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

[Vivek Goyal <vgoyal@redhat.com>]

On Mon, Mar 18, 2013 at 10:50:21AM -0700, Casey Schaufler wrote:
> On 3/18/2013 10:05 AM, Vivek Goyal wrote:
> > On Fri, Mar 15, 2013 at 02:12:59PM -0700, Casey Schaufler wrote:
> >> On 3/15/2013 1:35 PM, Vivek Goyal wrote:
> >>> Create a new capability CAP_SIGNED which can be given to signed executables.
> >> This would drive anyone who is trying to use
> >> capabilities as the privilege mechanism it is
> >> intended to be absolutely crazy.
> > Will calling it CAP_SIGNED_SERVICES help. I intend to use it as
> > capability (and not just as a flag for task attribute).
> 
> No, the name is not the issue.
> 
> > I think primary difference here is that this capability is controlled
> > by kernel and only validly signed processes get it.
> 
> Applications are allowed to manipulate their capability sets
> in well defined ways. The behavior of file based capabilities
> is also explicitly defined. The behavior you are proposing would
> violate both of these mechanisms. 
> 
> >> 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). Think about how this will
> >> interact with programs using file based capabilities.
> > It is a separate capability. I am not sure why it would
> > interfere with other capabilities or functionality out there.
> 
> The behavior of capabilities is uniform. You can't have one
> capability that behaves differently from the others. If a
> file is unsigned but has CAP_SIGNED in the file capability
> set what do you expect to happen? Do you want a signed
> application to be able to drop and raise the fact that it
> is signed?

I have already removed this capability from bounding set. Behavior
I am looking for is that nobody should be able to set CAP_SIGNED
as file capability. I will look into that.

I am thinking of this more as kernel managed capability. It is
not in bounding set of any process and it can not be set as file
capability. 

It is a new capability, so no existing user application should
be trying to set it.

I think the only surprise would be that they can't drop it. If
that's a concern, may be we can allow dropping the capability.
But the side affect is that there is no way to gain it back for
the life time of process.

> 
> I expect that you don't want your attribute that indicates
> that the binary was signed to behave the same way that
> capabilities do. Like I said, capabilities are not just
> attribute bits. You need a different kind of process attribute
> to indicate that the binary was signed.

I think I need more than process attribute. One of the things
I am looking for is that signed processes run locked in memory
and nobody (i think no unsigned process) is able to do ptrace() on it.
Using the notion of capability might help here.

> 
> When (if ever) we have multiple LSM support you might consider
> doing this as a small LSM. Until then, you're going to need a
> different way to express the signature attribute.

I am not sure why you are viewing it as necessarily as attribute only.
I am thinking more in terms of that in certain situations, user space
processes can't perform certain operations (like kexec) untile and
unless process has the capability CAP_SIGNED_SERVICES. And this capability
is granted if upon exec() process signature are verified.

So yes it is little different from how capabilities are managed
currently. But is it very hard to extend the current capability definition
and include the fact that kernel can give additional capabilities to
processes based on some other factors.

Thanks
Vivek