linux-kernel - Re: [PATCH] System Wide Capability Bounding Set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110128193809.GB8854@localhost>
Date:	Fri, 28 Jan 2011 13:38:09 -0600
From:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
To:	Steve Grubb <sgrubb@...hat.com>
Cc:	"Serge E. Hallyn" <serge.hallyn@...onical.com>,
	Eric Paris <eparis@...hat.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	"Serge E. Hallyn" <serge@...onical.com>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] System Wide Capability Bounding Set

Quoting Steve Grubb (sgrubb@...hat.com):
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/