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@xxxxxxxxx>
---
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.
