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
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
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@gmail.comwrote:
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
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:
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@gmail.comwrote:
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)
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
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@gmail.comwrote:
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
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@gmail.com 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, 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@gmail.comwrote:
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@gmail.com 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
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
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
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@gmail.comwrote:
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:
- you run the parent with the full mcs range
- 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
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@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
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@gmail.comwrote:
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@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
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@gmail.comwrote:
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@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@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
selinux@lists.fedoraproject.org
-
Dominick Grift -
jiun bookworm