| |||||||||||||
CAP_SYS_ADMIN: the new rootCAP_SYS_ADMIN: the new rootPosted Mar 14, 2012 17:56 UTC (Wed) by JoeBuck (subscriber, #2330)Parent article: CAP_SYS_ADMIN: the new root Suggestion: determine which capabilities are "as good as root" and either eliminate those capabilities or eliminate the ability for a program with that capability to obtain all the others. Programs that previously relied on eliminated capabilities would then have to run as root. To do otherwise gives a false sense of security and just adds complexity.
(Log in to post comments)
CAP_SYS_ADMIN: the new root Posted Mar 14, 2012 18:25 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
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...
|
|||||||||||||