On 05/02/2016 09:18 AM, Dominick Grift wrote: > On 05/02/2016 03:14 PM, Stephen Smalley wrote: >> On 04/29/2016 03:53 PM, Stephen Smalley wrote: >>> On 04/29/2016 01:04 PM, Dominick Grift wrote: >>>> >>>> I have mentioned this before (probably a few times), and i am >>>> not sure if this issue is actually what i think it is but i >>>> will once again mention this issue i observed many times. >>>> >>>> Excuse me if i am wrong here. >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1331668 >>>> >>>> https://github.com/fedora-selinux/selinux-policy/commit/971e97a2b8cb > cc14 >>>> >>>> > 3fc82badfaaf7900b4760399 >>>> >>>> When you change (user space?) access vectors then user space >>>> object managers get confused and stop working. This is now >>>> becoming an issue since core components are object managers >>>> (systemd/dbus) >>>> >>>> So basically there is no way for distributions to add/remove >>>> access vectors without breaking the running system. >>>> >>>> The only solution is immediately switch to permissive mode and >>>> to reboot the system after such an update. And you might not >>>> even be able to cleanly shutdown due to these confused >>>> components >>> >>> (cc'd redhat folks so they can provide more context on what the >>> actual bug/issue was, since it wasn't entirely clear to me from >>> the bugzilla or commit above) >>> >>> In general, the safest approach is to only add permissions at the >>> end of an existing class or add new classes at the end of the >>> current list of classes. That avoids perturbing the values of >>> any existing permission or class and thus shouldn't cause any >>> breakage. It looks like the commit you referenced was >>> adding/removing permissions at the end of the class though, so >>> I'm not clear on what broke there. There is something very odd >>> there though - I don't understand how Fedora policy got into a >>> state where those permissions weren't defined in the first place, >>> or why they are inconsistent in their order with upstream >>> refpolicy. > >> I looked a bit more closely at this bug, and it appears to me that >> the issue was simply that they added definitions for start and >> stop _without_ allowing those permissions for any confined domains >> that needed them. So then SELinux correctly denied those >> permissions and the system stopped working. That's operating as >> intended, not a bug in SELinux or anything to do with the potential >> race in class/permission lookup and policy reload. > > > Strange that then the solution seems to be removing the av perms again > instead of adding the required rules. Yes, I actually fixed the problem locally via a local policy module that allowed the permissions (prior to the update that undefined them again). I don't know why the latter approach was taken - maybe they didn't understand the cause of the bug or just viewed it as safer to undo what led to the bug. I also don't understand why these permissions became undefined in Fedora (they were originally defined by Fedora for systemd, so I would think they must have been defined at some point in the past in the Fedora policy) or the inconsistency between Fedora policy and current refpolicy. Current refpolicy has: class system { ipc_info syslog_read syslog_mod syslog_console module_request # these are overloaded userspace # permissions from systemd halt reboot status start stop enable disable reload } Fedora has: class system { ipc_info syslog_read syslog_mod syslog_console module_request halt reboot status undefined enable disable reload } So they have an "undefined" permission for some reason where refpolicy has "start", and their values of "enable", "disable", and "reload" won't match upstream because they omit "stop". And they were trying to add "start" and "stop" at the end, so their values also won't match upstream. > noneless, you've said it yourself (maybe not in so many words) that > the userspace object manager functionality is fragile in the sense > that object managers are not "fully safe against arbitrary changes to > class/permission definitions at runtime" Sure, but that isn't relevant for the bug above. Also, with the selinux userspace commit I mentioned, which is included in libselinux 2.5 and later, while there is still a potential race condition between policy reload and a permission check, that would only affect a permission check that is interleaved with the policy reload. So you might get a stray denial during the policy reload if it just so happens that one of these systemd permission checks is triggered at the same time, but you aren't going to keep getting denials indefinitely until systemd is restarted (which was the situation prior to that commit). Consequently, it might be safe enough to just sync the Fedora system class to the refpolicy one in an update, as long as you also make sure you are allowing those permissions where appropriate. Obviously testing any such update carefully would be a good idea. The other option if you want 100% safety would be to add back "start" and "stop" to the end of the Fedora system class while simultaneously allowing them as appropriate, but then you are essentially forever forked from refpolicy's system class definition. Meanwhile, it would be good to look at migrating systemd to using a class of its own and decoupling it from the kernel's system class. > >>> The fact that userspace code is using the system class at all is >>> a bug that has previously been pointed out; userspace needs to >>> use its own classes and not share one with the kernel. The >>> kernel recently took another permission from that class, so there >>> is a conflict looming. >>> >>> For userspace, selinux commit >>> b408d72ca9104cb0c1bc4e154d8732cc7c0a9190 was intended to help >>> with these kinds of changes, but as noted in the commit >>> description, there is still the potential interleaving of a >>> policy reload and a call to selinux_check_access() that could >>> cause problems. >>> >>> The kernel is presently the only component fully safe against >>> arbitrary changes to class/permission definitions at runtime, and >>> that is because it can atomically update its class/permission >>> mappings with the policy reload transaction. I think making >>> userspace fully safe would require introducing a new selinuxfs >>> interface (e.g. /sys/fs/selinux/access2) that takes and returns >>> class and permission strings rather than values, so that the >>> kernel can internally handle the mapping and ensure it is updated >>> atomic with policy reloads too. And one would then need to >>> rework the userspace AVC and selinux_check_access() to use that >>> interface, and convert any remaining userspace components that >>> are still using something other than selinux_check_access() for >>> SELinux permission checking. _______________________________________________ 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.
