[prev in list] [next in list] [prev in thread] [next in thread]
List: selinux
Subject: OSTree <3 SELinux
From: Colin Walters <walters () verbum ! org>
Date: 2014-03-03 23:34:05
Message-ID: 20140303233907.4C7FEC007AE () frontend1 ! nyi ! mail ! srv ! osa
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi all,
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:
https://lists.fedoraproject.org/pipermail/devel/2014-March/196257.html
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:
https://git.gnome.org/browse/ostree/commit/?id=2313bdcb62eee1170b128737ca84664cf82b13b8
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.
[Attachment #5 (text/html)]
Hi all,<div><br></div><div>In case you didn't notice, I'm back doing SELinux stuff - \
it's fun to be back =)</div><div><br></div><div>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:</div><div><a \
href="https://lists.fedoraproject.org/pipermail/devel/2014-March/196257.html">https:// \
lists.fedoraproject.org/pipermail/devel/2014-March/196257.html</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Except that on the client \
end, we need to handle /etc specially:</div><div><a \
href="https://git.gnome.org/browse/ostree/commit/?id=2313bdcb62eee1170b128737ca84664cf \
82b13b8">https://git.gnome.org/browse/ostree/commit/?id=2313bdcb62eee1170b128737ca84664cf82b13b8</a></div><div><br></div><div>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.</div><div><br></div><div>So that's some details about \
upgrades.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div>
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic