Managing SELinux in the Enterprise

[Douglas Brown]

Hi all,

SELinux has some configuration files such as /etc/selinux/config which are easily managed with a tool like puppet. There’s also modular policies that can be managed with rpms (via Satellite) and or puppet (semodule). Finally puppet supports enforcing booleans with 'seboolean’. However, there’s a few things missing:

*   SELinux user and role mappings
  *   Port labels (only supported in base policy or changed with semanage like so: semanage port -a -t httpd_port_t -p tcp 6312)
  *   Custom file labels (ie. semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?")

I know these can be imported and exported with semanage using the -i and -o flags, however it’s slow and doesn't easily facilitate the programmatic query and enforcement of these settings at scale using a tool like puppet. Ideally puppet could manage the .local files in /etc/selinux/targeted/modules/active/, however Red Hat support tells me this won’t work and that semanage is the only supported mechanism. Surely there’s someone in the community who has a non-hackish method of dealing with this?

Is FreeIPA the solution to the user and role mappings? What about the labels?

Thanks,
Doug

[Daniel J Walsh]

On 09/21/2014 09:49 PM, Douglas Brown wrote:
> Hi all,
>
> SELinux has some configuration files such as /etc/selinux/config which
> are easily managed with a tool like puppet. There’s also modular
> policies that can be managed with rpms (via Satellite) and or puppet
> (semodule). Finally puppet supports enforcing booleans with
> 'seboolean’. However, there’s a few things missing:
> SELinux user and role mappings
> Port labels (only supported in base policy or changed with
> semanage like so: semanage port -a -t httpd_port_t -p tcp 6312)
> Custom file labels (ie. semanage fcontext -a -t
> httpd_sys_content_t "/data/www(/.*)?")
>
> I know these can be imported and exported with semanage using the -i
> and -o flags, however it’s slow and doesn't easily facilitate the
> programmatic query and enforcement of these settings at scale using a
> tool like puppet. Ideally puppet could manage the .local files in
> /etc/selinux/targeted/modules/active/, however Red Hat support tells
> me this won’t work and that semanage is the only supported mechanism.
> Surely there’s someone in the community who has a non-hackish method
> of dealing with this?
>
> Is FreeIPA the solution to the user and role mappings? What about the
> labels?
>
> Thanks,
> Doug
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

Why is managing this content via semanage not a good thing?

BTW You can put multiple ops within a transaction, which speeds up semanage.

https://danwalsh.livejournal.com/41593.html

The openstack-selinux rpm package has a bunch of operations being done
within a transaction, including setting network ports, booleans and
default file labeling.

BTW Ansible is also a nice method for managing SELinux in the enterprise.

Here is an presentation I wrote on managing SELinux in the enterprise

https://fedorapeople.org/~dwalsh/SELinux/Presentations/SummitSELinuxEnterpri...

[Douglas Brown]

On 11 Oct 2014, at 9:20 pm, Daniel J Walsh <[e-mail]> wrote:

On 09/21/2014 09:49 PM, Douglas Brown wrote:
Hi all,

SELinux has some configuration files such as /etc/selinux/config which are easily managed with a tool like puppet. There’s also modular policies that can be managed with rpms (via Satellite) and or puppet (semodule). Finally puppet supports enforcing booleans with 'seboolean’. However, there’s a few things missing:

*   SELinux user and role mappings
  *   Port labels (only supported in base policy or changed with semanage like so: semanage port -a -t httpd_port_t -p tcp 6312)
  *   Custom file labels (ie. semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?")

I know these can be imported and exported with semanage using the -i and -o flags, however it’s slow and doesn't easily facilitate the programmatic query and enforcement of these settings at scale using a tool like puppet. Ideally puppet could manage the .local files in /etc/selinux/targeted/modules/active/, however Red Hat support tells me this won’t work and that semanage is the only supported mechanism. Surely there’s someone in the community who has a non-hackish method of dealing with this?

Is FreeIPA the solution to the user and role mappings? What about the labels?

Thanks,
Doug

--
selinux mailing list
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/selinux

Why is managing this content via semanage not a good thing?

semanage is great for general administration but not for compliance; it's not really designed to compare an expected configuration with running configuration, and rectify any differences, rather, for the most part applies cumulative changes.

BTW You can put multiple ops within a transaction, which speeds up semanage.

https://danwalsh.livejournal.com/41593.html

The openstack-selinux rpm package has a bunch of operations being done within a transaction, including setting network ports, booleans and default file labeling.

BTW Ansible is also a nice method for managing SELinux in the enterprise.

Here is an presentation I wrote on managing SELinux in the enterprise

https://fedorapeople.org/~dwalsh/SELinux/Presentations/SummitSELinuxEnterpri...

If we take the approach of importing all local customisations from a file with semanage, will it reapply each of the customisations in that file every time puppet runs it, or will it only apply the difference? (I.e. most of the time, there should not be any difference so semanage won't recompile the running config)

How would we remove a config previously applied by semanage in this way?

Cheers,
Doug

[Mark Montague]

On 2014-10-12 6:14, Douglas Brown wrote:
> semanage is great for general administration but not for compliance; 
> it's not really designed to compare an expected configuration with 
> running configuration, and rectify any differences, rather, for the 
> most part applies cumulative changes.

I use a cron job that runs "semanage -o" to dump the current 
configuration and compare it, using diff, with the expected 
configuration which is just the output of "semanage -o -" manually 
generated by an administrator at the last time the configuration was 
changed.

The same cronjob also checks the output of sestatus and "semodule -l" 
against expected values.

This approach is primitive, but it works.  You could hash the output, if 
you wanted, and compare the hash instead of using diff. I use diff in 
order to have the cron job email the administrator the diff output, 
showing how the actual configuration is different from the expected 
configuration in the alert.

[Jeremy Young]

I'll second the cron option.  If you're like me and have only recently
gotten sign-off for a tool like Puppet or Ansible, scripts and crons will
still work while you transition to the CM tool.  For example, I'll run this
in cron.hourly to maintain a consistent state of the booleans available.
It may not be perfect, but it's a nice go-between until we can finish
implementing Puppet.

#!/bin/bash
## Use lists in /etc/selinux to set SELinux booleans to desired state

PREFIX=/etc/selinux
LOGFILE=/var/log/sebooleans

touch ${LOGFILE}
for state in on off; do
cat ${PREFIX}/booleans$state | while read variable; do
                ## getsebool is a lot faster than semanage for this task
if [[ "$( getsebool $variable | gawk '{print $3}' )" != "$state" ]]; then
 ## If we're running the script manually, output info to the screen
if [[ -z "$PS1" ]]; then
echo "Setting $variable to $state..."
fi

echo "Setting $variable to $state at $( date +%c )..." >> ${LOGFILE}
setsebool -P $variable $state
fi
done
done

I like the idea of a hash comparison.  After the required action is taken,
hash the relevant file and store it somewhere for reference later.  Have
Puppet execute your script, first hashing the relevant file and comparing
it to your known value from last time.  So, for your original question, the
files modules/active/users.local and modules/active/seusers.final could
provide you with the information that you'd want.

If that's no good, maybe you grep through these files to confirm the
existence of your customizations, and for every one that is missing, append
it to a temporary file, executing only the required commands with one
semanage.

On Sun, Oct 12, 2014 at 9:49 AM, Mark Montague  wrote:
> On 2014-10-12 6:14, Douglas Brown wrote:
>
> semanage is great for general administration but not for compliance; it's
> not really designed to compare an expected configuration with running
> configuration, and rectify any differences, rather, for the most part
> applies cumulative changes.
>
> I use a cron job that runs "semanage -o" to dump the current configuration
> and compare it, using diff, with the expected configuration which is just
> the output of "semanage -o -" manually generated by an administrator at the
> last time the configuration was changed.
>
> The same cronjob also checks the output of sestatus and "semodule -l"
> against expected values.
>
> This approach is primitive, but it works.  You could hash the output, if
> you wanted, and compare the hash instead of using diff.  I use diff in
> order to have the cron job email the administrator the diff output, showing
> how the actual configuration is different from the expected configuration
> in the alert.
>
> --
>   Mark Montague
>   [e-mail]
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Douglas Brown]

Thanks to those who have replied. I’ve looked at the semanage python library that underpins the semanage tool, and created a hello world with it; as with anything Python, it’s straightforward.

Mandatory Access Controls have strong theoretical foundations in set theory and Python has native support for sets, so my idea is to create a tool called ‘secompliance’ that can be run by cron/puppet/etc to diff the running and expected config using set operators then resolve conflicts as appropriate. Naturally, if it comes off, I will provide it to the community.

Cheers,
Doug

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeremy Young
Sent: Monday, 13 October 2014 3:09 AM
To: Mark Montague
Cc: [e-mail]
Subject: Re: Managing SELinux in the Enterprise

I'll second the cron option.  If you're like me and have only recently gotten sign-off for a tool like Puppet or Ansible, scripts and crons will still work while you transition to the CM tool.  For example, I'll run this in cron.hourly to maintain a consistent state of the booleans available.  It may not be perfect, but it's a nice go-between until we can finish implementing Puppet.

#!/bin/bash
## Use lists in /etc/selinux to set SELinux booleans to desired state

PREFIX=/etc/selinux
LOGFILE=/var/log/sebooleans

touch ${LOGFILE}
for state in on off; do
            cat ${PREFIX}/booleans$state | while read variable; do
                ## getsebool is a lot faster than semanage for this task
                        if [[ "$( getsebool $variable | gawk '{print $3}' )" != "$state" ]]; then

## If we're running the script manually, output info to the screen
                                    if [[ -z "$PS1" ]]; then
                                                echo "Setting $variable to $state..."
                                    fi

echo "Setting $variable to $state at $( date +%c )..." >> ${LOGFILE}
                                    setsebool -P $variable $state
                        fi
            done
done

I like the idea of a hash comparison.  After the required action is taken, hash the relevant file and store it somewhere for reference later.  Have Puppet execute your script, first hashing the relevant file and comparing it to your known value from last time.  So, for your original question, the files modules/active/users.local and modules/active/seusers.final could provide you with the information that you'd want.

If that's no good, maybe you grep through these files to confirm the existence of your customizations, and for every one that is missing, append it to a temporary file, executing only the required commands with one semanage.

On Sun, Oct 12, 2014 at 9:49 AM, Mark Montague <[e-mail]> wrote:
On 2014-10-12 6:14, Douglas Brown wrote:
semanage is great for general administration but not for compliance; it's not really designed to compare an expected configuration with running configuration, and rectify any differences, rather, for the most part applies cumulative changes.

I use a cron job that runs "semanage -o" to dump the current configuration and compare it, using diff, with the expected configuration which is just the output of "semanage -o -" manually generated by an administrator at the last time the configuration was changed.

The same cronjob also checks the output of sestatus and "semodule -l" against expected values.

This approach is primitive, but it works.  You could hash the output, if you wanted, and compare the hash instead of using diff.  I use diff in order to have the cron job email the administrator the diff output, showing how the actual configuration is different from the expected configuration in the alert.

--

Mark Montague

[e-mail]

--
selinux mailing list
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/selinux

--
Jeremy Young, M.S., RHCSA

[Lukas Zapletal]

> The openstack-selinux rpm package has a bunch of operations being done
> within a transaction, including setting network ports, booleans and
> default file labeling.

Dan, would you mind sharing the URL/git repo link? I was only able to
find the policy itself, I'd like to see the SPEC file. I don't see any
content in the fedora distgit.

We (Satellite 6 / Foreman) team take several approach, which was
initially inspired from Satellite 5 / Spacewalk. We also put things into
transactions and stuff. I'd like to compare with OpenStack if we can
improve.

https://github.com/theforeman/foreman-selinux

Thanks!

[Daniel J Walsh]

Ryan can you attach the opestack-selinux.spec file we worked on a couple
of weeks ago.  Or give us a link were you can find it.

On 10/13/2014 08:33 AM, Lukas Zapletal wrote:
> > The openstack-selinux rpm package has a bunch of operations being done
> > within a transaction, including setting network ports, booleans and
> > default file labeling.
>
> Dan, would you mind sharing the URL/git repo link? I was only able to
> find the policy itself, I'd like to see the SPEC file. I don't see any
> content in the fedora distgit.
>
> We (Satellite 6 / Foreman) team take several approach, which was
> initially inspired from Satellite 5 / Spacewalk. We also put things into
> transactions and stuff. I'd like to compare with OpenStack if we can
> improve.
>
> https://github.com/theforeman/foreman-selinux
>
> Thanks!

[Daniel J Walsh]

Here is the patch that has sped up the installing of selinux policy 10
times for openstack.

If you are making lots of changes to selinux policy, you should always
use a transaction.

On 10/17/2014 03:18 PM, Daniel J Walsh wrote:
> Ryan can you attach the opestack-selinux.spec file we worked on a couple
> of weeks ago.  Or give us a link were you can find it.
>
> On 10/13/2014 08:33 AM, Lukas Zapletal wrote:
> > > The openstack-selinux rpm package has a bunch of operations being done
> > > within a transaction, including setting network ports, booleans and
> > > default file labeling.
> >
> > Dan, would you mind sharing the URL/git repo link? I was only able to
> > find the policy itself, I'd like to see the SPEC file. I don't see any
> > content in the fedora distgit.
> >
> > We (Satellite 6 / Foreman) team take several approach, which was
> > initially inspired from Satellite 5 / Spacewalk. We also put things into
> > transactions and stuff. I'd like to compare with OpenStack if we can
> > improve.
> >
> > https://github.com/theforeman/foreman-selinux
> >
> > Thanks!