how to transition a daemon to its own domain

[jiun bookworm]

I have been attempting to get my app to transition to a different domain
unsuccessfully,
what is wring with the following:

###############################TE file #############
########################################
#
# Declarations
#

require {
        type initrc_t;
}

type myapp_t;
type myapp_unit_file_t;
init_daemon_domain(myapp_t, myapp_unit_file_t);
allow initrc_t myapp_unit_file_t : file { read getattr execute open } ;
allow initrc_t   myapp_unit_file_t : file { ioctl read getattr lock execute
entrypoint open } ;
allow initrc_t myapp_t : process { transition siginh } ;

type myapp_exec_t;
files_type(myapp_exec_t);

allow initrc_t myapp_exec_t : file { read getattr execute open } ;
allow initrc_t   myapp_exec_t : file { ioctl read getattr lock execute
entrypoint open } ;
allow initrc_t myapp_t : process { transition siginh } ;


allow myapp_t self:fifo_file rw_fifo_file_perms;
allow myapp_t self:unix_stream_socket create_stream_socket_perms;

domain_use_interactive_fds(myapp_t)

#files_read_etc_files(myapp_t)

#miscfiles_read_localization(myapp_t)
#####################################################
########################END OF TE

#######################~INTERFACE#######
## <summary>policy for myapp</summary>

