On Wed, 2013-03-20 at 10:41 -0400, Vivek Goyal wrote: > I am not sure why CAP_COMPROMISE_KERNEL(CAP_MODIFY_KERNEL) is any > different. When secureboot is enabled, kernel will take away that > capability from all the processes. So kernel became a decision maker > too whether processes have CAP_COMPROMISE_KERNEL or not based on > certain other factors like secureboot is enabled or not.
No, that's a limited case. Outside of that, it's an access control capability in exactly the same way as CAP_SYS_RAWIO is. The easiest way to think of this is probably whether it ever makes sense for an arbitrary binary run as root to possess that capability. For CAP_COMPROMISE_KERNEL the answer is yes - for CAP_SIGNED, the answer is no. Just have a flag somewhere in the process structure that indicates whether it was signed. There's no need to use capabilities here. -- Matthew Garrett | [email protected]
