On lun., 2013-03-18 at 17:32 -0400, Matthew Garrett wrote: > This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability > indicates that a process is empowered to perform tasks that may result > in > modification of the running kernel. While aimed at handling the > specific > use-case of Secure Boot, it is generalisable to any other environment > where > permitting userspace to modify the kernel is undesirable. About that, did someone looked at the way securelevel(7) is handled on OpenBSD? This is more or less the same thing, where there's a desire to distinguish uid 0 from ring0. They're not using a capability but more a global state which allows more or less stuff depending on the value (securelevel=-1 to securelevel=2). Regards, -- Yves-Alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.infradead.org/pipermail/kexec/attachments/20130319/8b83a808/attachment-0001.sig>
