CAP_SYS_ADMIN: the new root

It's tricky, if you look at Brad's sample escalations you can see there are lots of assumptions involved. Some seem fairly clear (bind mounting a filesystem you control over the root is probably going to get attackers what they want or near enough) while others demand expert knowledge of the system being compromised (is there a root process treating information received over IPC as trusted? No? Too bad then, CAP_IPC_OWNER doesn't buy attackers root equivalence by that route)

The kernel is not in charge of local system policy. If the underlying block device on which your root filesystem is written is read-only then a kernel privilege to write to the device is no use to attackers, for example. But if they also have a device driver privilege that lets them flip the read-write switch on the hardware then suddenly they're in business...