From: harrytaurus2002@hotmail.com (HarryCiao) Date: Thu, 16 Dec 2010 10:17:53 +0000 Subject: [refpolicy] FW: Add support for the samhain program In-Reply-To: <4D09121E.1090807@tresys.com> References: , , , , <20101111121804.GA17316@localhost.localdomain>, , , , <20101112115307.GB21277@localhost.localdomain>, , , , <20101115123522.GE21277@localhost.localdomain>, , <4CE3E080.9070109@tresys.com> , <4CE695C4.5020501@tresys.com> , <4CF51323.7080007@tresys.com> , <4D09121E.1090807@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > Date: Wed, 15 Dec 2010 14:08:14 -0500 > From: cpebenito at tresys.com > To: harrytaurus2002 at hotmail.com > CC: domg472 at gmail.com; refpolicy at oss.tresys.com > Subject: Re: [refpolicy] FW: Add support for the samhain program > > On 12/04/10 07:54, HarryCiao wrote: > > Hi Chris, > > > > Thanks a lot for your comments, the attached is the v6 of samhain.pp. > > > > My replies are below. > > Merged. I did some additional cleanup, mainly reordering some > statements. I did have to fix the range transition so that it would > work on mcs systems > Hi Chris, Many thanks for endorsing samhain.pp to the upstream, you've made me very proud of my effort to keep improving it! Well, I've studied all your cleanups and I have a few questions or concerns that I would like to discuss with you further: 1. From the notes you left I knew that the call to the init_ranged_daemon_domain() has been replaced by init_ranged_system_domain(), in order to workaround some type transition conflict on MCS system. Honestly speaking I've tested just on MLS system but not MCS, so I am very curious about what the exact type transition conflict is? 2. Moreover, while I am testing the samhain.pp pulled from upstream today I run into two error messages by far: 2.1) root at qemu-host:/root> run_init /etc/init.d/samhain status Authenticating root. Password: type=1400 audit(1292488062.229:64): avc: denied { transition } for pid=991 comm="samhain" path="/usr/sbin/samhain" dev=sda ino=8425 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:samhaind_t:s15:c0.c1023 tclass=process /etc/init.d/samhain: line 291: /usr/sbin/samhain: Permission denied Service samhain: Status unknown root at qemu-host:/root> 2.2) type=1400 audit(1292490235.885:75): avc: denied { read write } for pid=1131 comm="samhain" path="/dev/pts/1" dev=devpts ino=4 scontext=system_u:system_r:samhaind_t:s15:c0.c1023 tcontext=system_u:object_r:initrc_devpts_t:s0 tclass=chr_file They are triggered since init_ranged_system_domain() won't go on to call mls_rangetrans_target() and init_use_script_ptys() interfaces as in the init_ranged_daemon_domain(). Without adding samhaind_t domain into the mlsrangetrans attribute the domain transition from initrc_t to samhaind_t would fail, making the samhain init script unable to control samhain_t daemon at all. So I guess if we have to fall back on the current init_ranged_system_domain(), we'd better call mls_rangetrans_target(samhaind_t) as well. As for the second error message, since the samhain init script would be started by the run_init tool, which calls open_init_pty to have the pty relabeled as init_devpts_t, I simply guess it would be the right thing to do to call init_use_script_ptys(samhaind_t). What do you think? thanks! Best regards, Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101216/359b032f/attachment-0001.html