[refpolicy] FW: Add support for the samhain program

HarryCiao harrytaurus2002 at hotmail.com
Sat Dec 4 06:54:21 CST 2010


Hi Chris,

Thanks a lot for your comments, the attached is the v6 of samhain.pp. 

My replies are below.

Have a nice weekend!

Best regards,
Harry


> 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_transition $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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101204/cdaaed50/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v6-Add-support-for-the-samhain-program.patch
Type: text/x-patch
Size: 12451 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101204/cdaaed50/attachment-0001.bin 


More information about the refpolicy mailing list