Re: [PATCH 3/4] capability: Create a new capability CAP_SIGNED

[Vivek Goyal <vgoyal@redhat.com>]

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