[lxc-devel] security considerations when running lxc as non-root
Daniel Lezcano
daniel.lezcano at free.fr
Thu Jul 1 12:44:38 UTC 2010
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>
More information about the lxc-devel
mailing list