From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 16 Dec 2010 08:28:04 -0500 Subject: [refpolicy] FW: Add support for the samhain program In-Reply-To: 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: <4D0A13E4.8020103@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/16/10 05:17, HarryCiao wrote: > > >> 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? Theres two things. I called it once on MCS and once on MLS since mls_systemhigh is not a valid level on MCS. The type transition conflict is hit when you turn on the DIRECT_INITRC option. > 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:&nbs p; 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_scr ipt_ptys(samhaind_t). > > What do you think? thanks! I'll add these rules. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com