From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Wed, 15 Dec 2010 14:08:14 -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> Message-ID: <4D09121E.1090807@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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