Re: SELinux policy updates in a post-%post world

[Colin Walters <walters@verbum.org>]

[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]



On Tue, Mar 25, 2014 at 1:13 PM, Stephen Smalley <sds@tycho.nsa.gov> 
wrote:
> 
> Can you explain when/why you cannot run semodule -B?  As long as you
> also pass it -n and -s <store-name> and possibly -p <rootpath>, it
> should work and should not affect the running system until reboot or
> next policy load.

Right.  The first reason is at the moment I have an update system that 
*has no %post at all*.  It's much less flexible than traditional 
packages, but is much more reliable.

I have two high level concerns:
1) If I'm running arbitrary code, I want it to be started by systemd 
and ensure any log messages from it go to the journal, any error code 
is tracked, any processes started are properly cleaned up, etc.  Were I 
to add a %post type thing I'd likely use systemd-nspawn for this to 
ensure that /proc is mounted and all other requirements are met.

On the other hand, if it's just SELinux for now I may just commit 
support into the ostree core to recompile the policy in the new root 
directly from the main process and not fork off any other tool.

2) External tools may not match the "fdatasync policy".  Looking at the 
implementation of semanage_direct_commit() in 
selinux/libsemanage/src/direct_api.c, we create empty files, but don't 
open the parent directory fd and sync it.  Similarly, 
semanage_write_policydb() appears to just use fclose() and does not 
attempt to fdatasync() the policy file on disk.

This has been a real world problem with other triggers like 
gtk-update-icon-cache.  RPM is pretty careful to fdatasync() files it 
writes to disk.  But until:
https://git.gnome.org/browse/gtk+/commit/?id=6c6b49392629a8ee2facafb66c8867a49a3e9036
if you pulled the power after RPM said a "transaction" was complete, 
you could end up with a corrupted icon cache.

Now I admit, right now in OSTree I am simply doing a global sync() 
before swapping the bootloader configuration:
https://git.gnome.org/browse/ostree/tree/src/libostree/ostree-sysroot-deploy.c#n692

But that's a short term hack since sync() doesn't return errors, and it 
forces a flush of *everything* which can be a major performance hit.

On the other hand, there are cases where we *don't* want to 
fdatasync(), like constructing mock/pbuilder type build roots.  Some 
discussion here:
https://bugs.freedesktop.org/show_bug.cgi?id=70366

> Effectively semodule -B is performing a merge, by merging any local
> policy customizations into the updated policy.  You do want the merge
> because the updated policy may include changes required for the 
> updated
> system components, while the local customizations may be required for
> system operation (e.g. local file_contexts entries, boolean settings,
> login mappings, added allow rules for third party software or
> non-standard configurations), so using either just the modified policy
> from before the upgrade or just the unmodified updated policy could
> leave the system in a non-functional state.

Right, absolutely.  I want policy updates to work with local 
configuration as they do with traditional packages.  I also want 
upgrades to be fully atomic.  The goal is to do both =)



[-- Attachment #2: Type: text/html, Size: 3929 bytes --]