On 11/01/2013 11:54 AM, Eric Paris wrote:
> On Fri, 2013-11-01 at 11:48 -0400, Stephen Smalley wrote:
>> On 11/01/2013 11:18 AM, Eric Paris wrote:
>>> glibc/nscd is acting as a userspace object manager. Today what they are
>>> doing is:
>>>
>>> static const access_vector_t perms[LASTREQ] =
>>> {
>>> [GETPWBYNAME] = NSCD__GETPWD,
>>> [GETPWBYUID] = NSCD__GETPWD,
>>> ...
>>> [INNETGR] = NSCD__GETNETGRP,
>>> [GETFDNETGR] = NSCD__SHMEMNETGRP,
>>> };
>>> ...
>>> rc = avc_has_perm (ssid, tsid, SECCLASS_NSCD, perms[req], &aeref, NULL) < 0;
>>> ...
>>>
>>> They recently ran into problems where they defined NSCD__GETNETGRP in
>>> their application but the selinux policy was never updated to support
>>> the new permission. They found that such checks were being denied.
>>> (which surprises me actually but I haven't dug into that and probably
>>> should)
>>>
>>> I suggested glibc replace SECCLASS_NSCD with string_to_security_class()
>>> and to replace the hard coded perm values with string_to_av_perm(). It
>>> has a couple of obvious benefits. one: they know if policy supports the
>>> class/perm in question. two: if things change in policy glibc still
>>> works (we know that WE won't change the policy such that they would
>>> break, but that doesn't mean that someone couldn't/wouldn't)
>>
>> Use selinux_set_mapping() if you want to create a mapping of your own
>> class/perm indices to the policy values without needing to keep them
>> identical. See XSELinux for an example.
>
> I completely forget about that interface. It does simplify things a
> bit, but it seems to make things worse as well. When dealing with
> unknown perms selinux_set_mapping() is going to return EINVAL and the
> userspace object manager will be just screwed...
>
> Any thoughts how we could better that interface for the case where
> security_deny_unknown() == 0?
Just do what I did in the kernel code (security/selinux/ss/services.c,
changes to selinux_set_mapping, map_decision based on handle_unknown).
But selinux_check_access() is IMHO a better way to go for any new code
unless it is so performance-critical that the context, class, and perm
lookups per check are prohibitive.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
