public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH] conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Date: Fri, 14 Oct 2022 14:20:44 +1100	[thread overview]
Message-ID: <Y0jVjAzy1YtaJDXC@yekko> (raw)
In-Reply-To: <Y0jTmgw3g/ilLG+h@yekko>

[-- Attachment #1: Type: text/plain, Size: 4119 bytes --]

On Fri, Oct 14, 2022 at 02:12:26PM +1100, David Gibson wrote:
> On Thu, Oct 13, 2022 at 06:34:06PM +0200, Stefano Brivio wrote:
> > Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
> > the target user namespace as we isolate the process, which means
> > we're unable to bind to low ports at that point.
> > 
> > Bind inbound ports, and only those, before isolate_user(). Keep the
> > handling of outbound ports (for pasta mode only) after the setup of
> > the namespace, because that's where we'll bind them.
> > 
> > To this end, initialise the netlink socket for the init namespace
> > before isolate_user() as well, as we actually need to know the
> > addresses of the upstream interface before binding ports, in case
> > they're not explicitly passed by the user.
> > 
> > As we now call nl_sock_init() twice, checking its return code from
> > conf() twice looks a bit heavy: make it exit(), instead, as we
> > can't do much if we don't have netlink sockets.
> > 
> > While at it:
> > 
> > - move the v4_only && v6_only options check just after the first
> >   option processing loop, as this is more strictly related to
> >   option parsing proper
> > 
> > - update the man page, explaining that CAP_NET_BIND_SERVICE is
> >   *not* the preferred way to bind ports, because passt and pasta
> >   can be abused to allow other processes to make effective usage
> >   of it. Add a note about the recommended sysctl instead
> > 
> > Reported-by: David Gibson <david@gibson.dropbear.id.au>
> > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Sorry, sent the previous reply before I'd finished.

> > -If the port forwarding configuration requires binding to port numbers lower than
> > -1024, \fBpasst\fR and \fBpasta\fR will try to bind to them, but will fail if not
> > -running as root, or without the \fICAP_NET_BIND_SERVICE\fR Linux capability, see
> > -\fBservices\fR(5) and \fBcapabilities\fR(7). To grant the
> > -\fICAP_NET_BIND_SERVICE\fR capability to passt, you can issue, as root:
> > +If the port forwarding configuration requires binding to ports with numbers
> > +lower than 1024, \fBpasst\fR and \fBpasta\fR will try to bind to them, but will
> > +fail, unless, either:
> > +
> > +.IP \(bu 2
> > +the \fIsys.net.ipv4.ip_unprivileged_port_start\fR sysctl is set to the number
> > +of the lowest port \fBpasst\fR and \fBpasta\fR need. For example, as root:
> > +
> > +.nf
> > +	sysctl -w net.ipv4.ip_unprivileged_port_start=443
> > +.fi
> > +
> > +\fBNote\fR: this is the recommended way of enabling \fBpasst\fR and \fBpasta\fR
> > +to bind to ports with numbers below 1024.
> > +
> > +.IP \(bu
> > +or the \fICAP_NET_BIND_SERVICE\fR Linux capability is granted, see
> > +\fBservices\fR(5) and \fBcapabilities\fR(7).
> > +
> > +This is, in general, \fBnot the recommended way\fR, because \fBpasst\fR and
> > +\fBpasta\fR might be used as vector to effectively use this capability from
> > +another process.
> > +
> > +However, if your environment is sufficiently controlled by an LSM (Linux
> > +Security Module) such as \fIAppArmor\fR, \fISELinux\fR, \fISmack\fR or
> > +\fITOMOYO\fR, and no other processes can interact in such a way in virtue of
> > +this, granting this capability to \fBpasst\fR and \fBpasta\fR only can
> > +effectively prevent other processes from utilising it.
> > +
> > +Note that this will not work for automatic detection and forwarding of ports
> > +with \fBpasta\fR, because \fBpasta\fR will relinquish this capability at
> > +runtime.
> > +
> > +To grant this capability, you can issue, as root:
> > +
> > +.nf
> > +	setcap 'cap_net_bind_service=+ep' $(which passt)
> > +.fi
> >  
> > -.RS
> > -setcap 'cap_net_bind_service=+ep' $(which passt)
> >  .RE

These likely won't be enough, since for most users the caps on the
passt.avx2 binary are the ones that will matter.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-10-14  4:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 16:34 [PATCH] conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user() Stefano Brivio
2022-10-14  3:12 ` David Gibson
2022-10-14  3:20   ` David Gibson [this message]
2022-10-14  6:38     ` Stefano Brivio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0jVjAzy1YtaJDXC@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).