From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Fri, 19 Nov 2010 10:20:36 -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> Message-ID: <4CE695C4.5020501@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 11/18/10 01:33, HarryCiao wrote: > Many thanks Chris! Please see my inline responses and the attached v4 of > samhain.pp. > >> Date: Wed, 17 Nov 2010 09:02:40 -0500 >> From: cpebenito at tresys.com >> >> On 11/16/10 02:11, HarryCiao wrote: >> > From 05eb3e1893917d5fbc83daddd37edb003281bd1d Mon Sep 17 00:00:00 2001 >> > From: Harry Ciao >> > Date: Mon, 8 Nov 2010 14:42:38 +0800 >> > Sub ject: [v3 PATCH 1/1] Add support for the samhain program. >> > >> > Note, extra privileges may need to be granted to the samhain domain >> > if its configuration file(/etc/samhainrc) is changed. >> > >> > The samhain program could be used in the following way: >> > >> > (In secadm_r role) >> > 1. Initialize filesystem signature database: >> > newrole -l s15:c0.c1023 -p -- -c "samhain -t init" >> > >> > 2. Start samhain deamon to check filesystem integrity >> > newrole -l s15:c0.c1023 -p -- -c "samhain -t check -D" >> > >> > 3. Update filesystem signature database: >> > newrole -l s15:c0.c1023 -p -- -c "samhain -t update" >> >> Sounds like there needs to be a range_transition in the run interface. > > 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 :-) 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. > Also, if we don't use above range_transition rule in the run interface, > I guess having samhain executable labeled as mls_systemhigh as I used to > do could also enforce the calling domain to have the clearance level. No. There is not any sensitive info in the executable, so it should be s0. [cut] >> > +interface(`samhain_admin',` >> > + gen_require(` >> > + type samhain_t, samhain_db_t, samhain_etc_t; >> > + type samhain_initrc_exec_t, samhain_log_t, samhain_var_run_t; >> > + ') >> > + >> > + allow $1 samhain_t:process { ptrace signal_perms }; >> > + ps_process_pattern($1, samhain_t) >> > + >> > + files_list_var_lib($1) >> > + admin_pattern($1, samhain_db_t) >> > + >> > + files_list_etc($1) >> > + admin_pattern($1, samhain_etc_t) >> > + admin_pattern($1, samhain_initrc_exec_t) >> > + >> > + logging_list_logs($1) >> > + admin_pattern($1, samhain_log_t) >> > + >> > + files_list_pids($1) >> > + admin_pattern($1, samhain_var_run_t) >> > + >> > + mls_file_write_all_levels($1) >> >> No. The caller needs to pass MLS constraints on its own. This is too >> big of a privilege. >> > > Very honestly speaking, I have been kinda worried about this too! > > This interface is expecting the calling domain able to do the following > things on its own: > 1. able to remove an entry from {var_log_t var_lib_t} : dir; > 2. able to remove an entry of the clearance level from above dir which > are of s0. > > Sadly so far neither secadm nor sysadm could have a full control over > samhain files. With the mls_systemhigh level the sysadm could remove > samhain_file from /var/lib/samhain/, but can't remove samhain_log from > /var/log/, since the latter is of s0. I guess we would have to fall back > on the permissive mode if we really want to remove it. Directories that have data with mixed levels are problematic :\ Perhaps we should reconsider the MLS constraints of ranged directories. > Also considering that the sysadm has already been able to manage all > files and dirs except shadow_t, calling samhain_admin(sysadm_t) would be > kinda redundant. > >> > +') >> > diff --git a/policy/modules/services/samhain.te > b/policy/modules/services/samhain.te >> ; > new file mode 100644 >> > index 0000000..612795f >> > --- /dev/null >> > +++ b/policy/modules/services/samhain.te >> > @@ -0,0 +1,114 @@ >> > +policy_module(samhain, 1.0.0) >> > + >> > +######################################## >> > +# >> > +# Declarations >> > +# >> > + >> > +type samhain_etc_t; >> > +files_config_file(samhain_etc_t) >> > + >> > +type samhain_log_t; >> > +logging_log_file(samhain_log_t) >> > + >> > +# Filesystem signature database >> > +type samhain_db_t; >> > +files_type(samhain_db_t) >> > + >> > +type samhain_initrc_exec_t; >> > +init_script_file(samhain_initrc_exec_t) >> > + >> > +type samhain_var_run_t; >> > +files_pid_file(samhain_var_run_t) >> > + >> > +type samhain_t; >> > +type samhain_exec_t; >> > +init_rang ed_daemon_domain(samhain_t, samhain_exec_t, mls_systemhigh) >> >> Needs a new domain. There should be a domain for this as a service, and >> a domain for command line access. Then hopefully that should allow the >> service to only be allowed read-only access to the database. > > I see your point here. > > The "domain for command line access" is to create the samhain database, > while the "domain for samhain service" needs only to read from the > database file. > > It would be great if we could have these two domains separated from each > other. However, when the command line access domain is creating the > database, it needs to getattr or read almost all kinds of files on the > system, requiring exactly the same set of privileges granted to the > service domain when performing the filesystem signature check. Moreover, > the samhain service could be started not only by its init script, but > also by the command line, by specifying the "samhain -t check - D" while > "-D" means running as daemon or by specifying "daemon = yes" in samhain > config files. > > So these two domain would have a lot of rules in common and it would > greatly simplify our life if we keep them as one. Using an attribute would make it easier. Create two domains having a common attribute, and then add the common rules to the attribute. Alternatively, you could use a template. The key thing here is the database. We only want it writeable when its intended, which is when its run interactively to create/update it. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com