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

[Daniel Lezcano]

Hi All,

The lxc tools can be run as non-root with all the needed capabilities 
set by lxc-setcap via the file capabilities. The command run by lxc 
won't have these privileges of course.

In the execution flow of lxc, there are two processes: the first process 
of the container and its parent.

The container's init lxc code runs with privilege until we exec the 
command (the kernel removes the capabilities).

The container's init parent runs with privilege until the end because it 
needs them to do some cleanup before exiting (eg. removing the cgroup).

So at any time, we can't drop definitively the capabilities.

If I refer the document "Secure programmer: Minimizing privileges"

http://www.ibm.com/developerworks/linux/library/l-sppriv.html

The following section suggests to drop and reacquire the privilege 
during code execution.

"... If you can't permanently give up the privilege, then you can at 
least temporarily drop the privilege as often as possible. This isn't as 
good as permanently dropping the privilege, since if an attacker can 
take control of your program, the attacker can re-enable the privilege 
and exploit it. Still, it's worth doing. 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.

So I am wondering if it's worth to do that considering the following:

  * the code is not a web server, sendmail or sshd

  * the privilege are dropped definitively for the application

  * lxc is opensource, so it is easy for a hacker to check where is a 
buffer overflow and re-enable the capabilities

  * the compiler sets -f-stack-protector by default protecting lxc for 
buffer overflows

  * inherited capabilities are not set, so if a buffer overflow succeed, 
it won't be able to exec anything until the code injection copy the 
permitted capabilities to the inherited ones.

  1) Shall we consider a buffer overflow is a bug not a security breach?
  2) Shall we wrap the syscalls with privilege ?
  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 ?

I put in attachement 3 patches illustrating a part of the modifications 
for dropping / getting the capabilities.

Thanks
   -- Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: set-privilegied-calls.patch
Type: text/x-diff
Size: 11868 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20100701/db089134/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-privilegied-macro.patch
Type: text/x-diff
Size: 701 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20100701/db089134/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-caps-file.patch
Type: text/x-diff
Size: 5391 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20100701/db089134/attachment-0002.patch>