[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1296238768.2567.18.camel@localhost.localdomain>
Date: Fri, 28 Jan 2011 13:19:27 -0500
From: Eric Paris <eparis@...hat.com>
To: Steve Grubb <sgrubb@...hat.com>
Cc: "Andrew G. Morgan" <morgan@...nel.org>,
linux-kernel@...r.kernel.org,
"Serge E. Hallyn" <serge@...onical.com>,
"Serge E. Hallyn" <serge.hallyn@...onical.com>,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH] System Wide Capability Bounding Set
On Thu, 2011-01-27 at 11:50 -0500, Steve Grubb wrote:
> On Thursday, January 27, 2011 11:35:13 am Andrew G. Morgan wrote:
> > > Today, people want to have multi-tenant hosting using virtual
> > > machines whereby they give away root control of the guest VM.
> > > If you were renting system space, you would expect root access.
> > > That would make a nice juicy hacking target because you don't know
> > > who else is sharing the physical machine with you and they might
> > > have something in their VM worth stealing.
> >
> > Which root filesystem (/) do kernel helpers run in in such a virtual setup?
>
> I would assume that root in the VM could umount and mount anything. Or bind mount over
> it. We really want any change to a global bounding set done before initrd finishes
> doing its thing. This way there is no chance for mischief by the time control is
> turned over to /sbin/init - which root controls.
I feel like we are all starting to understand the problem. It still
leaves me with the belief that the only 2 known ways to solve it are
1) global bounding set which bounds the pP = fI & pI rule, unlike the
per process bset
2) a mechanism to drop caps from the bset and pI of the kthread which
runs helper apps
Do others see another way?
-Eric
--
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/
Powered by blists - more mailing lists