On 08/11/12 04:45, noreply@xxxxxxxxxx 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@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-docs
