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: <1296253494.2567.35.camel@localhost.localdomain>
Date:	Fri, 28 Jan 2011 17:24:52 -0500
From:	Eric Paris <eparis@...hat.com>
To:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
Cc:	Steve Grubb <sgrubb@...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

On Fri, 2011-01-28 at 13:38 -0600, Serge E. Hallyn wrote:
> 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?

Undecided at this time.  There are 2 possibilities.  We will either
expose a small partition to the VM which the hypervisor enforces RO
access which contains the kernel, initrd, and bootloader (so basically
a /boot).  This is what I have been thinking.  Or we may just directly
launch a kernel and initrd from the hypervisor and those files need
never be exposed to the VM at all.  In an case, there will be no
possibility that root in the VM will be able to modify their kernel or
initrd.  The plan is to implement capability restrictions inside the
initrd.

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

That's correct, the TCB is going to be the kernel+initrd.  We must
accomplish all lockdowns inside the initrd before control is passed to
the root admin.

The helper script idea doesn't appear to meet the goal since the admin
would have control over the complete filesystem namespace and would be
able bypass it altogether (sgrubb mentioned bind mounting on top of it,
even if they couldn't overwrite it)

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