[refpolicy] Compile Error when using the userdom_login_user_template() macro...

[dac.override@gmail.com (Dominick Grift)]

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<<EOF
type myjava_exec_t;
application_executable_file(myjava_exec_t)
EOF

cat >myjava.fc<<EOF
/usr/bin/java -- gen_context(system_u:object_r:myjava_exec_t,s0)
EOF

make -f /usr/share/selinux/devel/Makefile myjava.pp
sudo semodule -i myjava.pp

seinfo -t | grep myjava_exec_t

Now you will have a conflict with the existing file context spec for
java_exec_t. because now selinux does not know whether to label
/usr/bin/java type java_exec_t or myjava_exec_t

One (possible) solution may be to disable the existing java module:

semodule -d java

This will disable the existing fc spec for /usr/bin/java if possible

restore the context of /usr/bin/java:

restorecon -v /usr/bin/java

> 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<<EOF
>>>>>> 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=0x3B6C5F1D2C7B
>>>>>> 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=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
> 


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160803/21c07c85/attachment.bin