On Mon, Oct 12, 2015 at 12:42:42PM +0300, Sergey Bronnikov wrote: > Alexander found a report which was done for OpenVZ in 2005. > I have attached it.
Thank you for making this public, Sergey! I think this is worth another look, and the test programs from the tarball are worth re-running against currently maintained kernels. > 1.7. route tables, network interfaces (aliases), and mounts are not > properly beancounted or limited, allowing for DoS attacks on the host > node. route table flood appears to be the most effective, leading to > the system running out of physical memory within minutes. > > 1.8. The queues_count variable in ipc/mqueue.c is not virtualized, > potentially allowing to DoS the functionality for non-root users in all > VPSes and on the host system. I am not aware of these issues having been fixed, so maybe they are still present. The deliverable-1.tar.gz tarball contains testcases (should I say exploits?) for some of them, potentially allowing in-container users to DoS the host in these ways. (Maybe kmemsize would kick in, or maybe not soon enough or not at all. Things were pretty bad back then - I think linear search and such. Maybe newer kernels' data structures are sufficiently better to tolerate this sort of abuse, or maybe not.) > 2.2. vzctl.spec [...] [...] > Additionally, it is preferable for default permissions on /vz/private to > be forced to 700. We've been using 700 in Owl, but I think this might not be the case in upstream vzctl, nor in other distros. > 2.4. A warning should be added to the vzctl(8) manual page stating that > enabling non-default capabilities may completely break the OpenVZ > security model. Maybe vzctl itself should print a warning, too, when > requested to set known-unsafe capabilities. I think this is still missing, right? > Portions of code and potential issues yet to be checked for. We did not proceed with a more thorough security audit. > Recommendations for "hardening" OpenVZ security. I think none of these ended up being implemented. Please correct me if I am wrong. Other than these pieces I quoted and maybe some documentation issues (on LSMs breaking OpenVZ security model), I think everything else was fixed. (But it's worth re-testing now, as regressions are possible and lots of new code has been added, both upstream and OpenVZ-specific.) It was a pleasant experience working with OpenVZ developers on this, and briefly with Linux kernel upstream as well (all issues promptly fixed). Thanks again, Alexander _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
