On 3/18/2013 11:30 AM, Vivek Goyal wrote: > 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.
No! You are not listening. All capabilities work the same way. If the file capabilities say ALL that means ALL. You do not get to put a hole in the middle of the file based capabilities. > 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. I heard that. No, you don't get to do that. All capabilities work the same way. Your attribute does not behave the way capabilities do, so you have to implement it some other way. > It is a new capability, so no existing user application should > be trying to set it. There are (and will be) applications that raise and drop all capabilities, and that do so for good reasons. > 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. Right. And that is a change to the capability mechanism. No, you don't get to do that. You don't want a new capability. You want a new attribute that behaves differently than capabilities do. You need to come up with a different way to implement your attribute. You do not get to change the way capabilities work. >> 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. There are already capabilities associated with ptrace. It would be simple to add a check for signatures in cap_ptrace_access_check. >> 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. Sigh. You need the process attribute to make the checks against. The process capability set, uids and groups are all examples of process attributes that exist today. > 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. Yes. That is correct. That is why we have the LSM facility. The unfortunate fact is that you only get one LSM at a time today. I am working on fixing that, but there is still work to be done before it will be ready for upstream. If signed application controls are deemed sufficiently important and your implementation sound you should be able to get the signature attribute and the checks on that attribute into the base system. > Thanks > Vivek > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
