Messages in this thread | | | Date | Wed, 20 Mar 2013 10:41:10 -0400 | From | Vivek Goyal <> | Subject | Re: [PATCH 3/4] capability: Create a new capability CAP_SIGNED |
| |
On Wed, Mar 20, 2013 at 04:07:58PM +1100, James Morris wrote: > On Fri, 15 Mar 2013, Casey Schaufler wrote: > > > Capabilities aren't just random attribute bits. They > > indicate that a task has permission to violate a > > system policy (e.g. change the mode bits of a file > > the user doesn't own). > > Casey's right here, as well he should be. >
Ok, so how do I go about it (Though I have yet to spend more time understanding the suggestion in couple of other mails. I will do that now)
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.
If I draw a parallel, then based on certain other factors (binary is signed and secureboot trust has been extended to this binary), why can't kernel take a decision to give extra capability to this binary.
In fact instead of new capabiilty, I guess upon successful signature verification, one could just give CAP_MODIFY_KERNEL to process.
I am just trying to understand better that why capability is not a good fit here (Especially given the fact that CAP_MODIFY_KERNEL is making progress and it seems reasonable to me to extend the secureboot trust to validly signed processes. Like modules, their signatures have been verified and they should be allowed to modify kernel).
Thanks Vivek
| |