On Mon, 2014-01-20 at 05:51 +0300, jiun bookworm wrote:
Let me try the question again, all init daemons are started with
the context specified at
[jiun@localhost ~]$ cat /etc/selinux/targeted/contexts/initrc_context
system_u:system_r:initrc_t:s0
is it possible to have my application specifically override this and
start with the full mcs range? you mentioned that
the init_t is able to do something like this because of some
mcsconstraints, what constraints are these?
iv tried these and they do not work:
init_ranged_daemon_domain(myapp_t,myapp_exec_t,s0 - mcs_systemhigh)
In theory the above should work maybe theres a small error somewhere
You should probably look more into the source policy for examples
mcs_process_set_categories(myapp_t);
Thats one of the available mcs interfaces. Theres more in the policy
seinfo -a | grep mcs
range_transition initrc_t myapp_exec_t:process s0:c0.c1023;
oh right, it should probably be:
range_transition init_t myapp_exec_t:process s0:c0.c1023;
So maybe init_ranged_daemon_domain() needed to be updated to reflect
systems.
But the idea is that init_ranged_daemon_domain() should work
On Mon, Jan 20, 2014 at 2:28 AM, Dominick Grift
<dominick.grift(a)gmail.com> wrote:
On Mon, 2014-01-20 at 01:42 +0300, jiun bookworm wrote:
> Dominick,
> thanks but you may have misunderstood my question, its not
the daemon
> that is confined to one category
> its the child processes that it spawns, previously when in
init_t
> the app could spawn processes and assign
>
> them categories, now it can not, when running under
myapp_t, what
> makes init_t or other types able to
> support mcs and myapp_t can not?
There are two options:
1. you run the parent with the full mcs range
2. you override mcs constraints for the parent using the
applicable mcs
type attributes
the latter is why init is allowed to do it but i recommend the
former
for your parent process