Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Hardened

Eclass update to support user-specific (overlay-driven) policy enhancements

 

 

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded


swift at gentoo

Apr 26, 2012, 11:58 AM

Post #1 of 3 (279 views)
Permalink
Eclass update to support user-specific (overlay-driven) policy enhancements

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


basile at opensource

Apr 28, 2012, 5:51 PM

Post #2 of 3 (263 views)
Permalink
Re: Eclass update to support user-specific (overlay-driven) policy enhancements [In reply to]

On 04/26/2012 02:58 PM, Sven Vermeulen wrote:

> 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

Why are you trying to avoid a global variable? I'd think that's less of
a QA issue than a trigger file.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197


swift at gentoo

May 15, 2012, 9:29 AM

Post #3 of 3 (234 views)
Permalink
Re: Eclass update to support user-specific (overlay-driven) policy enhancements [In reply to]

On Sat, Apr 28, 2012 at 08:51:05PM -0400, Anthony G. Basile wrote:
> Why are you trying to avoid a global variable? I'd think that's less of
> a QA issue than a trigger file.

Updated patch available on http://dpaste.com/748546/

It includes support for POLICY_FILES, allowing for 3rd party SELinux modules
to be managed by Portage without interfering or making things more difficult
for our policy.

It also removes some of the dual logic that was available before (to handle
bash arrays and single variables). By mapping arrays immediately towards
single variables, I could also drop the use of either a trigger file or a
global variable (as I can now just "query" the variable).

Finally, the eclass now tries to load the SELinux module and, if it fails,
it retries to load it but with all installed modules simultaneously. If that
still fails, we inform the user that this might be expected if this isn't
the last SELinux module installation (or upgrade).

That last addition allows us to support SELinux upgrade easier. For
instance, the failure(s) we had with 2.20110726 to 2.20120215 (modules
failing to load because of unresolved or undefined references) are now
handled automatically.

The eclass is currently still in hardened-dev overlay.

Wkr,
Sven Vermeulen

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.