Shuttleworth: Losing graciously

Posted Feb 19, 2014 17:43 UTC (Wed) by fandingo (guest, #67019)
In reply to: Shuttleworth: Losing graciously by HelloWorld
Parent article: Shuttleworth: Losing graciously

> Just allow processes to specify that an rlimit is supposed to apply to them as well as their descendants, and PR_SET_CHILD_SUBREAPER ensures that your descendants can't reparent themselves to init.

That's true if and only if that ancestor reaper never dies or is killed. The security implications complicate things. It should be possible to overcome them possibly, but the warts add up.

> That's not a fundamental limitation. Just allow processes to specify that an rlimit is supposed to apply to them as well as their descendants[...] Otoh, I'm not sure if anything would actually be gained by doing that instead of cgroups.

I totally agree, but it would require a change to those functions (or new recursive versions).

Shuttleworth: Losing graciously

Posted Feb 19, 2014 17:59 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> That's true if and only if that ancestor reaper never dies or is killed.
So what? systemd is already required to never die.

Shuttleworth: Losing graciously

Posted Feb 19, 2014 18:29 UTC (Wed) by fandingo (guest, #67019) [Link]

If the reaper dies, then processes in that service escaped their "container" (because PPID is now 1). The service manager can no longer track them, and has lost all reliable control of the service.

This becomes a major problem with privileged services. Many services maintain a parent process that runs as root. Any compromise of this privileged service process (or malfeasance by it) allows it to kill it's hierarchy manager process and escape all control.

On the other hand, cgroups in a single-writer environment should be immune to this.

With systemd cgroup manager, PolKit would not authorize a process move outside all cgroups or to another cgroup (outside specific definitions like system.slice/sshd.service/ --> /user.slice/session.scope/).

The major benefit to systemd's cgroup manager is that it is not attackable via this style. It cannot be intentionally killed (it ignores all signals, even sigkill since it is PID 1), and if it were somehow forced to crash, the system would panic. Since PID 1 is the cgroup manager, there is no way to gain control of the kernel interface either.

There's no meaningful way to protect a reaper, unless you mandate that nothing in a hierarchy can run with enough privileges to kill the reaper. That would require a substantial change in many services, or requires additional sandboxing mechanisms in the kernel. (The kernel would need to perform a check that a caller of kill(2) is not trying to kill its reaper.)