[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