Re: [PATCH] kernel: selinux: policy selectable handling of unknown classes and perms

[Eamon Walsh <ewalsh@tycho.nsa.gov>]

Joshua Brindle wrote:
> Paul Moore wrote:
>> On Thursday, August 2 2007 1:25:12 pm Eric Paris wrote:
>>   
>>> Maybe instead a versioning scheme?  Every security check comes with a
>>> 'version.'  Every time we add/change a security check we add one to the
>>> 'version' for that check.  If the policy handed to the kernel has a
>>> 'version' less than the value we get from the security hook call coded
>>> in kernel we can just allow it?   Maybe that could be a solution to the
>>> issue I am addressing now along with things like this netlabel change?
>>> It certainly would have to touch a whole lot of stuff and might be a
>>> pain to keep up with.  Lets say I move a security hook around in a
>>> function, I need to decide if the version need to be bumped on that hook
>>> or not.  Not impossible, but not pretty.  Also probably means a policy
>>> version update, which in turn breaks the discussion which we have
>>> ongoing above....
>>>     
>> While I'm not an expert on the policy aspects of this discussion and how the 
>> kernel and userspace objects managers interact I think at some point we are 
>> going to need something like what Eric proposes above.  With the requirement 
>> that new kernels must not regress when using old policy we are going to run 
>> into issues as we move forward and add new permission checks.  While I don't 
>> think we've seen it yet, it is reasonable to think that this problem will 
>> expand into userspace as we develop more and more userspace object managers 
>> such a X, CUPS, Postgres, etc.
>>
>> I know the changes aren't likely to be pretty, I'm kinda cringing at the 
>> thought actually, but I think it's a necessary evil for the long term 
>> survivability of SELinux.  At least that's what I took away from Eric and 
>> Stephen's comments on this thread and I tend to agree.
>>   
> 
> I'd have to give a pretty hard NAK (for what it would be worth) to the 
> versioning system, it simply doesn't scale; in the past we've used 
> policy versions to decide how some permission checks work (see fine 
> grained netlink discussions) and it was fairly non-ideal. I have to go 
> back to the 'the object manager should decide how to deal with unknown 
> permissions' argument. The object manager knows how its objects are 
> used, and how the security system affects those objects, it is in the 
> best position to make those decisions, the security server can only make 
> a rough estimation on what the object manager and user want to do, which 
> may or may not be accurate.

I would suggest exporting the allow/deny bit to userspace in the same 
manner as the enforcing mode.  The userspace AVC could then honor the 
behavior unless the object manager overrides it (I've been meaning to 
allow the object manager to override the enforcing mode so you could for 
example have a permissive X server on an otherwise enforcing system).

The selinux_set_mapping() call could be modified to return details on 
which specific classes and permissions were unknown.  Perhaps this could 
be done through a callback which would also be called on policy reload, 
given that class/perm values could appear or disappear at these times.

> 
> Here is an example, granted kernexec uses the reboot capability but 
> suppose we wanted to make it a separate permission, I'm fairly certain 
> that we'd want to always deny it if the policy didn't know about it, 
> whereas SE-X is completely unusable without policy and still has OS 
> level policy determining who can talk to the X daemon itself, SE-X would 
> have to make a determination of whether to run at all or run with course 
> grained permissions, chances are most people would want the latter. This 
> means we'd actually have environments where some object managers deny by 
> default and others allow (or even short circuit access attempts 
> altogether). This is ideal from a scalability and dynamic system 
> perspective and seems by far to be the best solution.
> 
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.