On Tue, 2014-04-29 at 17:14 -0400, Eric Paris wrote:
> selinux_check_access() has code like this:
>
> sclass = string_to_security_class(class);
> if (sclass == 0) {
> rc = errno;
> if (security_deny_unknown() == 0)
> return 0;
> errno = rc;
> return -1;
> }
>
> My problem with the code is that we have no logging of any kind why we
> just returned -1; The reason this was found is because Dominick is
> writing custom policy that doesn't define all of the classes/perms
> used by systemd and has security_deny_unknown() == 1. systemd calls
> selinux_check_access() gets -EINVAL, prints that it denied, but no
> where do we have a good reason why it was denied. systemd doesn't
> know, it's hidden in this library...
Systemd just prints: SELinux policy denies access. That is it. There is
no way to tell that there are unknown permissions and which unknown
permissions. One ends up in a situation that is not easy to debug.
In my case i knew directly this was about the systemd permissions
associated with the system kernel security class. I was hesitant to add
those since to me it just does not sound right to associate user space
permissions with a kernel security class.
This issue surfaced as part of a bigger issue that i identified where at
some point late in the shutdown process no avc's are logged at all
anymore. Whether it be user space avc denials or kernel avc denials.
For example if systemd would not have permissions to unmount file
systems then attempts my systemd to unmount file systems on shutdown
would be denied without any logs.
As a policy writer, avc denials and other SELinux messages is all i have
to go with. If SELinux blocks without any information then i do not know
what to do.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
