[refpolicy] FW: Add support for the samhain program

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

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

>> Date: Tue, 30 Nov 2010 10:07:15 -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 11/22/10 05:57, HarryCiao wrote:
>> > Hi Chris,
>> >
>> > Please see my inline responses, thanks!
>>
>> I have additional comments inline.
>>
>> > [cut]
>> >> >
>> >> > Right, I have added below range_transition rule to the samhain_run()
>> >> > interface to enforce the samhain domain to run in the clearance se
>> >> > curity level:
>> >> >
>> >> > ifdef(`enable_mls', `
>> >> > range_t ransition $1 samhain_exec_t:process mls_systemhigh;
>> >> > ')
>> >> >
>> >> > However, since secadm_t does not belong to the mlsprocsetsl nor
>> >> > privrangetrans attribute, the MLS constraint for process
> transition will
>> >> > fail if the secadm is trying to run samhain in s0 in the command
> line,
>> >> > so secadm would still have to fallback on the newrole program to
> switch
>> >> > to the clearance level.
>> >> > But, above range_transition rule would enforce the samhain domain
>> >> > running with the clearance level, I think it's desirable to have it
>> > :-)< br>>
>> >> After thinking about this some more, the level change should
> probably be
>> >> an active decision, so we should skip the range_transition. Theres also
>> >> the problem that if the user and it's terminal are, for example,
> system
>> >> low, then they run samhain at system high, samhain won't be able to
>> >> write to the terminal.
>> >>
>> >
>> > Well, I see you point, and I still want to preserve the range_transition
>> > there in the samhain_run interface, which could enforce the samhain
>> > domain running in mls_systemhigh, which in turn I think is the only way
>> > to ensure the samhain log files or data base files to be of
>> > mls_systemhigh too. (BTW do we have range_transition rule for files?)
>>
>> Range transitions work on files too, but that would definitely not be an
>> appropriate solution to make sure the files have the right sensitivity
>> if the application is running in the wrong domain.
>>
> 
> Yeah, you're right, the newly created file should share the same
> security level with its creator process.
> 
> 
>> > Well, since samhain would have to create and write to its log files to
>> > /var/log/ which is of s0, I have granted it the mlsfilewrite attribute,
>> > so it will be fine to run on user_devpts_t:s0 already :-)
>> >
>> >
> [cut]
>> > +
>> > + domain_use_interactive_fds($1_t)
>> > +
>> > + manage_files_pattern($1_t, samhain_var_run_t, samhain_var_run_t)
>> > + files_pid_filetrans($1_t, samhain_var_run_t, file)
>>
>> Does samhain_t really need manage acccess? I would think it would just
>> need to read the pid file.
>>
>> > + manage_files_pattern($1_t, samhain_log_t, samhain_log_t)
>> > + logging_log_filetrans($1_t, samhain_log_t, file)
>>
>> Similarly, does the command line version also log to the log files?
>>
>> > + mls_file_write_all_levels($1_t)
>>
>> If the above write accesses for the pid and log files should be dropped
>> for the command line, then this likely should be too.
>>
> 
> Yeah, both samhain_t and samhaind_t would need to manage the log,
> log.lock and pid files, since no matter how the samhain daemon is
> started, both domains would have to create log.lock and pid files on
> start and remove them on stop. Since log.lock and pid files are in
> /var/log/ or /var/run/ of s0 while samhain daemons are in
> mls_systemhigh, we have to add them to mlsfilewrite attribute.
> 
> 
> [cut]
>> > + userdom_use_user_terminals($1_t)
>>
>> I would not expect this access for samhaind_t.
> 
> Yep, both domain_use_interactive_fds() and userdom_use_user_terminals()
> would be unnecessary for samhaind_t that don't have to interact with the
> user. So I've removed them from the samhain_service_template() and have
> the called for samhain_t only.
> 
>  [cut]
>> > +########################################
>> > +#
>> > +# Samhaind local policy
>> > +#
>> > +
>> > +allow samhaind_t self: capability sys_ptrace;
>>
>> This can most likely be dontaudited.
> 
> Thanks!
> 
>>
>> > +# Need signal_perms to send SIGABRT/SIGKILL to termiate the samhain
> daemon
>> > +allow samhaind_t { samhain_t self }:process signal_perms;
>>
>> The daemon needs to signal the command line version?
>>
> 
> Yes, I am afraid so. Without the signull permission the samhaind_t
> domain would fail to get the status of samhain_t domain, although the
> latter has been started already:
> 
> root at qemu-host:/root> run_init /etc/init.d/samhain status
> Authenticating root.
> Password:
> type=1400 audit(1291456018.568:143): avc:  denied  { signull } for 
> pid=1277 comm="samhain"
> scontext=system_u:system_r:samhaind_t:s15:c0.c1023
> tcontext=root:secadm_r:samhain_t:s15:c0.c1023 tclass=process
> Service samhain: Stopped and /var/run pid file exists
> root at qemu-host:/root>
> root at qemu-host:/root> newrole -l s15:c0.c1023 -p -- -c "ps -eZ | grep
> samhain"
> Password:
> root:secadm_r:samhain_t:s15:c0.c1023 1370 ?    00:01:04 samhain
> root at qemu-host:/root>
> 
>> > +# Only needed when starting samhain daemon from its init script.
>> > +can_exec(samhaind_t, samhain_exec_t)
>> > +
>> > +read_files_pattern(samhaind_t, samhain_db_t, samhain_db_t)
>>
>>
>> --
>> Chris PeBenito
>> Tresys Technology, LLC
>> www.tresys.com | oss.tresys.com


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com