########################################
## <summary>
##      Execute TEMPLATE in the myapp domin.
## </summary>
## <param name="domain">
## <summary>
##      Domain allowed to transition.
## </summary>
## </param>
#
interface(`myapp_domtrans',`
        gen_require(`
                type myapp_t, myapp_exec_t;
        ')

        corecmd_search_bin($1)
        domtrans_pattern($1, myapp_exec_t, myapp_t)
##############################################
########################END OF INTERFACE#######################

and the other :

/appcl/myapp/apiservice.py                           --
gen_context(system_u:object_r:myapp_exec_t,s0)
/usr/lib/systemd/system/myapp.service                --
gen_context(system_u:object_r:myapp_unit_file_t,s0)


unfortunately it remains in  init_t   rather than  transition to mayapp_t,
which is my intention, but im wrong somewhere,  any help will be
appreciated.
here is some debug info:

# sesearch --allow -t myapp_t | grep transition
   allow initrc_t myapp_t : process { transition siginh } ;
   allow myapp_domain daemon : process transition ;

and there are no avc denials in the logs.  what do i do to correct?

----------------another question -------only for the patient---------------
For those who like reading alot here is where im going  with this:
My aim is to have the service interact over the network at a certain
unpriviledged port, and i can interact with it  over some REST interface,
and it can call some other programs with untrusted data an give back
results.
So far i was able to isolate different proceses that are launched by the
app from each other by using  mcs and using  runcon to set the level,
unfortunately everything is still running as
system_u:system_r:init_t:s0:cX,cY,    how can i have the child process run
with lower selinux priviledges?  like maybe :
system_u:system_r:sandbox_t:s0:cX,cY,
or another equivalent of sandbox? if i try
system_u:system_r:sandbox_t:s0:cX,cY  i get
invalid context error.

Jiun

[Dominick Grift]

On Fri, 2014-01-17 at 10:39 +0300, jiun bookworm wrote:
>  I have been attempting to get my app to transition to a different
>  domain unsuccessfully,  

>  
>  init_daemon_domain(myapp_t, myapp_unit_file_t); 
The transition does not go on myapp_unit_file_t instead it goes on
myapp_exec_t

>  type myapp_exec_t;
>  files_type(myapp_exec_t); 
So something like this to get started:

type myapp_t;
type myapp_exec_t;
init_daemon_domain(myapp_t, myapp_exec_t)

As for the unit file, not sure off the top of my head but something like
this:

type myapp_unit_file_t;
systemd_unit_file(systemd_unit_file_t)

The unit file does not get executed, just read. So the transition cant
go on that file

[jiun bookworm]

Thanks for that,
infortunately im still not there yet,
now the application runs in  initrc_t  (it  was  remaining in init_t)
this is how the policy looks like  (from your  and bigons advice):

########################################
#
# Declarations
#
require {
        type init_t;
}

type myapp_t;
type myapp_exec_t;
init_daemon_domain(myapp_t, myapp_exec_t)


######################
########################################
#
# myapp local policy
#
allow myapp_t self:fifo_file rw_fifo_file_perms;
allow myapp_t self:unix_stream_socket create_stream_socket_perms;

domain_use_interactive_fds(myapp_t)

#files_read_etc_files(myapp_t)

#miscfiles_read_localization(myapp_t)


i also tried to move the app to a more standard location,  as well as
labelled the python intepreter's parent directory
as bin_t  (its in a virtualenv),  im not sure what else to try,
if you have any more clues let me know






On Sat, Jan 18, 2014 at 10:15 PM, Dominick Grift
<dominick.grift(a)gmail.com&gt;wrote:

>  On Fri, 2014-01-17 at 10:39 +0300, jiun bookworm wrote:
>  > I have been attempting to get my app to transition to a different
>  > domain unsuccessfully,
>
>
>  >
>  > init_daemon_domain(myapp_t, myapp_unit_file_t);
>
>  The transition does not go on myapp_unit_file_t instead it goes on
>  myapp_exec_t
>
>  > type myapp_exec_t;
>  > files_type(myapp_exec_t);
>
>  So something like this to get started:
>
>  type myapp_t;
>  type myapp_exec_t;
>  init_daemon_domain(myapp_t, myapp_exec_t)
>
>  As for the unit file, not sure off the top of my head but something like
>  this:
>
>  type myapp_unit_file_t;
>  systemd_unit_file(systemd_unit_file_t)
>
>  The unit file does not get executed, just read. So the transition cant
>  go on that file
>
>
>

[Dominick Grift]

On Sun, 2014-01-19 at 09:19 +0300, jiun bookworm wrote:
>  Thanks for that, 
>  
>  infortunately im still not there yet,  
>  
>  now the application runs in  initrc_t  (it  was  remaining in init_t)
>  
>  this is how the policy looks like  (from your  and bigons advice): 
Make sure that the "daemon entry file" is labeled myapp_exec_t

so for example if the unit file has execstart=/usr/sbin/bla (or
whatever)

then: chcon -t myapp_exec_t /usr/sbin/bla

The transition happens on the daemon entry file so that must be labeled
accordingly (myapp_exec_t)

[jiun bookworm]

Dominick:

thanks,  i had overlooked the advice on the unit file in your first email,
but i went back to it and user enough it  helped,
but in the end  had to give the python intepreter the exec_t   label,
since its called  by the unit file (the .py file does not use shebang style
so its not called directly) viz   /path/to/python  /path/to/app.py

now im working on getting the new type to actually work,  im dealing with
strange socket connection errors that are not in the audit logs,  here is
what i have so far:



policy_module(myapp, 1.0.0)

########################################
#
# Declarations
#
require {
#        type init_t;
         type systemd_unit_file_t ;
         type urandom_device_t ;
         type etc_runtime_t ;
         type proc_t;
         type bin_t;
         type tmp_t;
         type user_home_dir_t;
         type user_home_t;
         type net_conf_t;
         type ldconfig_exec_t;
         type mongod_port_t;
}

type myapp_t;
type myapp_exec_t;
init_daemon_domain(myapp_t, myapp_exec_t)

type myapp_unit_file_t;
systemd_unit_file(systemd_unit_file_t)

########################################
allow myapp_t self:fifo_file rw_fifo_file_perms;
allow myapp_t self:unix_stream_socket create_stream_socket_perms;
allow myapp_t self:process signal;
allow myapp_t etc_runtime_t:file { read getattr open ioctl execute};
allow myapp_t proc_t:file { read open};
allow myapp_t bin_t:dir write;
allow myapp_t proc_t:file getattr;
allow myapp_t tmp_t:dir {write add_name};
allow myapp_t tmp_t:file {write open create};
allow myapp_t user_home_dir_t:dir { search getattr read open write
add_name};
allow myapp_t user_home_t:file { read open  getattr ioctl create};
allow myapp_t user_home_t:dir { read open search getattr };
allow myapp_t ldconfig_exec_t:file {execute  read open  execute_no_trans};
allow myapp_t net_conf_t:file { read  open   getattr ioctl};
allow myapp_t mongod_port_t:tcp_socket name_connect;

allow myapp_t self:tcp_socket { create setopt connect getattr getopt write
read bind append};
allow myapp_t self:udp_socket { create connect getattr getopt setopt write
read bind append};
allow myapp_t self:netlink_route_socket { create bind getattr write
nlmsg_read nlmsg_write read setattr lock getopt setopt append };


domain_use_interactive_fds(myapp_t)

#files_read_etc_files(myapp_t)

#miscfiles_read_localization(myapp_t)

#!!!! This avc can be allowed using the boolean 'global_ssp'
allow myapp_t urandom_device_t:chr_file {read open};


here is the  traceback that clueing me that there is something thats not
yet allowed thats no being logged to audit:

Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]: File
"/appcl/penv/lib/python3.3/site-packages/motor/__init__.py", line 809, in
open_sync
Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]: raise outcome['error']
Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]: File
"/appcl/penv/lib/python3.3/site-packages/motor/__init__.py", line 725, in
_connect
Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]: self.delegate =
self.__delegate_class__(*args, **kwargs)
Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]: File
"/appcl/penv/lib/python3.3/site-packages/pymongo/mongo_client.py", line
336, in __init__
Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]: raise
ConnectionFailure(str(e))
Jan 18 07:39:48 bookworm.saltminon01 myapp[19476]:
pymongo.errors.ConnectionFailure: [Errno 13] Permission denied



why does selinux not log these types of denials? i had to guess some
permissions that it needed like these to get past this point

allow latexapi_t self:tcp_socket { create setopt connect getattr getopt
write  read bind append};
allow latexapi_t self:udp_socket { create connect getattr getopt setopt
write read bind append};
allow latexapi_t self:netlink_route_socket { create bind getattr write
nlmsg_read nlmsg_write read setattr lock getopt setopt append };



regards



On Sun, Jan 19, 2014 at 6:56 PM, Dominick Grift <dominick.grift(a)gmail.com&gt;wrote:

>  On Sun, 2014-01-19 at 09:19 +0300, jiun bookworm wrote:
>  > Thanks for that,
>  >
>  > infortunately im still not there yet,
>  >
>  > now the application runs in  initrc_t  (it  was  remaining in init_t)
>  >
>  > this is how the policy looks like  (from your  and bigons advice):
>
>  Make sure that the "daemon entry file" is labeled myapp_exec_t
>
>  so for example if the unit file has execstart=/usr/sbin/bla (or
>  whatever)
>
>  then: chcon -t myapp_exec_t /usr/sbin/bla
>
>  The transition happens on the daemon entry file so that must be labeled
>  accordingly (myapp_exec_t)
>
>

[Dominick Grift]

On Sun, 2014-01-19 at 19:34 +0300, jiun bookworm wrote:

When you write a new policy always deal with potential transition cases
first.

domain transitions happen on execute and file transitions happen on
create

>  
>  allow myapp_t self:fifo_file rw_fifo_file_perms;
>  allow myapp_t self:unix_stream_socket create_stream_socket_perms;
>  allow myapp_t self:process signal;
>  allow myapp_t etc_runtime_t:file { read getattr open ioctl execute}; 
Above its mmapping a file with type etc_runtime_t. You should look at
the raw avc denials to see which file that is and where it is, then see
if its labeled appropriately. it should probably be labeled lib_t or
something

>  allow myapp_t proc_t:file { read open};
>  allow myapp_t bin_t:dir write; 
The above might be an access check. You should try to confirm that by
using audit to record this event and then look at the syscall.

>  allow myapp_t proc_t:file getattr;
>  allow myapp_t tmp_t:dir {write add_name};
>  allow myapp_t tmp_t:file {write open create}; 
The above file should be created with a type transition to a private
myapp_tmp_t files_tmp_file

>  allow myapp_t user_home_dir_t:dir { search getattr read open write
>  add_name};
>  allow myapp_t user_home_t:file { read open  getattr ioctl create};
>  allow myapp_t user_home_t:dir { read open search getattr }; 
The above don't quite add up. myapp is adding a directory entry and
writing to some directory in /home but without a type transition rule i
do not see how it can create the file with user_home_t.

You should analyze the raw avc denials related to the rules above to see
what exactly is happening and why 

>  allow myapp_t ldconfig_exec_t:file {execute  read open
>  execute_no_trans}; 
figure out what command exactly is executing it by looking at the raw
avc denials comm="" field

ldconfig should usually be run as is (e.g. without a domain transition)

>  allow myapp_t net_conf_t:file { read  open   getattr ioctl};
>  allow myapp_t mongod_port_t:tcp_socket name_connect;
>  
>  allow myapp_t self:tcp_socket { create setopt connect getattr getopt
>  write  read bind append};
>  allow myapp_t self:udp_socket { create connect getattr getopt setopt
>  write read bind append};
>  allow myapp_t self:netlink_route_socket { create bind getattr write
>  nlmsg_read nlmsg_write read setattr lock getopt setopt append };
>   
The policy is pretty simple if you take care of the tmp file that is
created and the mislabeled etc_runtime_t library

These are some of the things that i think should be in there and that
might solve some issues:

type myapp_t;
type myapp_exec_t;
init_daemon_domain(myapp_t, myapp_exec_t)

type myapp_unit_file_t;
systemd_unit_file(myapp_unit_file_t)

type myapp_tmp_t;
files_tmp_file(myapp_tmp_t)

manage_files_pattern(myapp_t myapp_tmp_t, myapp_tmp_t)
files_tmp_filetrans(myapp_t, myapp_tmp_t, file)

corenet_tcp_connect_mongodb_port(myapp_t)

lib_exec_ldconfig(myapp_t)

auth_use_nsswitch(myapp_t)

The remainder should probably be retested, re-analyzed

[jiun bookworm]

ok, thanks for the help,
i have one more question:

id like to use mcs with this  type,  how would i achieve that?,
before i  i was able to achieve transition, i could call a terminal
application  with runcon
and it would run in the category that i specified like this:
      '/bin/runcon/ -l s0:cX,cY   /usr/bin/appl   /path/to/inputfile '
it run in  system_u:system_r:init_t:s0:s0,cX,cY

what would i need to do to the type to make it work with categories?  or
even better with categories and
something like sandbox? like this
     '/bin/runcon/ -t sandbox_t  -l s0:cX,cY   /usr/bin/appl
/path/to/inputfile '
though the  categories are more  important to me than the sandbox.



On Sun, Jan 19, 2014 at 9:45 PM, Dominick Grift <dominick.grift(a)gmail.com&gt;wrote:

>  On Sun, 2014-01-19 at 19:34 +0300, jiun bookworm wrote:
>
>  When you write a new policy always deal with potential transition cases
>  first.
>
>  domain transitions happen on execute and file transitions happen on
>  create
>
>  >
>  > allow myapp_t self:fifo_file rw_fifo_file_perms;
>  > allow myapp_t self:unix_stream_socket create_stream_socket_perms;
>  > allow myapp_t self:process signal;
>  > allow myapp_t etc_runtime_t:file { read getattr open ioctl execute};
>
>  Above its mmapping a file with type etc_runtime_t. You should look at
>  the raw avc denials to see which file that is and where it is, then see
>  if its labeled appropriately. it should probably be labeled lib_t or
>  something
>
>  > allow myapp_t proc_t:file { read open};
>  > allow myapp_t bin_t:dir write;
>
>  The above might be an access check. You should try to confirm that by
>  using audit to record this event and then look at the syscall.
>
>  > allow myapp_t proc_t:file getattr;
>  > allow myapp_t tmp_t:dir {write add_name};
>  > allow myapp_t tmp_t:file {write open create};
>
>  The above file should be created with a type transition to a private
>  myapp_tmp_t files_tmp_file
>
>  > allow myapp_t user_home_dir_t:dir { search getattr read open write
>  > add_name};
>  > allow myapp_t user_home_t:file { read open  getattr ioctl create};
>  > allow myapp_t user_home_t:dir { read open search getattr };
>
>  The above don't quite add up. myapp is adding a directory entry and
>  writing to some directory in /home but without a type transition rule i
>  do not see how it can create the file with user_home_t.
>
>  You should analyze the raw avc denials related to the rules above to see
>  what exactly is happening and why
>
>  > allow myapp_t ldconfig_exec_t:file {execute  read open
>  > execute_no_trans};
>
>  figure out what command exactly is executing it by looking at the raw
>  avc denials comm="" field
>
>  ldconfig should usually be run as is (e.g. without a domain transition)
>
>  > allow myapp_t net_conf_t:file { read  open   getattr ioctl};
>  > allow myapp_t mongod_port_t:tcp_socket name_connect;
>  >
>  > allow myapp_t self:tcp_socket { create setopt connect getattr getopt
>  > write  read bind append};
>  > allow myapp_t self:udp_socket { create connect getattr getopt setopt
>  > write read bind append};
>  > allow myapp_t self:netlink_route_socket { create bind getattr write
>  > nlmsg_read nlmsg_write read setattr lock getopt setopt append };
>  >
>
>  The policy is pretty simple if you take care of the tmp file that is
>  created and the mislabeled etc_runtime_t library
>
>  These are some of the things that i think should be in there and that
>  might solve some issues:
>
>  type myapp_t;
>  type myapp_exec_t;
>  init_daemon_domain(myapp_t, myapp_exec_t)
>
>  type myapp_unit_file_t;
>  systemd_unit_file(myapp_unit_file_t)
>
>  type myapp_tmp_t;
>  files_tmp_file(myapp_tmp_t)
>
>  manage_files_pattern(myapp_t myapp_tmp_t, myapp_tmp_t)
>  files_tmp_filetrans(myapp_t, myapp_tmp_t, file)
>
>  corenet_tcp_connect_mongodb_port(myapp_t)
>
>  lib_exec_ldconfig(myapp_t)
>
>  auth_use_nsswitch(myapp_t)
>
>  The remainder should probably be retested, re-analyzed
>
>
>

[Dominick Grift]

On Sun, 2014-01-19 at 22:29 +0300, jiun bookworm wrote:
>  ok, thanks for the help, 
>  
>  i have one more question:
>  
>  
>  id like to use mcs with this  type,  how would i achieve that?,
>  before i  i was able to achieve transition, i could call a terminal
>  application  with runcon 
>  
>  and it would run in the category that i specified like this:
>  
>        '/bin/runcon/ -l s0:cX,cY   /usr/bin/appl   /path/to/inputfile
>  '    
>  
>  it run in  system_u:system_r:init_t:s0:s0,cX,cY
>  
>  
>  what would i need to do to the type to make it work with categories?
>  or  even better with categories and 
>  
>  something like sandbox? like this
>       '/bin/runcon/ -t sandbox_t  -l s0:cX,cY
>    /usr/bin/appl   /path/to/inputfile ' 
>  
>  though the  categories are more  important to me than the sandbox. 
>   
You'd probably replace the:

init_daemon_domain(myapp_t, myapp_exec_t)

by:

init_ranged_daemon_domain(myapp_t, myapp_exec_t, s0:cX,cY)

That *should* take care of the automatic range/domain transition. No
need to change it manually

>  
>  
>  
>  On Sun, Jan 19, 2014 at 9:45 PM, Dominick Grift
>  <dominick.grift(a)gmail.com&gt; wrote:
>          On Sun, 2014-01-19 at 19:34 +0300, jiun bookworm wrote:
>          
>          When you write a new policy always deal with potential
>          transition cases
>          first.
>          
>          domain transitions happen on execute and file transitions
>          happen on
>          create
>          
>          >
>          > allow myapp_t self:fifo_file rw_fifo_file_perms;
>          > allow myapp_t self:unix_stream_socket
>          create_stream_socket_perms;
>          > allow myapp_t self:process signal;
>          > allow myapp_t etc_runtime_t:file { read getattr open ioctl
>          execute};
>          
>          
>          Above its mmapping a file with type etc_runtime_t. You should
>          look at
>          the raw avc denials to see which file that is and where it is,
>          then see
>          if its labeled appropriately. it should probably be labeled
>          lib_t or
>          something
>          
>          > allow myapp_t proc_t:file { read open};
>          > allow myapp_t bin_t:dir write;
>          
>          
>          The above might be an access check. You should try to confirm
>          that by
>          using audit to record this event and then look at the syscall.
>          
>          > allow myapp_t proc_t:file getattr;
>          > allow myapp_t tmp_t:dir {write add_name};
>          > allow myapp_t tmp_t:file {write open create};
>          
>          
>          The above file should be created with a type transition to a
>          private
>          myapp_tmp_t files_tmp_file
>          
>          > allow myapp_t user_home_dir_t:dir { search getattr read open
>          write
>          > add_name};
>          > allow myapp_t user_home_t:file { read open  getattr ioctl
>          create};
>          > allow myapp_t user_home_t:dir { read open search getattr };
>          
>          
>          The above don't quite add up. myapp is adding a directory
>          entry and
>          writing to some directory in /home but without a type
>          transition rule i
>          do not see how it can create the file with user_home_t.
>          
>          You should analyze the raw avc denials related to the rules
>          above to see
>          what exactly is happening and why
>          
>          > allow myapp_t ldconfig_exec_t:file {execute  read open
>          > execute_no_trans};
>          
>          
>          figure out what command exactly is executing it by looking at
>          the raw
>          avc denials comm="" field
>          
>          ldconfig should usually be run as is (e.g. without a domain
>          transition)
>          
>          > allow myapp_t net_conf_t:file { read  open   getattr ioctl};
>          > allow myapp_t mongod_port_t:tcp_socket name_connect;
>          >
>          > allow myapp_t self:tcp_socket { create setopt connect
>          getattr getopt
>          > write  read bind append};
>          > allow myapp_t self:udp_socket { create connect getattr
>          getopt setopt
>          > write read bind append};
>          > allow myapp_t self:netlink_route_socket { create bind
>          getattr write
>          > nlmsg_read nlmsg_write read setattr lock getopt setopt
>          append };
>          >
>          
>          
>          The policy is pretty simple if you take care of the tmp file
>          that is
>          created and the mislabeled etc_runtime_t library
>          
>          These are some of the things that i think should be in there
>          and that
>          might solve some issues:
>          
>          type myapp_t;
>          type myapp_exec_t;
>          init_daemon_domain(myapp_t, myapp_exec_t)
>          
>          type myapp_unit_file_t;
>          
>          systemd_unit_file(myapp_unit_file_t)
>          
>          type myapp_tmp_t;
>          files_tmp_file(myapp_tmp_t)
>          
>          manage_files_pattern(myapp_t myapp_tmp_t, myapp_tmp_t)
>          files_tmp_filetrans(myapp_t, myapp_tmp_t, file)
>          
>          corenet_tcp_connect_mongodb_port(myapp_t)
>          
>          lib_exec_ldconfig(myapp_t)
>          
>          auth_use_nsswitch(myapp_t)
>          
>          The remainder should probably be retested, re-analyzed
>          
>          
>  
>

[jiun bookworm]

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?



On Sun, Jan 19, 2014 at 10:36 PM, Dominick Grift
<dominick.grift(a)gmail.com&gt;wrote:

>  On Sun, 2014-01-19 at 22:29 +0300, jiun bookworm wrote:
>  > ok, thanks for the help,
>  >
>  > i have one more question:
>  >
>  >
>  > id like to use mcs with this  type,  how would i achieve that?,
>  > before i  i was able to achieve transition, i could call a terminal
>  > application  with runcon
>  >
>  > and it would run in the category that i specified like this:
>  >
>  >       '/bin/runcon/ -l s0:cX,cY   /usr/bin/appl   /path/to/inputfile
>  > '
>  >
>  > it run in  system_u:system_r:init_t:s0:s0,cX,cY
>  >
>  >
>  > what would i need to do to the type to make it work with categories?
>  > or  even better with categories and
>  >
>  > something like sandbox? like this
>  >      '/bin/runcon/ -t sandbox_t  -l s0:cX,cY
>  >   /usr/bin/appl   /path/to/inputfile '
>  >
>  > though the  categories are more  important to me than the sandbox.
>  >
>
>  You'd probably replace the:
>
>  init_daemon_domain(myapp_t, myapp_exec_t)
>
>  by:
>
>  init_ranged_daemon_domain(myapp_t, myapp_exec_t, s0:cX,cY)
>
>  That *should* take care of the automatic range/domain transition. No
>  need to change it manually
>
>  >
>  >
>  >
>  > On Sun, Jan 19, 2014 at 9:45 PM, Dominick Grift
>  > <dominick.grift(a)gmail.com&gt; wrote:
>  >         On Sun, 2014-01-19 at 19:34 +0300, jiun bookworm wrote:
>  >
>  >         When you write a new policy always deal with potential
>  >         transition cases
>  >         first.
>  >
>  >         domain transitions happen on execute and file transitions
>  >         happen on
>  >         create
>  >
>  >         >
>  >         > allow myapp_t self:fifo_file rw_fifo_file_perms;
>  >         > allow myapp_t self:unix_stream_socket
>  >         create_stream_socket_perms;
>  >         > allow myapp_t self:process signal;
>  >         > allow myapp_t etc_runtime_t:file { read getattr open ioctl
>  >         execute};
>  >
>  >
>  >         Above its mmapping a file with type etc_runtime_t. You should
>  >         look at
>  >         the raw avc denials to see which file that is and where it is,
>  >         then see
>  >         if its labeled appropriately. it should probably be labeled
>  >         lib_t or
>  >         something
>  >
>  >         > allow myapp_t proc_t:file { read open};
>  >         > allow myapp_t bin_t:dir write;
>  >
>  >
>  >         The above might be an access check. You should try to confirm
>  >         that by
>  >         using audit to record this event and then look at the syscall.
>  >
>  >         > allow myapp_t proc_t:file getattr;
>  >         > allow myapp_t tmp_t:dir {write add_name};
>  >         > allow myapp_t tmp_t:file {write open create};
>  >
>  >
>  >         The above file should be created with a type transition to a
>  >         private
>  >         myapp_tmp_t files_tmp_file
>  >
>  >         > allow myapp_t user_home_dir_t:dir { search getattr read open
>  >         write
>  >         > add_name};
>  >         > allow myapp_t user_home_t:file { read open  getattr ioctl
>  >         create};
>  >         > allow myapp_t user_home_t:dir { read open search getattr };
>  >
>  >
>  >         The above don't quite add up. myapp is adding a directory
>  >         entry and
>  >         writing to some directory in /home but without a type
>  >         transition rule i
>  >         do not see how it can create the file with user_home_t.
>  >
>  >         You should analyze the raw avc denials related to the rules
>  >         above to see
>  >         what exactly is happening and why
>  >
>  >         > allow myapp_t ldconfig_exec_t:file {execute  read open
>  >         > execute_no_trans};
>  >
>  >
>  >         figure out what command exactly is executing it by looking at
>  >         the raw
>  >         avc denials comm="" field
>  >
>  >         ldconfig should usually be run as is (e.g. without a domain
>  >         transition)
>  >
>  >         > allow myapp_t net_conf_t:file { read  open   getattr ioctl};
>  >         > allow myapp_t mongod_port_t:tcp_socket name_connect;
>  >         >
>  >         > allow myapp_t self:tcp_socket { create setopt connect
>  >         getattr getopt
>  >         > write  read bind append};
>  >         > allow myapp_t self:udp_socket { create connect getattr
>  >         getopt setopt
>  >         > write read bind append};
>  >         > allow myapp_t self:netlink_route_socket { create bind
>  >         getattr write
>  >         > nlmsg_read nlmsg_write read setattr lock getopt setopt
>  >         append };
>  >         >
>  >
>  >
>  >         The policy is pretty simple if you take care of the tmp file
>  >         that is
>  >         created and the mislabeled etc_runtime_t library
>  >
>  >         These are some of the things that i think should be in there
>  >         and that
>  >         might solve some issues:
>  >
>  >         type myapp_t;
>  >         type myapp_exec_t;
>  >         init_daemon_domain(myapp_t, myapp_exec_t)
>  >
>  >         type myapp_unit_file_t;
>  >
>  >         systemd_unit_file(myapp_unit_file_t)
>  >
>  >         type myapp_tmp_t;
>  >         files_tmp_file(myapp_tmp_t)
>  >
>  >         manage_files_pattern(myapp_t myapp_tmp_t, myapp_tmp_t)
>  >         files_tmp_filetrans(myapp_t, myapp_tmp_t, file)
>  >
>  >         corenet_tcp_connect_mongodb_port(myapp_t)
>  >
>  >         lib_exec_ldconfig(myapp_t)
>  >
>  >         auth_use_nsswitch(myapp_t)
>  >
>  >         The remainder should probably be retested, re-analyzed
>  >
>  >
>  >
>  >
>
>
>

[Dominick Grift]

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? 
>  
>   
I made a shedload of mcs videos, some of which touch on what you are
trying to achieve i believe, i just do not know which ones exactly.

Here is a list with some of my MCS related videos on youtube:

1. https://www.youtube.com/watch?v=M9sMqeRb2l0
2. https://www.youtube.com/watch?v=mdZdV3R6ayg
3. https://www.youtube.com/watch?v=NJ_398QtoNM
4. https://www.youtube.com/watch?v=uprZGJcIXC4
5. https://www.youtube.com/watch?v=s8mEIipD3z0
6. https://www.youtube.com/watch?v=XoTpTmplTWc
7. https://www.youtube.com/watch?v=JHLN9fac2pc

One should probably watch them in that order, but the 7th link has some
important information with regard to MCS i believe.

I know they're long and boring videos and i am not forcing you to watch
them but this is the best help i can give

[Dominick Grift]

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

[jiun bookworm]

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);
mcs_process_set_categories(myapp_t);
range_transition initrc_t myapp_exec_t:process s0:c0.c1023;


On Mon, Jan 20, 2014 at 2:28 AM, Dominick Grift <dominick.grift(a)gmail.com&gt;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
>
>
>

[Dominick Grift]

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&gt; 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
>          
>          
>  
>

[jiun bookworm]

init_ranged_daemon_domain() was not working for me,  im  sure i have done
something wrong,  but i have no idea what or where that is,    right now
with the policy as it is, its running in
system_u:object_r:unlabeled_t:s0   meaning iv borked things big time.

here is the policy:

policy_module(myapp, 1.0.0)

########################################
#
# Declarations
#
require {
#        type init_t;
         type initrc_t;
         type systemd_unit_file_t ;
         type urandom_device_t ;
         type etc_runtime_t ;
         type proc_t;
         type bin_t;
         type tmp_t;
         type user_home_dir_t;
         type user_home_t;
         type net_conf_t;
         type ldconfig_exec_t;
         type mongod_port_t;
         type unreserved_port_t;
         type http_cache_port_t;
         type http_port_t;
         type sandbox_file_t;
         type node_t ;
         type shell_exec_t ;
         type bin_t ;
         type security_t ;
         type setroubleshootd_t ;
         type unconfined_t ;
         type default_t ;
}

init_ranged_daemon_domain(myapp_t,myapp_exec_t,s0 - mcs_systemhigh);
type myapp_t;
domain_type(myapp_t);
type myapp_exec_t;

type myapp_unit_file_t;
systemd_unit_file(systemd_unit_file_t)

mcs_process_set_categories(myapp_t);

########################################
allow myapp_t self:fifo_file rw_fifo_file_perms;
allow myapp_t self:unix_stream_socket create_stream_socket_perms;
allow myapp_t self:process signal;
allow myapp_t etc_runtime_t:file { read getattr open ioctl execute};
allow myapp_t proc_t:file { read open};
allow myapp_t bin_t:dir write;
allow myapp_t bin_t:file { execute execute_no_trans };
allow myapp_t proc_t:file getattr;
allow myapp_t tmp_t:dir {write add_name};
allow myapp_t tmp_t:file {write open create};
allow myapp_t user_home_dir_t:dir { search getattr read open write
add_name};
allow myapp_t user_home_t:file { read open  getattr ioctl create};
allow myapp_t user_home_t:dir { read open search getattr };
allow myapp_t ldconfig_exec_t:file {execute  read open  execute_no_trans};
allow myapp_t net_conf_t:file { read  open   getattr ioctl};
allow myapp_t mongod_port_t:tcp_socket name_connect;
allow myapp_t unreserved_port_t:tcp_socket {name_bind create setopt connect
getattr getopt write  read bind append};
allow myapp_t node_t:tcp_socket {node_bind };
allow myapp_t http_cache_port_t:tcp_socket { name_connect create setopt
connect getattr getopt write  read bind append };
allow myapp_t http_port_t:tcp_socket { name_connect };
allow myapp_t sandbox_file_t:dir { search getattr read open write add_name
create  };
allow myapp_t sandbox_file_t:file { read open  getattr ioctl create write
relabelfrom relabelto  };
allow myapp_t sandbox_file_t:dir { relabelfrom relabelto };
allow myapp_t shell_exec_t:file { execute execute_no_trans };
allow myapp_t security_t:file write;


allow myapp_t self:tcp_socket { create setopt connect getattr getopt write
read bind append listen accept};
allow myapp_t self:udp_socket { create connect getattr getopt setopt write
read bind append listen accept };

allow myapp_t self:netlink_route_socket { create bind getattr write
nlmsg_read nlmsg_write read setattr lock getopt setopt append };


domain_use_interactive_fds(myapp_t)


allow myapp_t urandom_device_t:chr_file {read open};

allow myapp_t default_t:file { read getattr execute  open
execute_no_trans};
allow setroubleshootd_t myapp_exec_t:file getattr;
allow init_t myapp_exec_t:file execute;
allow init_t myapp_exec_t:file { read open execute  getattr entrypoint };



On Mon, Jan 20, 2014 at 12:19 PM, Dominick Grift
<dominick.grift(a)gmail.com&gt;wrote:

>  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&gt; 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
>  >
>  >
>  >
>  >
>
>
>

[jiun bookworm]

I have nanaged to get  the daemon working with the full mcs range, but it
can not run a shell program under a particular category with runcon, what
special priviledges are neccessary for an app to use runcon?

this is the error message when the app calls a shell command with runcon

/bin/runcon: invalid context: system_u:system_r:myapp_t:s0:c370,c606:
Permission denied

after attempting to do this:
/bin/runcon   -l s0:c370,c606   /path/to/app   input

the daemon itself runs in the following context:

system_u:system_r:myapp_t:s0-s0:c0.c1023  myapp  7542 0.2  0.0 909660 60 ?
Ssl  01:06   0:14



here is the policy

policy_module(myapp, 1.0.0)

########################################
#
# Declarations
#
require {
         type init_t;
         type initrc_t;
         type systemd_unit_file_t ;
         type urandom_device_t ;
         type etc_runtime_t ;
         type proc_t;
         type bin_t;
         type tmp_t;
         type user_home_dir_t;
         type user_home_t;
         type net_conf_t;
         type ldconfig_exec_t;
         type mongod_port_t;
         type unreserved_port_t;
         type http_cache_port_t;
         type http_port_t;
         type sandbox_file_t;
         type node_t ;
         type shell_exec_t ;
         type bin_t ;
         type default_t ;
         type usr_t ;
         type root_t ;
         type security_t ;
         type unlabeled_t ;
}

type myapp_t;
type myapp_exec_t;

init_daemon_domain(myapp_t,myapp_exec_t);

ifdef(`enable_mcs',`
    init_ranged_daemon_domain(myapp_t,myapp_exec_t,s0 - mcs_systemhigh);
')
systemd_unit_file(systemd_unit_file_t) ;


########################################
allow myapp_t self:fifo_file rw_fifo_file_perms;
allow myapp_t self:unix_stream_socket create_stream_socket_perms;
allow myapp_t self:process { signal transition setexec };
allow myapp_t etc_runtime_t:file { read getattr open ioctl execute};
allow myapp_t proc_t:file { read open};
allow myapp_t bin_t:dir { write add_name create };
allow myapp_t bin_t:file { execute  execute_no_trans read open  getattr
ioctl };
allow myapp_t proc_t:file getattr;
allow myapp_t tmp_t:dir {write add_name};
allow myapp_t tmp_t:file {write open create};
allow myapp_t ldconfig_exec_t:file {execute  read open  execute_no_trans};
allow myapp_t net_conf_t:file { read  open   getattr ioctl};
allow myapp_t mongod_port_t:tcp_socket name_connect;
allow myapp_t unreserved_port_t:tcp_socket {name_bind create setopt connect
getattr getopt write  read bind append};
allow myapp_t node_t:tcp_socket {node_bind };
allow myapp_t http_cache_port_t:tcp_socket { name_connect create setopt
connect getattr getopt write  read bind append };
allow myapp_t http_port_t:tcp_socket { name_connect };
allow myapp_t sandbox_file_t:dir { search getattr read open write add_name
create  };
allow myapp_t sandbox_file_t:file { read open  getattr ioctl create write
relabelfrom relabelto  };
allow myapp_t sandbox_file_t:dir { relabelfrom relabelto };
allow myapp_t shell_exec_t:file { execute execute_no_trans };


allow myapp_t default_t:dir { search read getattr write };
allow myapp_t default_t:file { read getattr open execute execute_no_trans
ioctl };
allow myapp_t default_t:lnk_file read;
allow myapp_t root_t:dir {  write search read getattr add_name create
relabelfrom } ;
allow myapp_t root_t:file {  write  read getattr  create open ioctl
relabelfrom } ;
allow myapp_t security_t:file write;
allow myapp_t security_t:security check_context;

allow myapp_t usr_t:file { execute entrypoint  read getattr  create open
ioctl };

allow unlabeled_t root_t:dir search;

allow myapp_t self:tcp_socket { create setopt connect getattr getopt write
read bind append listen accept};
allow myapp_t self:udp_socket { create connect getattr getopt setopt write
read bind append listen accept };

domain_use_interactive_fds(myapp_t)

#files_read_etc_files(myapp_t)

#miscfiles_read_localization(myapp_t)

#!!!! This avc can be allowed using the boolean 'global_ssp'
allow myapp_t urandom_device_t:chr_file {read open};



On Mon, Jan 20, 2014 at 2:24 PM, jiun bookworm <thebookworm101(a)gmail.com&gt;wrote:

>  init_ranged_daemon_domain() was not working for me,  im  sure i have
> done
>  something wrong,  but i have no idea what or where that is,    right now
>  with the policy as it is, its running in
>  system_u:object_r:unlabeled_t:s0   meaning iv borked things big time.
>
>  here is the policy:
>
>
>  policy_module(myapp, 1.0.0)
>
>  ########################################
>  #
>  # Declarations
>  #
>  require {
>  #        type init_t;
>           type initrc_t;
>
>           type systemd_unit_file_t ;
>           type urandom_device_t ;
>           type etc_runtime_t ;
>           type proc_t;
>           type bin_t;
>           type tmp_t;
>           type user_home_dir_t;
>           type user_home_t;
>           type net_conf_t;
>           type ldconfig_exec_t;
>           type mongod_port_t;
>           type unreserved_port_t;
>           type http_cache_port_t;
>           type http_port_t;
>           type sandbox_file_t;
>           type node_t ;
>           type shell_exec_t ;
>           type bin_t ;
>           type security_t ;
>           type setroubleshootd_t ;
>           type unconfined_t ;
>           type default_t ;
>  }
>
>  init_ranged_daemon_domain(myapp_t,myapp_exec_t,s0 - mcs_systemhigh);
>  type myapp_t;
>  domain_type(myapp_t);
>  type myapp_exec_t;
>
>  type myapp_unit_file_t;
>  systemd_unit_file(systemd_unit_file_t)
>
>  mcs_process_set_categories(myapp_t);
>
>  ########################################
>
>  allow myapp_t self:fifo_file rw_fifo_file_perms;
>  allow myapp_t self:unix_stream_socket create_stream_socket_perms;
>  allow myapp_t self:process signal;
>  allow myapp_t etc_runtime_t:file { read getattr open ioctl execute};
>  allow myapp_t proc_t:file { read open};
>  allow myapp_t bin_t:dir write;
>  allow myapp_t bin_t:file { execute execute_no_trans };
>
>  allow myapp_t proc_t:file getattr;
>  allow myapp_t tmp_t:dir {write add_name};
>  allow myapp_t tmp_t:file {write open create};
>  allow myapp_t user_home_dir_t:dir { search getattr read open write
>  add_name};
>  allow myapp_t user_home_t:file { read open  getattr ioctl create};
>  allow myapp_t user_home_t:dir { read open search getattr };
>  allow myapp_t ldconfig_exec_t:file {execute  read open  execute_no_trans};
>  allow myapp_t net_conf_t:file { read  open   getattr ioctl};
>  allow myapp_t mongod_port_t:tcp_socket name_connect;
>  allow myapp_t unreserved_port_t:tcp_socket {name_bind create setopt
>  connect getattr getopt write  read bind append};
>  allow myapp_t node_t:tcp_socket {node_bind };
>  allow myapp_t http_cache_port_t:tcp_socket { name_connect create setopt
>  connect getattr getopt write  read bind append };
>  allow myapp_t http_port_t:tcp_socket { name_connect };
>  allow myapp_t sandbox_file_t:dir { search getattr read open write add_name
>  create  };
>  allow myapp_t sandbox_file_t:file { read open  getattr ioctl create write
>  relabelfrom relabelto  };
>  allow myapp_t sandbox_file_t:dir { relabelfrom relabelto };
>  allow myapp_t shell_exec_t:file { execute execute_no_trans };
>  allow myapp_t security_t:file write;
>
>
>  allow myapp_t self:tcp_socket { create setopt connect getattr getopt
>  write  read bind append listen accept};
>  allow myapp_t self:udp_socket { create connect getattr getopt setopt write
>  read bind append listen accept };
>
>
>  allow myapp_t self:netlink_route_socket { create bind getattr write
>  nlmsg_read nlmsg_write read setattr lock getopt setopt append };
>
>
>  domain_use_interactive_fds(myapp_t)
>
>
>
>  allow myapp_t urandom_device_t:chr_file {read open};
>
>  allow myapp_t default_t:file { read getattr execute  open
>  execute_no_trans};
>  allow setroubleshootd_t myapp_exec_t:file getattr;
>  allow init_t myapp_exec_t:file execute;
>  allow init_t myapp_exec_t:file { read open execute  getattr entrypoint };
>
>
>
>  On Mon, Jan 20, 2014 at 12:19 PM, Dominick Grift <dominick.grift(a)gmail.com
>  > wrote:
>
> > 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&gt; 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
> > >
> > >
> > >
> > >
> >
> >
> >
>