Stephen Smalley wrote:
On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
Those of you who don't read Planet SE Linux but who are interested in Debian
may want to read the above.
Regarding the mismatch in policy version between your domU vs. dom0, you
should be able to build older policy versions via the config setting
in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
setting in build.conf, overridable on the make command line (monolithic
build).
Or you could install newer selinux core userland in your dom0 such that
it can read and downgrade the latest policy to the one supported by your
kernel (libselinux policy load logic will convert a newer policy to an
older one at load time for you).
Agree that converting between non-MLS and MLS/MCS is very painful at
present. Part of that we can fix (inappropriate dependencies in
semanage/seobject.py that should be querying the policy store via
libsemanage/libsepol rather than checking the running policy), and part
we cannot (still won't be able to switch the kind of policy at policy
reload in the kernel). I'd actually prefer that we just always enable
the MLS engine and field for simplification, presenting the same
experience to all users, and ensuring that we are all testing the same
code paths. I don't know how others feel about that though - I know
that Gentoo has historically not enabled MCS/MLS, and that upstream
refpolicy still defaults to not enabling it (standard).
I'm not sure why MLS support significantly increases policy build time
though.
Also note that the default (and only) policy on Ubuntu is non-mls.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
