Re: [RFC PATCH] selinux: move policy commit after updating selinuxfs

[Stephen Smalley <stephen.smalley.work@gmail.com>]

On 8/4/20 9:53 AM, Stephen Smalley wrote:

> With the refactoring of the policy load logic in the security
> server from the previous change, it is now possible to split out
> the committing of the new policy from security_load_policy() and
> perform it only after successful updating of selinuxfs.  Change
> security_load_policy() to return the newly populated policy
> data structures to the caller, export selinux_policy_commit()
> for external callers, and introduce selinux_policy_cancel() to
> provide a way to cancel the policy load in the event of an error
> during updating of the selinuxfs directory tree.  Further, rework
> the interfaces used by selinuxfs to get information from the policy
> when creating the new directory tree to take and act upon the
> new policy data structure rather than the current/active policy.
> Update selinuxfs to use these updated and new interfaces.  While
> we are here, stop re-creating the policy_capabilities directory
> on each policy load since it does not depend on the policy, and
> stop trying to create the booleans and classes directories during
> the initial creation of selinuxfs since no information is available
> until first policy load.
>
> After this change, a failure while updating the booleans and class
> directories will cause the entire policy load to be canceled, leaving
> the original policy intact, and policy load notifications to userspace
> will only happen after a successful completion of updating those
> directories.  This does not (yet) provide full atomicity with respect
> to the updating of the directory trees themselves.
>
> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> ---
> This patch is relative to my previous one,
> https://patchwork.kernel.org/patch/11698505/. Although this does
> not ensure atomicity when updating the selinuxfs directoty tree,
> I suspect it will solve Daniel's original bug because systemd/dbusd
> won't get the policy load notifications until the kernel is done
> updating selinuxfs and therefore won't try to re-read selinuxfs
> in the middle of it (because libselinux caches the class/perm
> mappings and only flushes on a reload).

Recognizing that re-basing the selinux namespace patches on top of these 
two patches might be painful, I went ahead and did so; the result can be 
found here:

https://github.com/stephensmalley/selinux-kernel/tree/working-selinuxns-rebase

The two patches that required manual fix-ups were the first one 
("selinux: rename selinux state to ns (namespace)") and the third one 
("selinux: dynamically allocate selinux namespace"). The rest re-based 
without conflicts.  The resulting tree built, booted, passed the 
selinux-testsuite, and I could successfully follow the instructions to 
create a new namespace and load a policy into it. As before, the child 
namespace won't be usable if you switch it to enforcing mode since we 
haven't yet revived the per-namespace support for inode and superblock 
security blobs and it is still very unsafe to use in its current form.