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)
Carlos and I had a question come out of this. How do we recommend he
handle the perms[] array? Before the switch to string_to_av_perm() it
was on a read only data page. Now since it has to be updated at run
time he has an array of strings on a read only data page but the AV
values are on a rw page. Do we have a suggestion how this could be
improved? Is it worth map-ing a page for this tiny array so it can be
marked RO after it is filled in?
-Eric
--
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.
