[Users] Solar Designer Audit 2005

[Solar Designer]

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