From: jack.borg-cardona@cgi.com (Borg-Cardona, Jack) Date: Wed, 3 Aug 2016 08:24:45 +0000 Subject: [refpolicy] Compile Error when using the userdom_login_user_template() macro... In-Reply-To: References: <53E0DE5B854BBC4EA982E3197A0C96D24B111CB0@SE-EX021.groupinfra.com> <93b453d1-0c9a-ab52-0eb6-b3f191188354@gmail.com> <53E0DE5B854BBC4EA982E3197A0C96D24B111E05@SE-EX021.groupinfra.com> <67130EC7AFA3FE4E9290B03665B351F4017CD6@SE-EX021.groupinfra.com> <7824ccd2-6889-26d2-035a-dc42b4c3b5a6@gmail.com> <67130EC7AFA3FE4E9290B03665B351F4017E26@SE-EX021.groupinfra.com> <00206af6-6ec7-9ebd-d110-400572773639@gmail.com> <67130EC7AFA3FE4E9290B03665B351F401911E@SE-EX021.groupinfra.com> <58077fd8-7c07-8fb4-8cba-2d78e6fba598@gmail.com> <67130EC7AFA3FE4E9290B03665B351F4019853@SE-EX021.groupinfra.com> <67130EC7AFA3FE4E9290B03665B351F40198AD@SE-EX021.groupinfra.com> <67130EC7AFA3FE4E9290B03665B351F401994F@SE-EX021.groupinfra.com> Message-ID: <53E0DE5B854BBC4EA982E3197A0C96D24B117FE9@SE-EX021.groupinfra.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com HI Dominic, Thanks for explaining this in detail. Looks like we need a rethink. Jack -----Original Message----- From: Dominick Grift [mailto:dac.override at gmail.com] Sent: 03 August 2016 08:29 To: Fakim, Walid; refpolicy at oss.tresys.com Cc: Borg-Cardona, Jack Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... On 08/03/2016 12:19 AM, Fakim, Walid wrote: > It does help but that brings up another question or 2 : > > 1) Should we be using existing types to create our policies? i.e. instead of jbossd_t should we be using java_exec_t (could be a silly/wrong example but am sure you get the idea)? > 2) If we wish to use new types, do we first need to define them before compiling our policy module? Otherwise, we end up in a catch-22 situation as currently. > 1. Use existing types unless that is really not possible. java works like an interpreter. One should not use the java executable file as a domain entry file unless there is no other way (there is always another way) For example: for your java application server applications create scripts that call java. Transition on these scripts instead of java. In other words: there most likely is no need to change java_exec_t If you wish you to use your own types then you must obviously declare them first, make sure they are available if you have something that has a hard dependency on their availability. But also you must make sure that the file context specifications do not conflict There is no catch 22 if you make a soft/weak dependency optional with the optional {} policy. The compiler will include the optional when it can and exclude it when it can't The concept of hard dependencies and soft/weak dependencies is very important to understand. When to use optional policy and when not. This is want makes policy modular example: replacing the java_exec_t type with myjava_exec_t (discouraged and will probably not work due to other modules having hard dependencies on the availability of the java_exec_t type) for example you want to replace the java_exec_t type with your own myjava_exec_t type: 1. declare the new type, and make it available by loading it cat >myjava.te<myjava.fc< Thanks. > > Best Regards, > > Walid Fakim > > > -----Original Message----- > From: Dominick Grift [mailto:dac.override at gmail.com] > Sent: 02 August 2016 21:16 > To: Fakim, Walid; refpolicy at oss.tresys.com > Cc: Borg-Cardona, Jack > Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... > > On 08/02/2016 10:04 PM, Fakim, Walid wrote: >> Thanks Dominick - Tried that with no luck. >> >> Initially we had the definitions as follows: >> >> =============== >> >> policy_module(cosapp, 0.3) >> gen_require(' >> type jboss_exec_t; >> type jbossd_t; >> type jboss_conf_t; >> type jboss_log_t; >> type jboss_tmp_t; >> type cos_var_run_t; >> type javad_t; >> type java_exec_t; >> type http_port_cache_t; >> ') >> >> -------------- >> >> I then changed it to the below as per your suggestion: >> -------------- >> >> policy_module(cosapp, 0.3) >> require { >> type jboss_exec_t; >> type jbossd_t; >> type jboss_conf_t; >> type jboss_log_t; >> type jboss_tmp_t; >> type cos_var_run_t; >> type javad_t; >> type java_exec_t; >> type http_port_cache_t; >> } >> >> >> ========== >> >> That fails too with the same error message. And jboss_exec_t does not exist, it is a new type that we created. >> > > Then it means that your module has a "hard dependency" on a identifier that cannot be satisfied. > > if type jboss_exec_t (any identifier for that matter) does not exist then you cannot unconditionally reference it. > > wrap references to types that may not always exist into an optional block. > > example: > > optional { > require { type mytype_t; } > allow bla mytype_t:file read; > } > > This way the "mytype_t" will be "made available/can be referenced" if it exists and if it does not exist then the policy inside the "optional block" will not be compiled. > > E.g. the policy inside the optional block is a soft/weak dependency, instead of an hard dependency. > > Does that help? (if not then be more specific and exclose more > references) >> >> >> Thanks. >> >> Best Regards, >> >> Walid Fakim >> >> -----Original Message----- >> From: Dominick Grift [mailto:dac.override at gmail.com] >> Sent: 02 August 2016 20:13 >> To: Fakim, Walid; refpolicy at oss.tresys.com >> Cc: Borg-Cardona, Jack >> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... >> >> On 08/02/2016 09:07 PM, Fakim, Walid wrote: >>> Thanks Dominick - Followed your advice of stick to the Distro's policy and made some progress. >>> >>> The policy module compiles no problem but trying to load the policy fails as follows: >>> >>> ===== >>> [root at server2 cosapp]# semodule -i cosapp.pp >>> libsepol.print_missing_requirements: cosapp's global requirements were not met: type/attribute jboss_exec_t (No such file or directory). >>> libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). >>> semodule: Failed! >>> >> >> The type "jboss_exec_t" is referenced in your cosapp.pp but it is either unavailable or its not required. >> >> 1. determine whether type jboss_exec_t exists: >> >> seinfo -t | grep jboss_exec_t >> >> 2. if it exists (the above command returned) then require type jboss_exec_t in your cosapp.te file and rebuild the cosapp.pp, then try to install it again: >> >> echo "require { type jboss_exec_t; }" >> cosapp.te make -f >> /usr/share/selinux/devel/Makefile cosapp.pp sudo semodule -i >> cosapp.pp >> >> >> Did the above solve this particular issue? >> >>> ===== >>> >>> 1) We checked there's no other cosapp.pp module loaded >>> 2) Tried to artificially create all the relevant directories >>> referenced in cosapp.fc >>> >>> Kinda stumped now - been googling for this but can't come up with a root cause and resolution so any insight would be great. >>> >>> Thanks. >>> >>> Best Regards, >>> >>> Walid Fakim >>> >>> >>> >>> -----Original Message----- >>> From: Dominick Grift [mailto:dac.override at gmail.com] >>> Sent: 01 August 2016 15:49 >>> To: Fakim, Walid; refpolicy at oss.tresys.com >>> Cc: Borg-Cardona, Jack >>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... >>> >>> On 08/01/2016 04:29 PM, Fakim, Walid wrote: >>>> Hi Dominick, >>>> >>>> I tried a different approaching of identifying the reference policy >>>> (going back in chronological order) that will compile with CentOS >>>> 6.8 and this turns out to be version corresponding to -> >>>> refpolicy-2.20110726.tar.bz2 >>>> >>>> So that compiles fine and all seems to be hunky dory until you reboot the system (included touch /.autorelabel) and then it hangs at boot. This happens also after I force the relabelling manually when booting via grub options 'enforcing=0'. >>>> I've attached a couple of screenshots of what we're getting. I know the policy has been loaded from the output of seinfo (also attached). >>>> >>>> Is there something we're missing here? Or are we flogging a dead >>>> horse and should stick to the distribution's version? We are using >>>> CentOS >>>> 6.8 as a testbed but plan to use this (once we get it working) in >>>> production in RHEL 6.8 >>> >>> You will obviously encounter incompatibility with reference policy one way or another. My advice to you is to use what your distribution provides. >>> >>> The avc denials you have enclosed are compatibility "issues" in the >>> shape of missing rules, and labeling "issues" that may or may not be >>> fixed by relabeling your filesystems (if they aren't labels on the >>> initramfs) >>> >>>> >>>> Thanks + Regards, >>>> Walid >>>> >>>> -----Original Message----- >>>> From: Dominick Grift [mailto:dac.override at gmail.com] >>>> Sent: 28 July 2016 15:36 >>>> To: Fakim, Walid; refpolicy at oss.tresys.com >>>> Cc: Borg-Cardona, Jack >>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... >>>> >>>> On 07/28/2016 04:28 PM, Fakim, Walid wrote: >>>>> Hi Dominick, >>>>> >>>>> Thanks for your response. >>>>> >>>>> I've moved on to trying to load the upstream reference policy on my VM (running CentOS 6.8) - I'm getting the following error: >>>>> >>>>> ==== >>>>> >>>>> [staff at blue policy]$ sudo make load Compliling >>>>> tresys-test-refpolicy abrt.mod module >>>>> m4 -D enable_ubac -D mls_num_sens=16 -D mls_num_cats=1024 -D >>>>> mcs_num_cats=1024 -D hide_broken_symptoms -s support/divert.m4 >>>>> policy/support/file_patterns.spt policy/support/ipc_patterns.spt >>>>> policy/support/loadable_module.spt policy/support/misc_macros.spt >>>>> policy/support/misc_patterns.spt policy/support/mls_mcs_macros.spt >>>>> policy/support/obj_perm_sets.spt support/undivert.m4 >>>>> tmp/generated_definitions.conf tmp/all_interfaces.conf >>>>> policy/modules/contrib/abrt.te > tmp/abrt.tmp /usr/bin/checkmodule >>>>> -m tmp/abrt.tmp -o tmp/abrt.mod >>>>> /usr/bin/checkmodule: loading policy configuration from >>>>> tmp/abrt.tmp policy/modules/contrib/abrt.te":37:ERROR 'syntax error' at token 'attribute_role' on line 509: >>>>> >>>>> >>>>> ==== >>>>> >>>>> Is this a compatibility issue between the latest reference policy and CentOS 6.8 or am I missing something? >>>> >>>> Yes, may well be. role attributes may not be supported in Centos6.8. Hmm we should have considered that this would break compatibility. >>>> >>>> Best to stick to what your distribution provides >>>> >>>>> >>>>> Thanks & Regards, >>>>> Walid >>>>> >>>>> -----Original Message----- >>>>> From: refpolicy-bounces at oss.tresys.com >>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Dominick >>>>> Grift >>>>> Sent: 28 July 2016 12:53 >>>>> To: refpolicy at oss.tresys.com >>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... >>>>> >>>>> On 07/28/2016 01:30 PM, Fakim, Walid wrote: >>>>>> Hi Dominick, >>>>>> >>>>>> I am working with Jack on this issue. So we tried your code snippet and that worked. We do have the reference policy downloaded - how do we confirm that we are indeed using it? >>>>>> >>>>>> Going back to Jack's comment regarding the userdom_unpriv_user_template() macro : >>>>>> >>>>>> I've switched the order of the code round from : >>>>>> >>>>>> ==== Old Code ==== >>>>>> role cos_r; >>>>>> gen_user(cos_u, dsp_user, cos_r, s0, s0 - mls_systemhigh, >>>>>> mcs_allcats) >>>>>> >>>>>> userdom_unpriv_user_template(cos) ================ >>>>>> >>>>>> To >>>>>> >>>>>> ====New Code==== >>>>>> userdom_unpriv_user_template(cos) >>>>>> >>>>>> role cos_r; >>>>>> gen_user(cos_u, dsp_user, cos_r, s0, s0 - mls_systemhigh, >>>>>> mcs_allcats) ================ >>>>>> >>>>>> And now the code has compiled with no errors. Is there anything we need to be careful of that the 2 macros are doing that could be interfering with each other? >>>>>> >>>>> >>>>> Exactly. The gen_user() call has to be the last line in the policy module, or else it wont work and you will get that very unhelpful error. >>>>> >>>>> As for IRC: I am not sure what channel youve tried but we're on >>>>> #selinux at irc.freenode.org >>>>> >>>>> >>>>>> Thanks & Regards, >>>>>> Walid >>>>>> >>>>>> -----Original Message----- >>>>>> From: Borg-Cardona, Jack >>>>>> Sent: 28 July 2016 11:06 >>>>>> To: Fakim, Walid >>>>>> Subject: FW: [refpolicy] Compile Error when using the userdom_login_user_template() macro... >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: refpolicy-bounces at oss.tresys.com >>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Dominick >>>>>> Grift >>>>>> Sent: 28 July 2016 10:44 >>>>>> To: refpolicy at oss.tresys.com >>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro... >>>>>> >>>>>> On 07/28/2016 11:02 AM, Borg-Cardona, Jack wrote: >>>>>>> Morning, >>>>>>> >>>>>>> I've been working on my first custom policies recently and have begun the compile process and am working through the various syntax errors I have made. I have come across one error that I can't decipher, and does not seem to reference the syntax in my own policy but rather the syntax in the tmp/cosapp.tmp folder that is created at compile time. >>>>>>> >>>>>> >>>>>> Hi, Is this refpolicy or some fork (redhat maybe?) If this is a >>>>>> redhat fork then you might want to ask on the fedora-selinux >>>>>> maillist or #fedora-selinux or irc.freenode.org for better >>>>>> results >>>>>> >>>>>> Regardless, I would probably start by narrowing this down. >>>>>> >>>>>> cat >>mytest.te<>>>>> policy_module(mytest,1.0.0) >>>>>> userdom_login_user_template(cos) >>>>>> EOF >>>>>> make -f /usr/share/selinux/devel/Makefile mytest.pp >>>>>> >>>>>> Do you see the same error message? >>>>>> >>>>>> >>>>>>> >From my policy (.te) the offending line is: >>>>>>> userdom_login_user_template(cos) >>>>>>> >>>>>>> The error message is: >>>>>>> cosapp.te":61:ERROR 'syntax error' at token 'require' on line 4050: >>>>>>> require { >>>>>>> #line 61 >>>>>>> /usr/bin/checkmodule: error(s) encountered while parsing >>>>>>> configuration >>>>>>> make: *** [tmp/cosapp.mod] Error 1 >>>>>>> >>>>>>> Looking at the cospp.tmp file more closely I went to line 4050 >>>>>>> #line >>>>>>> 61 >>>>>>> require { >>>>>>> #line 61 >>>>>>> >>>>>>> #line 61 >>>>>>> class context contains; #line 61 >>>>>>> attribute login_userdomain; #line 61 >>>>>>> >>>>>>> #line 61 >>>>>>> } # end require >>>>>>> As this is not my syntax I am a bit puzzled as to what is actually wrong? >>>>>>> A couple of thoughts that I had are: >>>>>>> The macro userdom_login_user_template(cos)references a new custom user 'cos_u' I have not yet added the user file_contexts file to /etc/selinux/targeted/contexts/users so could this be causing the error? If so I am surprised that the gen_user() statement the line before works. >>>>>>> Are there any dependencies I need to consider for this template to work, that I may not have thought about? >>>>>>> >>>>>>> Then finally I jumped on the IRC channel yesterday no one was around, what time to people tend to be on it? >>>>>>> >>>>>>> Thanks for the help >>>>>>> Jack >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> refpolicy mailing list >>>>>>> refpolicy at oss.tresys.com >>>>>>> http://oss.tresys.com/mailman/listinfo/refpolicy >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B >>>>>> 6B02 >>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7 >>>>>> B >>>>>> 6 >>>>>> B >>>>>> 0 >>>>>> 2 >>>>>> Dominick Grift >>>>>> >>>>>> _______________________________________________ >>>>>> refpolicy mailing list >>>>>> refpolicy at oss.tresys.com >>>>>> http://oss.tresys.com/mailman/listinfo/refpolicy >>>>>> >>>>> >>>>> >>>>> -- >>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B >>>>> 6B02 >>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B >>>>> 6 >>>>> B >>>>> 0 >>>>> 2 >>>>> Dominick Grift >>>>> >>>> >>>> >>>> -- >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B >>>> 6B02 >>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6 >>>> B >>>> 0 >>>> 2 >>>> Dominick Grift >>>> >>> >>> >>> -- >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B >>> 0 >>> 2 >>> Dominick Grift >>> >> >> >> -- >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B0 >> 2 >> Dominick Grift >> > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > Dominick Grift > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift