[refpolicy] FW: Add support for the samhain program

[cpebenito@tresys.com (Christopher J. PeBenito)]

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