Try running it in enforcing and document the application failures you get together with their denials. And see if allowing it fixes that particular problem. If you just give a list with rules and say "this is needed" there is a realistic chance that I can't get it upstreamed. On Oct 25, 2012 12:24 AM, "Stan Sander" <[email protected]> wrote:
> On 10/24/2012 08:46 AM, Sven Vermeulen wrote: > > On Tue, Oct 23, 2012 at 12:50:22PM -0600, Stan Sander wrote: > >> This is the invalid context that I think I need to address: > >> > >> Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983): > >> security_compute_sid: invalid context stan:system_r:initrc_t for > >> scontext=stan:sysadm_r:sysadm_t > >> tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process > >> > > Meh, > > > > Seems my reply didn't hit the list first. > > > > You probably forgot to add in the system_r role to the SELinux user, see > > > http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=1#serviceadmin > > > > Wkr, > > Sven Vermeulen > > Thanks, asterisk now starts with SELinux enforcing. However, it did > produce some new denials, two of which I believe impact the correct > running of the daemon and associated scripts, etc. Here are all the > denials generated at startup: > > Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.194:8824301): > avc: denied { entrypoint } for pid=14590 comm="runscript.sh" > path="/bin/rm" dev="sda3" ino=6837732 scontext=stan:system_r:initrc_t > tcontext=system_u:object_r:bin_t tclass=file > Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824302): > avc: denied { read write } for pid=14592 comm="asterisk" > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t > tcontext=stan:object_r:user_devpts_t tclass=chr_file > Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824303): > avc: denied { read write } for pid=14592 comm="asterisk" > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t > tcontext=stan:object_r:user_devpts_t tclass=chr_file > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.462:8824304): > avc: denied { write } for pid=14669 comm="runscript.sh" > name="wrapper_loop.pid" dev="sda3" ino=6422541 > scontext=stan:system_r:initrc_t > tcontext=stan:object_r:asterisk_var_run_t tclass=file > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824305): > avc: denied { read write } for pid=14670 comm="asterisk" > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t > tcontext=stan:object_r:user_devpts_t tclass=chr_file > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824306): > avc: denied { read write } for pid=14670 comm="asterisk" > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t > tcontext=stan:object_r:user_devpts_t tclass=chr_file > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.469:8824307): > avc: denied { setattr } for pid=14670 comm="asterisk" name="asterisk" > dev="sda3" ino=6446976 scontext=stan:system_r:asterisk_t > tcontext=system_u:object_r:asterisk_var_run_t tclass=dir > > > > The write denial for the wrapper_loop.pid file will lead to trouble, and > the denial for setattr on the /var/run/asterisk directory has the > potential (IMHO) to get us off in the weeds. The others, AFAICT are > candidates for dontaudit rules. Based on the above, it seems initrc_t > needs to be allowed to write asterisk_var_run_t files. Since > runscript.sh is trying to write the pid, I really don't see any > alternatives. I believe it needs this info to properly signal the > wrapper for a graceful daemon stoppage. The last denial (for setattr) > is trying to ensure 770 permissions on /var/run/asterisk and likely user > and group ownership also. > > I can throw a couple rules at this in a local policy module, and let > this run for a few days to see if anything else pops out, then file what > I find in a bug against the policy module. > > -- > Stan & HD Tashi Grad 10/08 Edgewood, NM SWR > PR - Cindy and Jenny - Sammamish, WA NWR > http://www.cci.org > > >
