Re: [PATCH] System Wide Capability Bounding Set

[Serge E. Hallyn]

Quoting Steve Grubb (sgrubb@xxxxxxxxxx):
> On Friday, January 28, 2011 01:49:01 pm Serge E. Hallyn wrote:
> > > Using a wrapper program is a NOGO because the admin renting the machine
> > > would be able  to overwrite the wrapper and then they have arbitrary
> > > code running with full privs and
> > 
> > Not sure I've got this.  Wrapper program in the VM he can over-write,
> > but then he can overwrite the kernel too.
> 
> No, because the kernel is only read in at boot. After that, /boot can disapear and it 

And you can set it up so userspace cannot remount it, I assume?

> won't matter. It can be replaced with something and that won't matter because that's 
> not the real boot partition.
> 
> > But what we are worried about is the host, so you must mean that.  But if the
> > wrapper program is of type noone_may_write_this_t, then wouldn't finding a way to
> > replace that be as hard as overwriting the host kernel? 
> 
> No, because we aren't taking away the ability to mount or unmount. Not to mention that 
> root can replace his selinux policy so that next boot it doesn't define 
> noone_may_write_this_t. He might even put selinux in his VM in permissive.
> 
> > Which, of course, still remains as a viable attack vector for the guest admin,
> > whether you have this bounding set or not.
> 
> No, with the bounding set, any external call the kernel makes has the bounding set 
> applied. This means we don't have to further restrict root in unnatural ways.
> 
> > In other words, we have to accept that the TCB is always not just the
> > kernel, but some user-space too.  And yes, the wrapper program here
> > would be part of the TCB.
> 
> If you give someone root access in the VM, they probably want to set things up their 
> way. So, we really would like it if all the security mechanism were inside where they 
> can't be easily tampered with.

That's cool  :)

Thanks for the elaboration, that's very interesting and helpful.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/