In case you didn't notice, I'm back doing SELinux stuff - it's fun to be back =)
Now, I've been working on a new general-purpose upgrade system for Linux-based operating systems, called OSTree. There is a higher level project "Fedora Atomic Initiative" which I just announced a new release of here:
So why am I posting here? Well, I designed OSTree from day 0 to support SELinux well, and I think it shows. Let's just say the integration of traditional package systems (dpkg/rpm) and SELinux is...a bit ugly.
For example, whether and how we relabel existing contexts on disk when upgrading to a new policy. Whether and how we restart running daemons after a new policy.
Say that an update changes policy and a daemon at the same time. With the "partial live updates" model that traditional package systems create, you can have the *old* daemon running with the *new* policy, and the new policy now denies something only the old version needs.
This kind of problem is deeply evil and insidious because only live updates see it - if someone downstream tries to reproduce with the same package versions, they won't see it on a fresh boot.
So with OSTree, I solve this by simply not supporting "partial live updates". Every upgrade is *fully atomic* you have to reboot for a new SELinux policy, a new daemon, etc.
Another example of a major change OSTree enables is that most SELinux file context labeling happens on the *build server side*. This is significantly more efficient if one is replicating to many machines, and also more reliable.
Except that on the client end, we need to handle /etc specially:
That's old code, but the basic idea is that on upgrades, we do a 3 way merge of /etc - and on the client end, OSTree will load the policy and ensure that the new /etc gets the property security contexts.
So that's some details about upgrades.
I could talk more here about how the OSTree model of shipping and testing complete *trees* melds well with the similarly centralized selinux-policy model, but hopefully that's obvious.
On the subject of testing - my goal is to get notification of a new AVC denial after a package build in Koji for one of my tracked trees down to minutes, if not faster.
This mail is already long, but I just wanted you all to know I'm committed to making SELinux work well, and if you have a chance to look at the OSTree-SELinux integration, I'm happy to hear any feedback.
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
