Re: Alas for CAP_NET_BIND_SERVICE

[David Gibson <david@gibson.dropbear.id.au>]

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

On Sun, Oct 16, 2022 at 11:46:46AM +0200, Stefano Brivio wrote:
> On Fri, 14 Oct 2022 13:54:28 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, Oct 13, 2022 at 06:54:26AM +0200, Stefano Brivio wrote:
> > > On Thu, 13 Oct 2022 11:34:04 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > On Wed, Oct 12, 2022 at 12:47:07PM +0200, Stefano Brivio wrote:  
> > > > > On Wed, 12 Oct 2022 20:31:20 +1100
> > > > > David Gibson <david@gibson.dropbear.id.au> wrote:
[snip]
> > > > > It would be equivalent if we just inherited capabilities from the
> > > > > parent as opposed to file capabilities -- that's what I meant.
> > > > > 
> > > > > I think it's a bit early to decide to drop those, though. Right now
> > > > > pasta isn't really used as a stand-alone tool (even though I
> > > > > actually do that, I find it very convenient also for totally unrelated
> > > > > purposes).
> > > > > 
> > > > > Should we see some use cases, then we could make a more informed
> > > > > decision.
> > > > >     
> > > > > > You can do the same thing with passt, though it's fiddlier
> > > > > > (you'd need a shim to translate qemu socket protocol before plugging
> > > > > > it into the server).    
> > > > > 
> > > > > Oh, you mean running pasta plus a shim plus qemu? Because with passt I
> > > > > don't understand how you'd pass that kind of stuff over AF_UNIX...    
> > > > 
> > > > No qemu necessary.  Make your bogus server, but instead of directly
> > > > listen()ing on a low port, have it connect to a Unix socket and wait
> > > > for SYN packets to a low port in qemu protocol.  Then use passt to
> > > > turn your Unix socket into a real listen()ing socket on the host.  
> > > 
> > > ...here. But the environment I had in mind was a rather controller one,
> > > with KSM policies that would normally prevent you from even having your
> > > bogus server.
> > > 
> > > Well, that would be the case for KubeVirt at least: three binaries and
> > > not much margin to play tricks.  
> > 
> > Ok, but even then using the file capability rather than the sysctl
> > only makes a difference if the attacker:
> >  * CAN escape confinement enough to make socket calls in the netns
> >    where we would be setting the sysctl
> >  * CAN'T escape confinment enough to exec() passt
> 
> Hmm, I'm thinking about another fact. Now we don't drop the capability
> after binding ports, but that's anyway not effective in the parent
> namespace because of what you mentioned, which implies that we can just
> bind configured ports.

Sorry, I don't follow what you're saying here.

> There might be a relevant difference between binding a port 25, a less
> usable 53 or 67, or a more innocent 443. In practice, if somebody uses
> the sysctl, they might very well be setting it to 0, instead.
> 
> By the way, I just realised, after these changes we should double check
> the AppArmor and SELinux profiles we ship as examples.
> 
> I don't think it's urgent, because in the worst case they should be too
> restrictive rather than the opposite -- see the current AppArmor
> "capability" directive and the SELinux "allow passt_t self:capability"
> enforcement.

-- 
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 --]