On Thu, Sep 10, 2020 at 7:39 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > On Wed, Aug 19, 2020 at 9:07 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > On Wed, Aug 19, 2020 at 1:15 PM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > <snip> > > > So I've started to compose Fedora Change proposal > > > > > > https://fedoraproject.org/wiki/SELinux/Changes/Disable_CONFIG_SECURITY_SELINUX_DISABLE > > > > > > It's not complete yet, but I believe it contains basic information. I'd > > > appreciate if you can help me with text, phrases and references so that it would > > > be easy to sell it as security feature to Fedora community :) > > > > I'd simplify the Summary to be something like "Remove support for > > SELinux runtime disable so that the LSM hooks can be hardened via > > read-only-after-initialization protections. Migrate users to using > > selinux=0 if they want to disable SELinux." > > FYI, the change proposal has now been announced to the Fedora devel community: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/YQIYMWKFQEWCILU7UZWXO3YFNS2PLDG4/ With regard to concerns raised in that thread: 1) For (soft?) real-time users, one option (if the latency introduced by SELinux without a policy loaded is truly enough to affect their workloads) would be to insert a if (!selinux_initialized(&selinux_state)) return 0; at the beginning of most hooks. However, we can't do that everywhere (e.g. we still need to allocate/initialize security structures and maintain lists of superblocks and inodes allocated before policy load so that we can later fix up their labels during selinux_complete_init), and adding such checks would make selinux_state.initialized an even more attractive target for kernel exploits since it becomes another way to "disable" SELinux entirely. You can of course already target it to disable policy checking but doing so tends to break certain things like security_sid_to_context/context_to_sid on SIDs other than the initial ones so it is not quite as attractive as enforcing currently. This assumes that these real-time workloads are not so sensitive that even the overhead of the indirect function call for the LSM hook pushes them over their tolerance. 2) For cases where an error is returned by SELinux that is not already governed by a selinux_initialized() or enforcing_enabled() check, we just need to ensure that all such cases are gated by such a check. We fixed that recently for the removexattr security.selinux case and there were some earlier cases fixed with respect to setting labels before policy load. The specific concern raised in the thread appeared to be due to denials silenced via dontaudit rules, which won't happen if there is no policy loaded so I don't think that's relevant. There are other cases where SELinux might return an error if a new case is introduced in another kernel subsystem without updating SELinux to handle it, e.g. a new type for selinux_perf_event_open(), a new obj_type in selinux_path_notify(). It would be better if we could introduce build-time guards to catch these as we have done for e.g. new capabilities, new socket address families, new netlink message types, in order to ensure that they are always in sync.
