Daniel Lezcano <daniel.lezc...@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. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
