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