BUG: selinuxfs class directory not updated atomically on reload

[stephensmalley]

As reported in https://lore.kernel.org/selinux/d3abd210-928e-374f-1e9b-fddfaa203c53@linux.microsoft.com/, selinuxfs does not atomically update its class subdirectory upon a policy reload, thereby creating a window during which userspace lookups of classes/permissions will fail. This can break userspace object managers like systemd or dbusd especially after more recent userspace changes to flush the class/perm cache upon a policy load notification from the kernel. If handle_unknown=deny, this can yield extraneous denials during the race window. Instead of deleting the old class subdirectory and then creating the new one in place, selinuxfs should create an unattached class directory tree from the new policy and then atomically exchange the old and new directories (ala RENAME_EXCHANGE). This is part of a broader set of issues around policy reload.

[stephensmalley]

Aside from the manner in which we re-create the tree, wondering if we ought to optimize for the case where there are no changes to the existing classes/permissions (hence no need to delete or re-create any nodes under "class"). Ditto for "booleans".

[pcmoore]

Adding @dburgener as he originally brought the issue up on-list.

[pcmoore]

Related to #52.

[dburgener]

Thanks for the mention. I've been working off and on on trying to get a patch set ready for submission for this, but unfortunately I haven't had as much time to put towards it as I'd hoped. I'm still making progress though, so if no one else gets there first, I hope to have a fix for this eventually.

[stephensmalley]

Fixed via 0eea6091539b15572cd278b8d62893c058bdb292