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

[Michael H. Warfield]

On Thu, 2010-07-01 at 17:47 +0200, Ferenc Wagner wrote: 
> Daniel Lezcano <daniel.lezcano at free.fr> writes:
> 
> > "... If you can't permanently give up the privilege, then you can at
> > least temporarily drop the privilege as often as possible.  [...]
> > Many attacks only work if they trick the privileged program into doing
> > something unintended while its privileges are enabled (for example, by
> > creating weird symbolic links and hard links). If the program doesn't
> > normally have its privileges enabled, it's harder for an attacker to
> > exploit the program."
> >
> > But if I look at the lxc code, the number of syscalls with the
> > privilege needed is very important, so enabling the capabilities, call
> > the syscall and disable the capabilities again, will be intrusive and
> > will modify all the lxc code, with the disadvantage of adding more
> > overhead at container startup by increasing the number of syscalls.
> 
> And at the same time remove the reason for doing it at all: it's only
> the syscalls which can "do something unintended", not the arithmetics
> between them.

> >  1) Shall we consider a buffer overflow is a bug not a security
> >     breach?

> It's a security breach if somebody runs lxc setuid root or with file
> capabilities.

It's a security "vulnerability" if someone can exploit it to execute
code or gain privileges.  It's not a security breach unless someone
actually exploits it.  Even in the case where Proof of Concept code
exists for a vulnerability, it still is not considered a breach until
someone actually actively exploits it to break into a system.
> >  2) Shall we wrap the syscalls with privilege ?

> As above, I don't think it's worth doing.

As a security expert, I would tend to disagree but I don't have a real
strong opinion in this particular case.  Since the syscalls are not
called frequently and not imposing a particular performance load, my
inclination would be to take the extra overhead and close off avenues of
exploitation outside of those calls, anyways.

> >  3) Shall we bound with privilege a large scope of lxc code like
> >     lxc_setup or lxc_spawn reducing the number of caps flip/flop ?

> Can you really drop significant capabilities during those?

The largest gain would be against any exploit that executed code without
passing through those syscalls.  In theory, an exploit could incorporate
code which recovered those priv's and THEN executed code like forking a
shell.  That's not a common occurrence, though.  Most buffer overrun
exploits fork to a shell as quickly as possible.  If the buffer overrun
is in an area of code where privs are dropped, you've limited the scope
of the damage or forced the exploit coder to add the recovery code or
some how use that BO to exploit something through one of your critical
syscall paths.  Not impossible, certainly.  But definitely more
difficult.
> The best would be to permanently drop anything that isn't needed
> anymore.  But I guess CAP_SYS_ADMIN is needed for cleaning up the cgroup
> at the end, so there isn't much to gain here: any exploit would easily
> get to full root in no time.  And as you also point out, lxc_start isn't
> a server accepting input from outside.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20100701/99667f26/attachment.pgp>