[refpolicy] FW: Add support for the samhain program

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

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.

> 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]
>> >
>> > So these two domain w ould 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.
>>
> 
> Right, thanks a lot! Template is the right choice to collect all those
> common rules for both domains no matter started by command line or init
> script, then I could grant each domain different privileges against the
> signature database.
> 
> Please see my attached v5 patch, it's really exciting to be able to make
> use of the template for the very first of my time :-)
> 
> Have a nice day!
> 
> Best regards,
> Harry

> +## <summary>Samhain - check file integrity</summary>
> +
> +#######################################
> +## <summary>
> +##	The template containing the most basic rules
> +##	common to the samhain domains.
> +## </summary>
> +## <param name="samhaindomain_prefix">
> +##	<summary>
> +##	The prefix of the samhain domain(e.g., samhain
> +##	for the domain of command line access, samhaind
> +##	for the domain started by init script).
> +##	</summary>
> +## </param>
> +## <rolebase/>
> +#
> +template(`samhain_service_template',`
> +	gen_require(`
> +		type etc_t, samhain_etc_t;
> +		type samhain_log_t, samhain_var_run_t;
> +	')
> +
> +	allow $1_t self:capability { dac_override dac_read_search fowner ipc_lock };
> +	dontaudit $1_t self:capability sys_resource;
> +	allow $1_t self:fd use;
> +	allow $1_t self:process { setsched setrlimit signull };
> +
> +	read_files_pattern($1_t, etc_t, samhain_etc_t)
> +
> +	kernel_getattr_core_if($1_t)
> +
> +	corecmd_list_bin($1_t)
> +	corecmd_read_bin_symlinks($1_t)
> +
> +	dev_read_urand($1_t)
> +	dev_dontaudit_read_rand($1_t)
> +
> +	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.

> +	auth_read_login_records($1_t)
> +
> +	dev_getattr_all_blk_files($1_t)
> +	dev_getattr_all_chr_files($1_t)
> +	dev_getattr_generic_blk_files($1_t)
> +	dev_getattr_generic_chr_files($1_t)
> +
> +	files_getattr_all_dirs($1_t)
> +	files_getattr_all_files($1_t)
> +	files_getattr_all_symlinks($1_t)
> +
> +	files_getattr_all_pipes($1_t)
> +	files_getattr_all_sockets($1_t)
> +	files_getattr_all_mountpoints($1_t)
> +
> +	files_read_all_files($1_t)
> +	files_read_all_symlinks($1_t)
> +
> +	init_read_utmp($1_t)
> +
> +	fs_getattr_all_dirs($1_t)
> +
> +	logging_send_syslog_msg($1_t)
> +
> +	userdom_use_user_terminals($1_t)

I would not expect this access for samhaind_t.

[cut]
> diff --git a/policy/modules/services/samhain.te b/policy/modules/services/samhain.te
> new file mode 100644
> index 0000000..40a4e70
> --- /dev/null
> +++ b/policy/modules/services/samhain.te
> @@ -0,0 +1,56 @@
> +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)
> +
> +# Domain for samhain service started by samhain init script
> +type samhaind_t;
> +type samhain_exec_t;
> +init_ranged_daemon_domain(samhaind_t, samhain_exec_t, mls_systemhigh)
> +samhain_service_template(samhaind)
> +
> +# Domain for command line access
> +type samhain_t;
> +application_domain(samhain_t, samhain_exec_t)
> +samhain_service_template(samhain)
> +
> +########################################
> +#
> +# Samhain local policy
> +#
> +
> +manage_files_pattern(samhain_t, samhain_db_t, samhain_db_t)
> +files_var_lib_filetrans(samhain_t, samhain_db_t, { file dir })
> +
> +########################################
> +#
> +# Samhaind local policy
> +#
> +
> +allow samhaind_t self:capability sys_ptrace;

This can most likely be dontaudited.

> +# 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?

> +# 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