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

[Ferenc Wagner]

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.

>  2) Shall we wrap the syscalls with privilege ?

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

>  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 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.
-- 
Cheers,
Feri.