Messages in this thread | | | From | Matthew Garrett <> | Subject | Re: [PATCH 3/4] capability: Create a new capability CAP_SIGNED | Date | Wed, 20 Mar 2013 14:50:59 +0000 |
| |
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 | mjg59@srcf.ucam.org
| |