[lxc-devel] security considerations when running lxc as non-root

Serge E. Hallyn serge.hallyn at canonical.com
Fri Jul 2 16:05:13 UTC 2010


Quoting Greg Kurz (gkurz at fr.ibm.com):
> On Thu, 2010-07-01 at 10:58 -0500, Serge E. Hallyn wrote:
> > 3. instead of keeping caps in pP and raising in pE when needed,
> > a more privilege-separated approach could be used, where you
> > have small privileged helpers which are called by the unprivileged
> > main program.  In this case, lxc-start would clear out both pP
> > and pE, but keep caps in pI.  Then, little helpers like
> > lxc-destroy-cgroup would have fP=fE=empty and fI=<some_set> where
> > some_set has just the caps it needs to do its job.  Then if any
> > normal user calls lxc-destroy-cgroup, it'll run with no privs,
> > but when lxc-start calls it with pI=full, then lxc-destroy-cgroup
> > will run with pP = (intersection of lxc-start's pI and
> > lxc-destroy-cgroup's
> > fI).  It can then move bits from pP to pE when needed (or just
> > have fE=fI to have pE auto-filled).
> > 
> 
> I definitely like this approach. Is it possible to do something similar
> without relying on file capabilities ? To handle the case where liblxc
> binaries are located on NFS, for example.

1. maybe you can make the helpers setuid-root and have them check the
   ruid or rgid of the caller to make sure only lxc-start calls them?

2. James Morris is pushing patches to make xattrs over NFS work.  He
   last sent them out a few weeks ago, not sure of upstream status.
   Of course then you still have CIFS, squashfs, etc to worry about...

-serge




More information about the lxc-devel mailing list