Hi all,
In Gentoo, we have a setup for our init system where various scripts are all
wrappers on top of /sbin/rc. Now, the /sbin/rc binary itself needs to be
labeled initrc_exec_t (for the standard init stuff), but the scripts that
refer to it all have specific functionalities. The problem is that these
scripts do not present these functionalities - they just call /sbin/rc with
the option that tells the rc binary how it should behave.
When these scripts are labeled bin_t, then any call of these scripts results
in the action to run in the run_init_t domain:
sysadm_t -(bin_t)-> sysadm_t -(initrc_exec_t)-> run_init_t
Most of these scripts however do not need to run in the run_init_t domain.
As a matter of fact, the script should run in the current domain.
What I have devised, but which I find ugly (almost to the point that I was
reluctant to share ;-) is to create an intermediate domain which, when
executing initrc_exec_t, transitions back to the original domain, like so:
sysadm_t -(bin_t)-> sysadm_initrc_notrans_t -(initrc_exec_t)-> sysadm_t
At first, I made that intermediate domain through a template() definition
(in this case within init.if) but that has the issue that, if you need to
create some additional privileges (like allowing file descriptor usages) you
don't have "control" over the type (iow, you'd need to give the rights in a
.te file where the specific type isn't declared).
So now, my idea is to create the type definition locally, and then call an
interface which makes the necessary transition rules.
What's your guys' take on this?
Some sample code for those that read that better than my pidgin english...
type sysadm_initrc_notrans_t;
init_initrc_notrans(sysadm_initrc_notrans_t, sysadm_t)
+template(`init_initrc_notrans',`
+ gen_require(`
+ type initrc_exec_t;
+ type initrc_notrans_exec_t;
+ ')
+
+ application_domain($1, initrc_notrans_exec_t)
+
+ ###########################################
+ #
+ # Local policy
+ #
+
+ domain_use_interactive_fds($1)
+ userdom_use_user_terminals($1)
+
+ domtrans_pattern($2, initrc_notrans_exec_t, $1)
+ domain_entry_file($2, initrc_exec_t)
+
+ domtrans_pattern($1, initrc_exec_t, $2)
+ corecmd_exec_shell($1)
+')
Wkr,
Sven Vermeulen
On 07/20/11 13:08, Sven Vermeulen wrote:
> In Gentoo, we have a setup for our init system where various scripts are all
> wrappers on top of /sbin/rc. Now, the /sbin/rc binary itself needs to be
> labeled initrc_exec_t (for the standard init stuff), but the scripts that
> refer to it all have specific functionalities. The problem is that these
> scripts do not present these functionalities - they just call /sbin/rc with
> the option that tells the rc binary how it should behave.
Quite unfortunate.
> When these scripts are labeled bin_t, then any call of these scripts results
> in the action to run in the run_init_t domain:
> sysadm_t -(bin_t)-> sysadm_t -(initrc_exec_t)-> run_init_t
>
> Most of these scripts however do not need to run in the run_init_t domain.
> As a matter of fact, the script should run in the current domain.
>
> What I have devised, but which I find ugly (almost to the point that I was
> reluctant to share ;-) is to create an intermediate domain which, when
> executing initrc_exec_t, transitions back to the original domain, like so:
> sysadm_t -(bin_t)-> sysadm_initrc_notrans_t -(initrc_exec_t)-> sysadm_t
>
> At first, I made that intermediate domain through a template() definition
> (in this case within init.if) but that has the issue that, if you need to
> create some additional privileges (like allowing file descriptor usages) you
> don't have "control" over the type (iow, you'd need to give the rights in a
> .te file where the specific type isn't declared).
>
> So now, my idea is to create the type definition locally, and then call an
> interface which makes the necessary transition rules.
>
> What's your guys' take on this?
That definitely is horribly ugly.
Here's something you can try. Make a new type, eg rc_exec_t, and label
/sbin/rc with it. Make it so when init execs it, it goes to initrc_t,
and initrc_t and sysadm_t have execute_no_trans.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com