On 08/11/12 04:45, nore...@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.
> +
>
_______________________________________________
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs
