[CentOS-docs] [CentOS Wiki] Update of "HowTos/SELinux" by kirkbocek

Thu Nov 8 16:47:53 UTC 2012
Ned Slider <ned at unixmail.co.uk>

On 08/11/12 04:45, noreply at centos.org wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "CentOS Wiki" for change notification.
>
> The following page has been changed by kirkbocek:
> http://wiki.centos.org/HowTos/SELinux?action=diff&rev2=29&rev1=28
>
> The comment on the change is:
> Added the User Notes and Gotchas Section
>
> ------------------------------------------------------------------------------
>
>    http://danwalsh.livejournal.com/
>
> + == User Notes and Gotchas ==
> +
> + This section is provided by a user who learned most of what he knows of SELinux from this document. This document is a wonderful and detailed resource. However, it is somewhat dry. It misses a couple of practical points I found rather frustrating as I tried to actually get stuff done.
> +
> +  1. ''semanage'' is found in the package ''policycoreutils-python'' which is not installed by default. Note there is a separate ''policycoreutils'' package.

This doc was written for CentOS 5. There are large differences between 
CentOS 5 and 6. This is one of them. The policycoreutils-python package 
doesn't exist on CentOS 5 and semanage is indeed provided by 
policycoreutils.

I've asked before and I'll say it again - we need a policy for dealing 
with documentation changes between 5 and 6.

I've not checked for errors further into this commit.

> +  1. Finding the right context to use as you manage a system is difficult. One place to start is ''ls -Z''. Look at the directories and data pre-installed by a package and copy the contexts already used. The next tool is ''seinfo -t'' which lists all contexts currently in use on your system. grep for the name of your application.
> +  1. ''audit2allow'' is actually easier to use than presented here. When you have a conflict between two contexts, find the error messages in ''audit.log'' and extract them to a separate text file. Feed the errors back to ''audit2allow'' like this:
> + {{{
> + audit2allow -M mynewpolicyname<errors.txt}}}
> +  What will be generated is ''mynewpolicyname.te'' and ''mynewpolicyname.pp'' along with helpful instructions on how to import the new policy. This new policy will enable whatever was previously conflicting.
> +
> +  I discovered this process attempting to get a script running under postfix that was previously installed on a non-SELinux system. Under SELinux, the script needs to run under the ''postfix_pipe_exec_t'' context and it's spooling directory needs the ''postfix_pipe_tmp_t'' context. However the script also calls the ''spamc'' binary of ''spamassassin'' for processing. Alas, this binary runs under ''spamc_t'' and thus couldn't read or write into the spool directory.
> +
> +  After executing this process we get a ''.te'' file that looks like this:
> + {{{
> + module mynewpolicy 1.0;
> +
> + require {
> +         type spamc_t;
> +         type postfix_pipe_tmp_t;
> +         class file { read write };
> + }
> +
> + #============= spamc_t ==============
> + allow spamc_t postfix_pipe_tmp_t:file { read write };
> + }}}
> +  If you look at the last line, this policy allows the ''spamc_t'' context to read and write files in the ''postfix_pipe_tmp_t'' context. ''spamassassin'' now works as before.
> +
>