I think I'm really close to having this policy finished and working, just a couple things to work out...
When I exercise my app and then run audit2allow and it says:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow myapp_t default_t:dir search; allow myapp_t default_t:dir read; allow myapp_t default_t:file execmod; allow myapp_t myapp_bin_t:file write;
does it mean only the first line is an constraint violation? Or are all of those constraint violations?
How does one typically deal with constraint violations? By attribute above I suppose it means a type attribue but how do I know which one to add?
Then I have these:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service starts. I suspect this is a bad idea and I'm not sure why they are doing it. I think they may be applying security categories here. We may have to find a different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
Thanks!
On 05/26/2015 05:05 AM, Tracy Reed wrote:
I think I'm really close to having this policy finished and working, just a couple things to work out...
When I exercise my app and then run audit2allow and it says:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow myapp_t default_t:dir search; allow myapp_t default_t:dir read; allow myapp_t default_t:file execmod; allow myapp_t myapp_bin_t:file write;
does it mean only the first line is an constraint violation? Or are all of those constraint violations?
How does one typically deal with constraint violations? By attribute above I suppose it means a type attribue but how do I know which one to add?
Then I have these:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service starts. I suspect this is a bad idea and I'm not sure why they are doing it. I think they may be applying security categories here. We may have to find a different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
Thanks!
The latest audit2allow gives you a little more information, when you get a constraint violation you usually need to add an attribute to the calling process type, to say it is ok to do the operation. Usually it is related to the MLS/MCS Levels being different or changing the SELinux user component of a label. If you attached the actual AVC message we might be able to diagnose the problem. Having restorecon in an initscript is not unusual.
Hello all!
Way back in May I wrote to the list and got some, but not all, of the problems fixed in my policy. This project was on the back-burner mostly working for a while but now I need to get it perfected.
We use MCS and have an automated process to deploy web application instances to machines with a separate category per application instance to protect them from each other. When the application starts the init script does a chcon to set the category/context. initrc_t is supposedly unconstrained from what I'm reading in the docs so why is it being prohibited from relabeling?
type=AVC msg=audit(11/09/2015 04:22:43.045:3126812) : avc: denied { relabelto } for pid=13753 comm=chcon name=tomcat-server.xml dev=dm-0 ino=16900514 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_conf_t:s0:c50 tclass=file
On Tue, May 26, 2015 at 02:04:59AM PDT, Tracy Reed spake thusly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service starts. I suspect this is a bad idea and I'm not sure why they are doing it. I think they may be applying security categories here. We may have to find a different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
dgrift suggested on IRC that I try the domain_obj_id_change_exemption attribute.
I tried that and it didn't work. For example I added the following (including trying the extra unnecessary attributes):
# Adding lines to try and overcome the constraint violation for initrc starting nodes. domain_obj_id_change_exemption(initrc_t) domain_subj_id_change_exemption(initrc_t) domain_role_change_exemption(initrc_t) domain_system_change_exemption(initrc_t) domain_user_exemption_target(initrc_t)
# Guess this really shouldn't be necessary, but just in case. allow initrc_t myapp_exec_t:file execute; allow initrc_t myapp_java_t:file { execute read execmod open getattr execute_no_trans }; allow initrc_t myapp_java_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_api_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_bin_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_conf_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_exec_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_lib_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_logs_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_nodes_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_release_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_scripts_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_util_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_var_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_webapps_t:file { relabelfrom relabelto getattr };
Policy loads, but on reboot when the init.d starts the web application:
type=AVC msg=audit(1447281933.532:76): avc: denied { relabelto } for pid=1429 comm="chcon" name="select2_doctype.css" dev=dm-0 ino=614732 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_webapps_t:s0:c18 tclass=file type=AVC msg=audit(1447281933.607:77): avc: denied { relabelto } for pid=1429 comm="chcon" name="myapp-release" dev=dm-0 ino=508002 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_release_t:s0:c18 tclass=file type=AVC msg=audit(1447281933.936:78): avc: denied { relabelto } for pid=1429 comm="chcon" name="README" dev=dm-0 ino=1296427 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_logs_t:s0:c18 tclass=file
Still getting the constraint messages. #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_logs_t:file relabelto;
Ideas?
On Tue, Nov 10, 2015 at 03:48:35PM PST, Tracy Reed spake thusly:
Hello all!
Way back in May I wrote to the list and got some, but not all, of the problems fixed in my policy. This project was on the back-burner mostly working for a while but now I need to get it perfected.
We use MCS and have an automated process to deploy web application instances to machines with a separate category per application instance to protect them from each other. When the application starts the init script does a chcon to set the category/context. initrc_t is supposedly unconstrained from what I'm reading in the docs so why is it being prohibited from relabeling?
type=AVC msg=audit(11/09/2015 04:22:43.045:3126812) : avc: denied { relabelto } for pid=13753 comm=chcon name=tomcat-server.xml dev=dm-0 ino=16900514 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_conf_t:s0:c50 tclass=file
On Tue, May 26, 2015 at 02:04:59AM PDT, Tracy Reed spake thusly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service starts. I suspect this is a bad idea and I'm not sure why they are doing it. I think they may be applying security categories here. We may have to find a different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
-- Tracy Reed
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
The refpolicy has the following mcs constraints:
# New filesystem object labels must be dominated by the relabeling subject # clearance, also the objects are single-level. mlsconstrain file { create relabelto } (( h1 dom h2 ) and ( l2 eq h2 ));
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { create relabelto } (( h1 dom h2 ) and ( l2 eq h2 ));
There's no "or ( t1 != mcs_constrained_type)" for the relabelto of files (unlike other constraints in the mcs policy), so I don't think there can be an attribute to allow a domain to override the constraint. Perhaps you could look into transitioning initrc_t to a different domain with system_high clearance, which can then do what you need it to?
Cheers, Doug
On 12 Nov 2015, at 9:36 AM, Tracy Reed <treed@ultraviolet.orgmailto:treed@ultraviolet.org> wrote:
dgrift suggested on IRC that I try the domain_obj_id_change_exemption attribute.
I tried that and it didn't work. For example I added the following (including trying the extra unnecessary attributes):
# Adding lines to try and overcome the constraint violation for initrc starting nodes. domain_obj_id_change_exemption(initrc_t) domain_subj_id_change_exemption(initrc_t) domain_role_change_exemption(initrc_t) domain_system_change_exemption(initrc_t) domain_user_exemption_target(initrc_t)
# Guess this really shouldn't be necessary, but just in case. allow initrc_t myapp_exec_t:file execute; allow initrc_t myapp_java_t:file { execute read execmod open getattr execute_no_trans }; allow initrc_t myapp_java_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_api_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_bin_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_conf_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_exec_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_lib_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_logs_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_nodes_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_release_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_scripts_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_util_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_var_t:file { relabelfrom relabelto getattr }; allow initrc_t myapp_webapps_t:file { relabelfrom relabelto getattr };
Policy loads, but on reboot when the init.d starts the web application:
type=AVC msg=audit(1447281933.532:76): avc: denied { relabelto } for pid=1429 comm="chcon" name="select2_doctype.css" dev=dm-0 ino=614732 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_webapps_t:s0:c18 tclass=file type=AVC msg=audit(1447281933.607:77): avc: denied { relabelto } for pid=1429 comm="chcon" name="myapp-release" dev=dm-0 ino=508002 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_release_t:s0:c18 tclass=file type=AVC msg=audit(1447281933.936:78): avc: denied { relabelto } for pid=1429 comm="chcon" name="README" dev=dm-0 ino=1296427 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_logs_t:s0:c18 tclass=file
Still getting the constraint messages. #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_logs_t:file relabelto;
Ideas?
On Tue, Nov 10, 2015 at 03:48:35PM PST, Tracy Reed spake thusly: Hello all!
Way back in May I wrote to the list and got some, but not all, of the problems fixed in my policy. This project was on the back-burner mostly working for a while but now I need to get it perfected.
We use MCS and have an automated process to deploy web application instances to machines with a separate category per application instance to protect them from each other. When the application starts the init script does a chcon to set the category/context. initrc_t is supposedly unconstrained from what I'm reading in the docs so why is it being prohibited from relabeling?
type=AVC msg=audit(11/09/2015 04:22:43.045:3126812) : avc: denied { relabelto } for pid=13753 comm=chcon name=tomcat-server.xml dev=dm-0 ino=16900514 scontext=system_u:system_r:initrc_t:s0 tcontext=myapp_u:object_r:myapp_conf_t:s0:c50 tclass=file
On Tue, May 26, 2015 at 02:04:59AM PDT, Tracy Reed spake thusly: #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service starts. I suspect this is a bad idea and I'm not sure why they are doing it. I think they may be applying security categories here. We may have to find a different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
-- Tracy Reed
-- selinux mailing list selinux@lists.fedoraproject.orgmailto:selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.orgmailto:selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Ok we don't support it on CentOS/RHEL6 for relabeling. New object file objects must be dominated by the relabeling subject. We have mcsuntrustedproc here but not applied. Could you open a new bug where we can discuss it if we want to add it to RHEL6?
Thank you.
Regards, Miroslav
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Douglas Brown -
Miroslav Grepl -
Tracy Reed