Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:15 UTC (Wed) by fandingo (guest, #67019)
In reply to: Shuttleworth: Losing graciously by Cyberax
Parent article: Shuttleworth: Losing graciously

> it seems that an untrusted process _at_ _most_ can cause high load on the kernel and perhaps significantly slow down other processes.

Only if that process is unprivileged. If you have a service that runs a privileged process (like the parent PID of Apache or OpenSSH), it can modify any part of the cgroup hierarchy.

A single-writer model (especially if the writer is PID 1) with policy enforcement precludes this behavior. Even a privileged user would not be able to gain authorization to perform cgroup changes outside what the policy allows (like managing its subtree). Furthermore, a privileged user couldn't even connect to the kernel cgroup API directly, because a writer is already registered, and if it's PID 1, cannot be crashed in order to register a malicious writer.

Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:20 UTC (Wed) by dlang (guest, #313) [Link]

existing LSMs can block access to cgroups by even root processes today.

or you can play games with the PID namespace so that those processes are only root within their limited context, not for the whole systems.

But if you are concerned about a malicious root process, the fact that it can change cgroups settings seems like a pretty minor thing to worry about.

Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Only if that process is unprivileged. If you have a service that runs a privileged process (like the parent PID of Apache or OpenSSH), it can modify any part of the cgroup hierarchy.
It might as well simply do 'chmod -R a+r+w+x /' to the same effect.