SELinux policy updates in a post-%post world

[Colin Walters <walters@verbum.org>]

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

Hi,

I mentioned OSTree earlier here.  An issue came up with the SELinux 
integration; to understand it, let me describe how OSTree upgrades work:

1) We perform an rsync-like[1] process to a *new* chroot
2) A "basic" configuration merge is done - we take the new /etc 
defaults, and apply any modified files on top

Note that the policy.19 file is in /etc.

Crucially, there is at present no %post/postinst type functionality.  
This is a dramatic increase in reliability over traditional packages.  
No shell script run as root copy/pasted or just copied from elsewhere 
appended to everything.

For things like /usr/lib/ld.so.cache which is just a cache, this works 
fine because it's just referencing things in /usr/lib - it's all 
precomputed on the compose server.

Now, at least the Fedora selinux-policy has a %post that runs "semodule 
-B" which recompiles the policy (if the client machine has modified it 
locally).

Currently with OSTree, what will happen is it will notice the policy.19 
file is a modified file in /etc, and simply carry it forward.  In other 
words, updates to the base policy have no effect once the admin has 
modified it locally.

Administrators *can* rerun "semodule -B" manually after booting into 
the new root to recompile.

Why can't I just add a %post concept to OSTree?  Well, I could.  But 
I'd like to try as hard as conceivably possible to avoid it, and even 
then only do it where all other avenues are exhausted.  For one thing, 
it would break the ability to do completely offline updates (e.g. open 
up a VM guest disk from the host, and update it).  This ability is 
presently used to great effect in the testing system.

The primary alternative to %post is a "dynamic merge".  For example, 
systemd has a design where the default unit files are in 
/usr/lib/system, and then "dropins" can customize them in 
/etc/systemd/system.  On boot, it unions the two.

Similarly, I added /usr/lib/passwd in addition to /etc/passwd:
https://sourceware.org/bugzilla/show_bug.cgi?id=16142

However...I'm uncertain about doing this for SELinux policy.  The 
policy load happens very early in userspace setup and it's a complex 
task.

One option is to recompile the policy if we can (we're doing an upgrade 
from inside a running system, just chroot to new deployment and rerun 
semodule), and throw an error if we can't do it (the offline upgrade 
case).  The latter would only occur when a machine has a modified 
policy, which doesn't happen for my testing system.

Any other ideas?

[1] It doesn't share any code with rsync, but the details are 
irrelevant for this purpose

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