Hi guys,
"""
tl;dr: New eclass supports users providing SELinux module files (the .fc,
.te and .if files) through their ebuilds' files/ directory rather than
through ugly patches.
"""
One of the things I'm hoping to accomplish soon is to better support users
in their quest to update the SELinux policies. Although we continue to
strive towards a working set of policies for most users, we should help
users to update the policies themselves when it matches their requirements,
but not necessarily ours.
A huge part on this is of course documentation, so I'm definitely going to
put much focus there, but another thing would be to support users in
user-specified SELinux policy modules.
Until now, the feedback to the user was to create the module, build it
manually and load it in the system. This works well of course (it is the
de-facto way of handling things) but I was wondering why users wouldn't be
able to provide these modules towards other users in overlays.
Until now, this meant that the user had to setup a development environment,
add in the module files, generate a patch and then include that patch in an
ebuild package. That's not really efficient for most users, so I updated the
eclass (currently only in hardened-dev overlay for testing) to support a
POLICY_FILES="" variable.
When such an ebuild contains a setting like:
POLICY_FILES="jbossas.te jbossas.fc"
then these files, found in the files/ directory, are automatically build and
loaded just like official modules. No need for patching or creating
development areas just to load the modules: write the code, put it in the
files/ directory and you're done.
The second change is to support interfaces for these modules. In SELinux,
interfaces provide a way for other modules to call privileges specific for
this module. For instance, in the example of jbossas (JBoss Application
Server module), this could be a jbossas_domtrans() interface, allowing one
domain to call JBoss AS and transition to the jbossas_t domain.
Until now, we cannot update interfaces easily since interfaces were only
manageable by the selinux-base package. Every update on interfaces meant an
update on the base policy. With the change currently in the overlay,
user-provided modules can now provide their own .if file as well, which gets
installed. They can't overwrite the interfaces provided by the
selinux-base package (that's still our domain) but can provide interfaces
that other modules can use:
POLICY_FILES="jbossas.te jbossas.fc jbossas.if"
One thing I'm not that happy about is some trick I included in the eclass
for now to decide if a .if file can be installed as well or not. I check if
the file is provided through POLICY_FILES (which means a 3rd party module)
and then place a trigger file in ${S}/strict/ called ".install_interfaces"
because I need this information in a later phase of the ebuild. I use this
because I don't like introducing global variables in ebuilds, but this might
be wrong (QA-wise) from me. I'll check with the QA folks a bit later (after
some more testing).
Wkr,
Sven Vermeulen
