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

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

[Borg-Cardona, Jack]

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.

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160728/5a4022a5/attachment.html 

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

[Dominick Grift]

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=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/20160728/a3c3ea08/attachment-0001.bin 

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

[Fakim, Walid]

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?

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@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=0x3B6C5F1D2C7B6B02
Dominick Grift

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

[Dominick Grift]

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=0x3B6C5F1D2C7B6B02
> 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=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/20160728/d5097dee/attachment.bin 

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

[Fakim, Walid]

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?

Thanks & Regards,
Walid

-----Original Message-----
From: refpolicy-bounces@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=0x3B6C5F1D2C7B6B02
> 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=0x3B6C5F1D2C7B6B02
Dominick Grift

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

[Dominick Grift]

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=0x3B6C5F1D2C7B6B02
>> 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=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/20160728/34dddb8b/attachment.bin 

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

[Dominick Grift]

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=0x3B6C5F1D2C7B6B0
>>> 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=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/20160801/521c18ef/attachment.bin 

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

[Fakim, Walid]

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!

=====

	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=0x3B6C5F1D2C7B6B
>>> 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=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

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

[Dominick Grift]

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=0x3B6C5F1D2C7B6B
>>>> 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=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/20160802/642a2dd4/attachment-0001.bin 

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

[Fakim, Walid]

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.



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=0x3B6C5F1D2C7B6
>>>> 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=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

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

[Dominick Grift]

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=0x3B6C5F1D2C7B6
>>>>> 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=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/20160802/89dde5be/attachment-0001.bin 

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

[Fakim, Walid]

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.

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

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

[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 

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

[Borg-Cardona, Jack]

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<<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=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

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

[Fakim, Walid]

Morning Dominick,

Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Borg-Cardona, Jack 
Sent: 03 August 2016 09:25
To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

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<<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=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

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

[Fakim, Walid]

Hi Dominick & All,

Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.

It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:

=====

-sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad interpreter: Permission denied

=====

Here is the init script that we run to start up the "apache-tomcat" service (I called this apache-tomcat as I also have the packaged tomcat version running installed via yum to compare parameters when they are running etc)

========

[root at server2 ~]# cat /etc/init.d/apache-tomcat
#!/bin/bash
# description: Tomcat Start Stop Restart
# processname: tomcat
# chkconfig: 234 20 80
JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
export CATALINA_HOME
case $1 in
start)
/sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
;;
stop)
/sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
;;
restart)
/sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
/sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
;;
esac
exit 0

==========

When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):

==========

|-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
  |   |-{java},`system_u:system_r:tomcat_t:s0'


  |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
  |   |-{java},`system_u:jboss_r:jboss_java_t:s0'

===============

I've attached the policy module .te file for convenience as well.

We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: refpolicy-bounces@oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
Sent: 03 August 2016 11:30
To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

Morning Dominick,

Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Borg-Cardona, Jack
Sent: 03 August 2016 09:25
To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

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<<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=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

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: poc_proto.te
Type: application/octet-stream
Size: 5249 bytes
Desc: poc_proto.te
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160815/ad5ffa31/attachment-0001.obj 

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

[Dominick Grift]

On 08/15/2016 03:15 PM, Fakim, Walid wrote:
> Hi Dominick & All,
> 
> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
> 
> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
> 

You would do what you alway's do in such situations:

1. run semodule -DB to build/load the policy without the "dontaudit"
rules inserted

2. reproduce the issues

3. look again for avc denials that may be related

4. run semodule -B to build/load the policy with the "dontaudit" rules
re-inserted

When you have some avc denials that look related, you start by
processing them all. Then see if the issue is fixed. Then after you
confirmed that the issue is fixed. You comment individual rules one by
one until you have identified which rules are needed and which rules are
not needed.

> =====
> 
> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad interpreter: Permission denied
> 
> =====
> 
> Here is the init script that we run to start up the "apache-tomcat" service (I called this apache-tomcat as I also have the packaged tomcat version running installed via yum to compare parameters when they are running etc)
> 
> ========
> 
> [root at server2 ~]# cat /etc/init.d/apache-tomcat
> #!/bin/bash
> # description: Tomcat Start Stop Restart
> # processname: tomcat
> # chkconfig: 234 20 80
> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
> export JAVA_HOME
> PATH=$JAVA_HOME/bin:$PATH
> export PATH
> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
> export CATALINA_HOME
> case $1 in
> start)
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
> ;;
> stop)
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
> ;;
> restart)
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
> ;;
> esac
> exit 0
> 
> ==========
> 
> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
> 
> ==========
> 
> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>   |   |-{java},`system_u:system_r:tomcat_t:s0'
> 
> 
>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
> 
> ===============
> 
> I've attached the policy module .te file for convenience as well.
> 
> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
> Sent: 03 August 2016 11:30
> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> Morning Dominick,
> 
> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Borg-Cardona, Jack
> Sent: 03 August 2016 09:25
> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> 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<<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=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
> 
> _______________________________________________
> 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=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/20160815/e1f166dd/attachment.bin 

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

[Fakim, Walid]

Nice one - thanks I'll give that a shot.

Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 15 August 2016 14:22
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/15/2016 03:15 PM, Fakim, Walid wrote:
> Hi Dominick & All,
> 
> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
> 
> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
> 

You would do what you alway's do in such situations:

1. run semodule -DB to build/load the policy without the "dontaudit"
rules inserted

2. reproduce the issues

3. look again for avc denials that may be related

4. run semodule -B to build/load the policy with the "dontaudit" rules re-inserted

When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.

> =====
> 
> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad 
> interpreter: Permission denied
> 
> =====
> 
> Here is the init script that we run to start up the "apache-tomcat" 
> service (I called this apache-tomcat as I also have the packaged 
> tomcat version running installed via yum to compare parameters when 
> they are running etc)
> 
> ========
> 
> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash # 
> description: Tomcat Start Stop Restart # processname: tomcat # 
> chkconfig: 234 20 80
> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
> export JAVA_HOME
> PATH=$JAVA_HOME/bin:$PATH
> export PATH
> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
> export CATALINA_HOME
> case $1 in
> start)
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
> ;;
> stop)
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
> ;;
> restart)
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
> ;;
> esac
> exit 0
> 
> ==========
> 
> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
> 
> ==========
> 
> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>   |   |-{java},`system_u:system_r:tomcat_t:s0'
> 
> 
>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
> 
> ===============
> 
> I've attached the policy module .te file for convenience as well.
> 
> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com 
> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
> Sent: 03 August 2016 11:30
> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> Morning Dominick,
> 
> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Borg-Cardona, Jack
> Sent: 03 August 2016 09:25
> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> 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<<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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 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=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
> 
> _______________________________________________
> 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=0x3B6C5F1D2C7B6B02
Dominick Grift

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

[Dominick Grift]

On 08/15/2016 03:32 PM, Fakim, Walid wrote:
> Nice one - thanks I'll give that a shot.
> 
> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
> 
> Thanks.
> 

Not that I am aware of but i just took a quick look at your .te file and
it looks strange to me (to say the least).

However I do not know your requirements, environment, and properties so
I can't really suggest alternative approaches, improvements. (maybe
someone else on this list wants to suggest improvements?)

If it works it works (and with work i mean not just if it runs but also
if your security goals are verified to be achieved)

> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 15 August 2016 14:22
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>> Hi Dominick & All,
>>
>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>
>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>
> 
> You would do what you alway's do in such situations:
> 
> 1. run semodule -DB to build/load the policy without the "dontaudit"
> rules inserted
> 
> 2. reproduce the issues
> 
> 3. look again for avc denials that may be related
> 
> 4. run semodule -B to build/load the policy with the "dontaudit" rules re-inserted
> 
> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
> 
>> =====
>>
>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad 
>> interpreter: Permission denied
>>
>> =====
>>
>> Here is the init script that we run to start up the "apache-tomcat" 
>> service (I called this apache-tomcat as I also have the packaged 
>> tomcat version running installed via yum to compare parameters when 
>> they are running etc)
>>
>> ========
>>
>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash # 
>> description: Tomcat Start Stop Restart # processname: tomcat # 
>> chkconfig: 234 20 80
>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>> export JAVA_HOME
>> PATH=$JAVA_HOME/bin:$PATH
>> export PATH
>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>> export CATALINA_HOME
>> case $1 in
>> start)
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>> ;;
>> stop)
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>> ;;
>> restart)
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>> ;;
>> esac
>> exit 0
>>
>> ==========
>>
>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>
>> ==========
>>
>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>
>>
>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>
>> ===============
>>
>> I've attached the policy module .te file for convenience as well.
>>
>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: refpolicy-bounces at oss.tresys.com 
>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>> Sent: 03 August 2016 11:30
>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> Morning Dominick,
>>
>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Borg-Cardona, Jack
>> Sent: 03 August 2016 09:25
>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> 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<<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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 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=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
>>
>> _______________________________________________
>> 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=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/20160815/16b897d9/attachment-0001.bin 

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

[Fakim, Walid]

Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).

To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 15 August 2016 14:44
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/15/2016 03:32 PM, Fakim, Walid wrote:
> Nice one - thanks I'll give that a shot.
> 
> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
> 
> Thanks.
> 

Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).

However I do not know your requirements, environment, and properties so I can't really suggest alternative approaches, improvements. (maybe someone else on this list wants to suggest improvements?)

If it works it works (and with work i mean not just if it runs but also if your security goals are verified to be achieved)

> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 14:22
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>> Hi Dominick & All,
>>
>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>
>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>
> 
> You would do what you alway's do in such situations:
> 
> 1. run semodule -DB to build/load the policy without the "dontaudit"
> rules inserted
> 
> 2. reproduce the issues
> 
> 3. look again for avc denials that may be related
> 
> 4. run semodule -B to build/load the policy with the "dontaudit" rules 
> re-inserted
> 
> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
> 
>> =====
>>
>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>> interpreter: Permission denied
>>
>> =====
>>
>> Here is the init script that we run to start up the "apache-tomcat" 
>> service (I called this apache-tomcat as I also have the packaged 
>> tomcat version running installed via yum to compare parameters when 
>> they are running etc)
>>
>> ========
>>
>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>> description: Tomcat Start Stop Restart # processname: tomcat #
>> chkconfig: 234 20 80
>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>> export JAVA_HOME
>> PATH=$JAVA_HOME/bin:$PATH
>> export PATH
>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>> export CATALINA_HOME
>> case $1 in
>> start)
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>> ;;
>> stop)
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>> ;;
>> restart)
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>> ;;
>> esac
>> exit 0
>>
>> ==========
>>
>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>
>> ==========
>>
>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>
>>
>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>
>> ===============
>>
>> I've attached the policy module .te file for convenience as well.
>>
>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: refpolicy-bounces at oss.tresys.com 
>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>> Sent: 03 August 2016 11:30
>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> Morning Dominick,
>>
>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Borg-Cardona, Jack
>> Sent: 03 August 2016 09:25
>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> 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<<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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 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=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
>>
>> _______________________________________________
>> 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=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

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

[Dominick Grift]

On 08/15/2016 04:07 PM, Fakim, Walid wrote:
> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
> 
> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.

Why does that user need to be a login user? Isnt that just a system user?

Basically now you have a jboss_t type that has at least 3 different
uses: 1. a login shell process, 2. an application process 3. an init
daemon process

I suspect you dont need that login user stuff, and you dont need the
jboss_r role. Basically i suspect that you dont need a lot of what you
have there.

But again, if it works for you then it works (dont fix what isnt broken)

> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 15 August 2016 14:44
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>> Nice one - thanks I'll give that a shot.
>>
>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>
>> Thanks.
>>
> 
> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
> 
> However I do not know your requirements, environment, and properties so I can't really suggest alternative approaches, improvements. (maybe someone else on this list wants to suggest improvements?)
> 
> If it works it works (and with work i mean not just if it runs but also if your security goals are verified to be achieved)
> 
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 14:22
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>> Hi Dominick & All,
>>>
>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>
>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>
>>
>> You would do what you alway's do in such situations:
>>
>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>> rules inserted
>>
>> 2. reproduce the issues
>>
>> 3. look again for avc denials that may be related
>>
>> 4. run semodule -B to build/load the policy with the "dontaudit" rules 
>> re-inserted
>>
>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>
>>> =====
>>>
>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>> interpreter: Permission denied
>>>
>>> =====
>>>
>>> Here is the init script that we run to start up the "apache-tomcat" 
>>> service (I called this apache-tomcat as I also have the packaged 
>>> tomcat version running installed via yum to compare parameters when 
>>> they are running etc)
>>>
>>> ========
>>>
>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>> chkconfig: 234 20 80
>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>> export JAVA_HOME
>>> PATH=$JAVA_HOME/bin:$PATH
>>> export PATH
>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>> export CATALINA_HOME
>>> case $1 in
>>> start)
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>> ;;
>>> stop)
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>> ;;
>>> restart)
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>> ;;
>>> esac
>>> exit 0
>>>
>>> ==========
>>>
>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>
>>> ==========
>>>
>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>
>>>
>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>
>>> ===============
>>>
>>> I've attached the policy module .te file for convenience as well.
>>>
>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: refpolicy-bounces at oss.tresys.com 
>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>> Sent: 03 August 2016 11:30
>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> Morning Dominick,
>>>
>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Borg-Cardona, Jack
>>> Sent: 03 August 2016 09:25
>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> 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<<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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 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=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
>>>
>>> _______________________________________________
>>> 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=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/20160815/a89cbb1b/attachment-0001.bin 

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

[Fakim, Walid]

OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need. How can I link my linux user say jbosslinuxuser to the correct SELinux user and role to confine my application but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?

I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 15 August 2016 15:13
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/15/2016 04:07 PM, Fakim, Walid wrote:
> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
> 
> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.

Why does that user need to be a login user? Isnt that just a system user?

Basically now you have a jboss_t type that has at least 3 different
uses: 1. a login shell process, 2. an application process 3. an init daemon process

I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.

But again, if it works for you then it works (dont fix what isnt broken)

> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 14:44
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>> Nice one - thanks I'll give that a shot.
>>
>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>
>> Thanks.
>>
> 
> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
> 
> However I do not know your requirements, environment, and properties 
> so I can't really suggest alternative approaches, improvements. (maybe 
> someone else on this list wants to suggest improvements?)
> 
> If it works it works (and with work i mean not just if it runs but 
> also if your security goals are verified to be achieved)
> 
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 14:22
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>> Hi Dominick & All,
>>>
>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>
>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>
>>
>> You would do what you alway's do in such situations:
>>
>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>> rules inserted
>>
>> 2. reproduce the issues
>>
>> 3. look again for avc denials that may be related
>>
>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>> rules re-inserted
>>
>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>
>>> =====
>>>
>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>> interpreter: Permission denied
>>>
>>> =====
>>>
>>> Here is the init script that we run to start up the "apache-tomcat" 
>>> service (I called this apache-tomcat as I also have the packaged 
>>> tomcat version running installed via yum to compare parameters when 
>>> they are running etc)
>>>
>>> ========
>>>
>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>> chkconfig: 234 20 80
>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>> export JAVA_HOME
>>> PATH=$JAVA_HOME/bin:$PATH
>>> export PATH
>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>> export CATALINA_HOME
>>> case $1 in
>>> start)
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>> ;;
>>> stop)
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>> ;;
>>> restart)
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>> ;;
>>> esac
>>> exit 0
>>>
>>> ==========
>>>
>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>
>>> ==========
>>>
>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>
>>>
>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>
>>> ===============
>>>
>>> I've attached the policy module .te file for convenience as well.
>>>
>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: refpolicy-bounces at oss.tresys.com 
>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>> Sent: 03 August 2016 11:30
>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> Morning Dominick,
>>>
>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Borg-Cardona, Jack
>>> Sent: 03 August 2016 09:25
>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> 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<<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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 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=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
>>>
>>> _______________________________________________
>>> 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=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

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

[Dominick Grift]

On 08/15/2016 04:35 PM, Fakim, Walid wrote:
> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.

I am saying that, in my view and with the information i have to my
disposal, there is no to create additional "_u"'s and "_r"'s

 How can I link my linux user say jbosslinuxuser to the correct SELinux
user and role to confine my application

I would need more infomation about the nature of this user. Is this user
a login user or a system user (can the user log into the system or is it
just a system user to run the application with?)

If this is a real login user, then what context is associated with that
user currently. and what privileges is this user supposed to have.

 but at the same time not give jbosslinuxuser full system privileges via
system_u and system_r?

I think i see where you might be going with this but I am not sure.

1. your jboss application is a system service (init daemon)
2. your jboss application does not run as root but instead it runs with
the jbosslinuxuser identity.

Are the above two assumptions right?

what does: grep jbosslinuxuser /etc/passwd
return?

> 
> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 15 August 2016 15:13
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>
>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
> 
> Why does that user need to be a login user? Isnt that just a system user?
> 
> Basically now you have a jboss_t type that has at least 3 different
> uses: 1. a login shell process, 2. an application process 3. an init daemon process
> 
> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
> 
> But again, if it works for you then it works (dont fix what isnt broken)
> 
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 14:44
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>> Nice one - thanks I'll give that a shot.
>>>
>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>
>>> Thanks.
>>>
>>
>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>
>> However I do not know your requirements, environment, and properties 
>> so I can't really suggest alternative approaches, improvements. (maybe 
>> someone else on this list wants to suggest improvements?)
>>
>> If it works it works (and with work i mean not just if it runs but 
>> also if your security goals are verified to be achieved)
>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 14:22
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>> Hi Dominick & All,
>>>>
>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>
>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>
>>>
>>> You would do what you alway's do in such situations:
>>>
>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>> rules inserted
>>>
>>> 2. reproduce the issues
>>>
>>> 3. look again for avc denials that may be related
>>>
>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>> rules re-inserted
>>>
>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>
>>>> =====
>>>>
>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>> interpreter: Permission denied
>>>>
>>>> =====
>>>>
>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>> service (I called this apache-tomcat as I also have the packaged 
>>>> tomcat version running installed via yum to compare parameters when 
>>>> they are running etc)
>>>>
>>>> ========
>>>>
>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>> chkconfig: 234 20 80
>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>> export JAVA_HOME
>>>> PATH=$JAVA_HOME/bin:$PATH
>>>> export PATH
>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>> export CATALINA_HOME
>>>> case $1 in
>>>> start)
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>> ;;
>>>> stop)
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>> ;;
>>>> restart)
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>> ;;
>>>> esac
>>>> exit 0
>>>>
>>>> ==========
>>>>
>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>
>>>> ==========
>>>>
>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>
>>>>
>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>
>>>> ===============
>>>>
>>>> I've attached the policy module .te file for convenience as well.
>>>>
>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: refpolicy-bounces at oss.tresys.com 
>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>>> Sent: 03 August 2016 11:30
>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> Morning Dominick,
>>>>
>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Borg-Cardona, Jack
>>>> Sent: 03 August 2016 09:25
>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> 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<<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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 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=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
>>>>
>>>> _______________________________________________
>>>> 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=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: 644 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160815/c2850489/attachment-0001.bin 

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

[Fakim, Walid]

jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash

Your assumptions 1 and 2 are correct.

I also see your points about using system_u and system_r. 

The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.

[root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
jbossman        user       s0         s0-s0:c0.c1023                 jboss_r

====

jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.

Does that give you enough to go by?

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 15 August 2016 15:55
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/15/2016 04:35 PM, Fakim, Walid wrote:
> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.

I am saying that, in my view and with the information i have to my disposal, there is no to create additional "_u"'s and "_r"'s

 How can I link my linux user say jbosslinuxuser to the correct SELinux user and role to confine my application

I would need more infomation about the nature of this user. Is this user a login user or a system user (can the user log into the system or is it just a system user to run the application with?)

If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.

 but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?

I think i see where you might be going with this but I am not sure.

1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.

Are the above two assumptions right?

what does: grep jbosslinuxuser /etc/passwd return?

> 
> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 15:13
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>
>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
> 
> Why does that user need to be a login user? Isnt that just a system user?
> 
> Basically now you have a jboss_t type that has at least 3 different
> uses: 1. a login shell process, 2. an application process 3. an init 
> daemon process
> 
> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
> 
> But again, if it works for you then it works (dont fix what isnt 
> broken)
> 
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 14:44
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>> Nice one - thanks I'll give that a shot.
>>>
>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>
>>> Thanks.
>>>
>>
>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>
>> However I do not know your requirements, environment, and properties 
>> so I can't really suggest alternative approaches, improvements. 
>> (maybe someone else on this list wants to suggest improvements?)
>>
>> If it works it works (and with work i mean not just if it runs but 
>> also if your security goals are verified to be achieved)
>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 14:22
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>> Hi Dominick & All,
>>>>
>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>
>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>
>>>
>>> You would do what you alway's do in such situations:
>>>
>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>> rules inserted
>>>
>>> 2. reproduce the issues
>>>
>>> 3. look again for avc denials that may be related
>>>
>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>> rules re-inserted
>>>
>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>
>>>> =====
>>>>
>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>> interpreter: Permission denied
>>>>
>>>> =====
>>>>
>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>> service (I called this apache-tomcat as I also have the packaged 
>>>> tomcat version running installed via yum to compare parameters when 
>>>> they are running etc)
>>>>
>>>> ========
>>>>
>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>> chkconfig: 234 20 80
>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>> export JAVA_HOME
>>>> PATH=$JAVA_HOME/bin:$PATH
>>>> export PATH
>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>> export CATALINA_HOME
>>>> case $1 in
>>>> start)
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>> ;;
>>>> stop)
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>> ;;
>>>> restart)
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>> ;;
>>>> esac
>>>> exit 0
>>>>
>>>> ==========
>>>>
>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>
>>>> ==========
>>>>
>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>
>>>>
>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>
>>>> ===============
>>>>
>>>> I've attached the policy module .te file for convenience as well.
>>>>
>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: refpolicy-bounces at oss.tresys.com 
>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>>> Sent: 03 August 2016 11:30
>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> Morning Dominick,
>>>>
>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Borg-Cardona, Jack
>>>> Sent: 03 August 2016 09:25
>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> 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<<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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 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=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
>>>>
>>>> _______________________________________________
>>>> 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=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

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

[Dominick Grift]

On 08/15/2016 05:12 PM, Fakim, Walid wrote:
> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
> 
> Your assumptions 1 and 2 are correct.
> 

Then why is user jboss_tomcat associated with a shell? associate it with
/sbin/nologin instead because this "system user" is not supposed to have
a login shell.

> I also see your points about using system_u and system_r. 
> 
> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.

Ok so you want a confined administrator (a user that can only manage the
apache-tomcat)

For now i would advice that you wait with the confined admin. First just
create the policy for your system service and make sure that works.

Once that is done we can look at creating the confined admin.

Because your current module is a little unwieldy. I cannot make sense of
all of it.

So if you remove all the noise from the module and stick with the basic
service , then i can hopefully make more sense of it and review that and
when that looks solid we can look at adding the confined admin user. I
will help you with that then if you want.

But first things first: deal with the service in the simplest possible way.

> 
> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
> 
> ====
> 
> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
> 
> Does that give you enough to go by?
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 15 August 2016 15:55
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
> 
> I am saying that, in my view and with the information i have to my disposal, there is no to create additional "_u"'s and "_r"'s
> 
>  How can I link my linux user say jbosslinuxuser to the correct SELinux user and role to confine my application
> 
> I would need more infomation about the nature of this user. Is this user a login user or a system user (can the user log into the system or is it just a system user to run the application with?)
> 
> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
> 
>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
> 
> I think i see where you might be going with this but I am not sure.
> 
> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
> 
> Are the above two assumptions right?
> 
> what does: grep jbosslinuxuser /etc/passwd return?
> 
>>
>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 15:13
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>
>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>
>> Why does that user need to be a login user? Isnt that just a system user?
>>
>> Basically now you have a jboss_t type that has at least 3 different
>> uses: 1. a login shell process, 2. an application process 3. an init 
>> daemon process
>>
>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>
>> But again, if it works for you then it works (dont fix what isnt 
>> broken)
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 14:44
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>> Nice one - thanks I'll give that a shot.
>>>>
>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>
>>>> Thanks.
>>>>
>>>
>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>
>>> However I do not know your requirements, environment, and properties 
>>> so I can't really suggest alternative approaches, improvements. 
>>> (maybe someone else on this list wants to suggest improvements?)
>>>
>>> If it works it works (and with work i mean not just if it runs but 
>>> also if your security goals are verified to be achieved)
>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 14:22
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>> Hi Dominick & All,
>>>>>
>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>
>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>
>>>>
>>>> You would do what you alway's do in such situations:
>>>>
>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>> rules inserted
>>>>
>>>> 2. reproduce the issues
>>>>
>>>> 3. look again for avc denials that may be related
>>>>
>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>> rules re-inserted
>>>>
>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>
>>>>> =====
>>>>>
>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>>> interpreter: Permission denied
>>>>>
>>>>> =====
>>>>>
>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>> tomcat version running installed via yum to compare parameters when 
>>>>> they are running etc)
>>>>>
>>>>> ========
>>>>>
>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>> chkconfig: 234 20 80
>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>> export JAVA_HOME
>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>> export PATH
>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>> export CATALINA_HOME
>>>>> case $1 in
>>>>> start)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>> ;;
>>>>> stop)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>> ;;
>>>>> restart)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>> ;;
>>>>> esac
>>>>> exit 0
>>>>>
>>>>> ==========
>>>>>
>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>
>>>>> ==========
>>>>>
>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>
>>>>>
>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>
>>>>> ===============
>>>>>
>>>>> I've attached the policy module .te file for convenience as well.
>>>>>
>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>>>> Sent: 03 August 2016 11:30
>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> Morning Dominick,
>>>>>
>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Borg-Cardona, Jack
>>>>> Sent: 03 August 2016 09:25
>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> 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<<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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 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=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
>>>>>
>>>>> _______________________________________________
>>>>> 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=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/20160815/7fde3eb0/attachment-0001.bin 

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

[Fakim, Walid]

Sounds good Dominick - Thanks for the help.



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 15 August 2016 16:24
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/15/2016 05:12 PM, Fakim, Walid wrote:
> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
> 
> Your assumptions 1 and 2 are correct.
> 

Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.

> I also see your points about using system_u and system_r. 
> 
> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.

Ok so you want a confined administrator (a user that can only manage the
apache-tomcat)

For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.

Once that is done we can look at creating the confined admin.

Because your current module is a little unwieldy. I cannot make sense of all of it.

So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.

But first things first: deal with the service in the simplest possible way.

> 
> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
> 
> ====
> 
> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
> 
> Does that give you enough to go by?
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 15:55
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
> 
> I am saying that, in my view and with the information i have to my 
> disposal, there is no to create additional "_u"'s and "_r"'s
> 
>  How can I link my linux user say jbosslinuxuser to the correct 
> SELinux user and role to confine my application
> 
> I would need more infomation about the nature of this user. Is this 
> user a login user or a system user (can the user log into the system 
> or is it just a system user to run the application with?)
> 
> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
> 
>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
> 
> I think i see where you might be going with this but I am not sure.
> 
> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
> 
> Are the above two assumptions right?
> 
> what does: grep jbosslinuxuser /etc/passwd return?
> 
>>
>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 15:13
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>
>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>
>> Why does that user need to be a login user? Isnt that just a system user?
>>
>> Basically now you have a jboss_t type that has at least 3 different
>> uses: 1. a login shell process, 2. an application process 3. an init 
>> daemon process
>>
>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>
>> But again, if it works for you then it works (dont fix what isnt
>> broken)
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 14:44
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>> Nice one - thanks I'll give that a shot.
>>>>
>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>
>>>> Thanks.
>>>>
>>>
>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>
>>> However I do not know your requirements, environment, and properties 
>>> so I can't really suggest alternative approaches, improvements.
>>> (maybe someone else on this list wants to suggest improvements?)
>>>
>>> If it works it works (and with work i mean not just if it runs but 
>>> also if your security goals are verified to be achieved)
>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 14:22
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>> Hi Dominick & All,
>>>>>
>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>
>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>
>>>>
>>>> You would do what you alway's do in such situations:
>>>>
>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>> rules inserted
>>>>
>>>> 2. reproduce the issues
>>>>
>>>> 3. look again for avc denials that may be related
>>>>
>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>> rules re-inserted
>>>>
>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>
>>>>> =====
>>>>>
>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>>> interpreter: Permission denied
>>>>>
>>>>> =====
>>>>>
>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>> tomcat version running installed via yum to compare parameters 
>>>>> when they are running etc)
>>>>>
>>>>> ========
>>>>>
>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>> chkconfig: 234 20 80
>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>> export JAVA_HOME
>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>> export PATH
>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>> export CATALINA_HOME
>>>>> case $1 in
>>>>> start)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>> ;;
>>>>> stop)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>> ;;
>>>>> restart)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>> ;;
>>>>> esac
>>>>> exit 0
>>>>>
>>>>> ==========
>>>>>
>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>
>>>>> ==========
>>>>>
>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>
>>>>>
>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>
>>>>> ===============
>>>>>
>>>>> I've attached the policy module .te file for convenience as well.
>>>>>
>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>> Walid
>>>>> Sent: 03 August 2016 11:30
>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> Morning Dominick,
>>>>>
>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Borg-Cardona, Jack
>>>>> Sent: 03 August 2016 09:25
>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> 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<<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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 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=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

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

[Fakim, Walid]

Hi Dominick,

Quick question : From your comments, am understanding that for a service to run, it always makes sense to run that service as system_u:system_r:service_domain_t

What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.

It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.

Thanks.

Best Regards,

Walid Fakim

-----Original Message-----
From: refpolicy-bounces@oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
Sent: 15 August 2016 16:30
To: Dominick Grift; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

Sounds good Dominick - Thanks for the help.



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com]
Sent: 15 August 2016 16:24
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/15/2016 05:12 PM, Fakim, Walid wrote:
> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
> 
> Your assumptions 1 and 2 are correct.
> 

Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.

> I also see your points about using system_u and system_r. 
> 
> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.

Ok so you want a confined administrator (a user that can only manage the
apache-tomcat)

For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.

Once that is done we can look at creating the confined admin.

Because your current module is a little unwieldy. I cannot make sense of all of it.

So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.

But first things first: deal with the service in the simplest possible way.

> 
> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
> 
> ====
> 
> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
> 
> Does that give you enough to go by?
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 15:55
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
> 
> I am saying that, in my view and with the information i have to my 
> disposal, there is no to create additional "_u"'s and "_r"'s
> 
>  How can I link my linux user say jbosslinuxuser to the correct 
> SELinux user and role to confine my application
> 
> I would need more infomation about the nature of this user. Is this 
> user a login user or a system user (can the user log into the system 
> or is it just a system user to run the application with?)
> 
> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
> 
>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
> 
> I think i see where you might be going with this but I am not sure.
> 
> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
> 
> Are the above two assumptions right?
> 
> what does: grep jbosslinuxuser /etc/passwd return?
> 
>>
>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 15:13
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>
>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>
>> Why does that user need to be a login user? Isnt that just a system user?
>>
>> Basically now you have a jboss_t type that has at least 3 different
>> uses: 1. a login shell process, 2. an application process 3. an init 
>> daemon process
>>
>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>
>> But again, if it works for you then it works (dont fix what isnt
>> broken)
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 14:44
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>> Nice one - thanks I'll give that a shot.
>>>>
>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>
>>>> Thanks.
>>>>
>>>
>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>
>>> However I do not know your requirements, environment, and properties 
>>> so I can't really suggest alternative approaches, improvements.
>>> (maybe someone else on this list wants to suggest improvements?)
>>>
>>> If it works it works (and with work i mean not just if it runs but 
>>> also if your security goals are verified to be achieved)
>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 14:22
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>> Hi Dominick & All,
>>>>>
>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>
>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>
>>>>
>>>> You would do what you alway's do in such situations:
>>>>
>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>> rules inserted
>>>>
>>>> 2. reproduce the issues
>>>>
>>>> 3. look again for avc denials that may be related
>>>>
>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>> rules re-inserted
>>>>
>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>
>>>>> =====
>>>>>
>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>>> interpreter: Permission denied
>>>>>
>>>>> =====
>>>>>
>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>> tomcat version running installed via yum to compare parameters 
>>>>> when they are running etc)
>>>>>
>>>>> ========
>>>>>
>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>> chkconfig: 234 20 80
>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>> export JAVA_HOME
>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>> export PATH
>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>> export CATALINA_HOME
>>>>> case $1 in
>>>>> start)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>> ;;
>>>>> stop)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>> ;;
>>>>> restart)
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>> ;;
>>>>> esac
>>>>> exit 0
>>>>>
>>>>> ==========
>>>>>
>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>
>>>>> ==========
>>>>>
>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>
>>>>>
>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>
>>>>> ===============
>>>>>
>>>>> I've attached the policy module .te file for convenience as well.
>>>>>
>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>> Walid
>>>>> Sent: 03 August 2016 11:30
>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> Morning Dominick,
>>>>>
>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Borg-Cardona, Jack
>>>>> Sent: 03 August 2016 09:25
>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> 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<<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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 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=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

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

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

[Dominick Grift]

On 08/16/2016 03:36 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Quick question : From your comments, am understanding that for a service to run, it always makes sense to run that service as system_u:system_r:service_domain_t

Atleast system_r:service_domain_t, if this is started by the system.

> 
> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
> 

The way confined admins commonly work is:

1. the existing staff_r role is used to allow the admin to login.
You would create a new selinux user id (for example jboss_tomcat_adm_u),
then associate the staff_r role and system_r role with that user id.

2. then you would create a admin role. This role can be access via sudo
example: jboss_tomcat_adm_r
that role is then also associated to the jboss_tomcat_adm_u selinux id,
so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r
system_r and jboss_tomcat_r)

3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t

4. the user can now use sudo to change to his privileged
jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s

5. now the user has context:
jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t

+ is associated with root

6. this allows root associated with
jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t

to manage the system service: example: sudo -r jboss_tomcat_adm_r
service jboss_tomcat start

Then there is a rule that tells selinux when a process associated with
role jboss_tomcat_adm_r executes an init script file with type
jboss_tomcat_initrc_exec_t, then automatically role transition from
jboss_tomcat_adm_r to system_r

thus the service ends up with:

jboss_tomcat_adm_u:system_r:jboss_tomcat_t

if it is started manually via the init script by the admin and with

system_u:system_r:jboss_tomcat_t

if it is started by the system user

I hope that clears at least some of this up


> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
> Sent: 15 August 2016 16:30
> To: Dominick Grift; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> Sounds good Dominick - Thanks for the help.
> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 16:24
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>
>> Your assumptions 1 and 2 are correct.
>>
> 
> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
> 
>> I also see your points about using system_u and system_r. 
>>
>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
> 
> Ok so you want a confined administrator (a user that can only manage the
> apache-tomcat)
> 
> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
> 
> Once that is done we can look at creating the confined admin.
> 
> Because your current module is a little unwieldy. I cannot make sense of all of it.
> 
> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
> 
> But first things first: deal with the service in the simplest possible way.
> 
>>
>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>
>> ====
>>
>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>
>> Does that give you enough to go by?
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 15:55
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>
>> I am saying that, in my view and with the information i have to my 
>> disposal, there is no to create additional "_u"'s and "_r"'s
>>
>>  How can I link my linux user say jbosslinuxuser to the correct 
>> SELinux user and role to confine my application
>>
>> I would need more infomation about the nature of this user. Is this 
>> user a login user or a system user (can the user log into the system 
>> or is it just a system user to run the application with?)
>>
>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>
>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>
>> I think i see where you might be going with this but I am not sure.
>>
>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>
>> Are the above two assumptions right?
>>
>> what does: grep jbosslinuxuser /etc/passwd return?
>>
>>>
>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 15:13
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>
>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>
>>> Why does that user need to be a login user? Isnt that just a system user?
>>>
>>> Basically now you have a jboss_t type that has at least 3 different
>>> uses: 1. a login shell process, 2. an application process 3. an init 
>>> daemon process
>>>
>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>
>>> But again, if it works for you then it works (dont fix what isnt
>>> broken)
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 14:44
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>> Nice one - thanks I'll give that a shot.
>>>>>
>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>
>>>> However I do not know your requirements, environment, and properties 
>>>> so I can't really suggest alternative approaches, improvements.
>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>
>>>> If it works it works (and with work i mean not just if it runs but 
>>>> also if your security goals are verified to be achieved)
>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 14:22
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick & All,
>>>>>>
>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>
>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>
>>>>>
>>>>> You would do what you alway's do in such situations:
>>>>>
>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>> rules inserted
>>>>>
>>>>> 2. reproduce the issues
>>>>>
>>>>> 3. look again for avc denials that may be related
>>>>>
>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>> rules re-inserted
>>>>>
>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>
>>>>>> =====
>>>>>>
>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>>>> interpreter: Permission denied
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>>> tomcat version running installed via yum to compare parameters 
>>>>>> when they are running etc)
>>>>>>
>>>>>> ========
>>>>>>
>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>> chkconfig: 234 20 80
>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>> export JAVA_HOME
>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>> export PATH
>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>> export CATALINA_HOME
>>>>>> case $1 in
>>>>>> start)
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>> ;;
>>>>>> stop)
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>> ;;
>>>>>> restart)
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>> ;;
>>>>>> esac
>>>>>> exit 0
>>>>>>
>>>>>> ==========
>>>>>>
>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>
>>>>>> ==========
>>>>>>
>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>
>>>>>>
>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>
>>>>>> ===============
>>>>>>
>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>
>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>> Walid
>>>>>> Sent: 03 August 2016 11:30
>>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> Morning Dominick,
>>>>>>
>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Borg-Cardona, Jack
>>>>>> Sent: 03 August 2016 09:25
>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> 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<<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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 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=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
> 
> _______________________________________________
> 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=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/20160816/a8d7c258/attachment-0001.bin 

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

[Dominick Grift]

On 08/16/2016 03:50 PM, Dominick Grift wrote:
> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Quick question : From your comments, am understanding that for a service to run, it always makes sense to run that service as system_u:system_r:service_domain_t
> 
> Atleast system_r:service_domain_t, if this is started by the system.
> 
>>
>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>
> 
> The way confined admins commonly work is:

Here is a RedHat example of how such an adm role could look:

https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/policy/modules/roles/logadm.te

although i would not use the userdom_confined_admin_template because i
would not want to allow privileged logins. Instead i would use the
base_user_template for the role and require the user to log into the
system with the unprivileged staff_r and then change to the privileged
role with sudo manually

> 
> 1. the existing staff_r role is used to allow the admin to login.
> You would create a new selinux user id (for example jboss_tomcat_adm_u),
> then associate the staff_r role and system_r role with that user id.
> 
> 2. then you would create a admin role. This role can be access via sudo
> example: jboss_tomcat_adm_r
> that role is then also associated to the jboss_tomcat_adm_u selinux id,
> so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r
> system_r and jboss_tomcat_r)
> 
> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
> 
> 4. the user can now use sudo to change to his privileged
> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
> 
> 5. now the user has context:
> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
> 
> + is associated with root
> 
> 6. this allows root associated with
> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
> 
> to manage the system service: example: sudo -r jboss_tomcat_adm_r
> service jboss_tomcat start
> 
> Then there is a rule that tells selinux when a process associated with
> role jboss_tomcat_adm_r executes an init script file with type
> jboss_tomcat_initrc_exec_t, then automatically role transition from
> jboss_tomcat_adm_r to system_r
> 
> thus the service ends up with:
> 
> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
> 
> if it is started manually via the init script by the admin and with
> 
> system_u:system_r:jboss_tomcat_t
> 
> if it is started by the system user
> 
> I hope that clears at least some of this up
> 
> 
>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>> -----Original Message-----
>> From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>> Sent: 15 August 2016 16:30
>> To: Dominick Grift; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> Sounds good Dominick - Thanks for the help.
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 16:24
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>
>>> Your assumptions 1 and 2 are correct.
>>>
>>
>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>
>>> I also see your points about using system_u and system_r. 
>>>
>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>
>> Ok so you want a confined administrator (a user that can only manage the
>> apache-tomcat)
>>
>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>
>> Once that is done we can look at creating the confined admin.
>>
>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>
>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>
>> But first things first: deal with the service in the simplest possible way.
>>
>>>
>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>
>>> ====
>>>
>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>
>>> Does that give you enough to go by?
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 15:55
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>
>>> I am saying that, in my view and with the information i have to my 
>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>
>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>> SELinux user and role to confine my application
>>>
>>> I would need more infomation about the nature of this user. Is this 
>>> user a login user or a system user (can the user log into the system 
>>> or is it just a system user to run the application with?)
>>>
>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>
>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>
>>> I think i see where you might be going with this but I am not sure.
>>>
>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>
>>> Are the above two assumptions right?
>>>
>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>
>>>>
>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 15:13
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>
>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>
>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>
>>>> Basically now you have a jboss_t type that has at least 3 different
>>>> uses: 1. a login shell process, 2. an application process 3. an init 
>>>> daemon process
>>>>
>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>
>>>> But again, if it works for you then it works (dont fix what isnt
>>>> broken)
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 14:44
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>
>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>
>>>>> However I do not know your requirements, environment, and properties 
>>>>> so I can't really suggest alternative approaches, improvements.
>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>
>>>>> If it works it works (and with work i mean not just if it runs but 
>>>>> also if your security goals are verified to be achieved)
>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 14:22
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick & All,
>>>>>>>
>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>
>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>
>>>>>>
>>>>>> You would do what you alway's do in such situations:
>>>>>>
>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>> rules inserted
>>>>>>
>>>>>> 2. reproduce the issues
>>>>>>
>>>>>> 3. look again for avc denials that may be related
>>>>>>
>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>> rules re-inserted
>>>>>>
>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: bad
>>>>>>> interpreter: Permission denied
>>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>>>> tomcat version running installed via yum to compare parameters 
>>>>>>> when they are running etc)
>>>>>>>
>>>>>>> ========
>>>>>>>
>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>> chkconfig: 234 20 80
>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>> export JAVA_HOME
>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>> export PATH
>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>> export CATALINA_HOME
>>>>>>> case $1 in
>>>>>>> start)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>> ;;
>>>>>>> stop)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>> ;;
>>>>>>> restart)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>> ;;
>>>>>>> esac
>>>>>>> exit 0
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>
>>>>>>>
>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>
>>>>>>> ===============
>>>>>>>
>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>
>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>> Walid
>>>>>>> Sent: 03 August 2016 11:30
>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> Morning Dominick,
>>>>>>>
>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Borg-Cardona, Jack
>>>>>>> Sent: 03 August 2016 09:25
>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> 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<<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=0x3B6C5F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>>> B
>>>>>>>> 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=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
>>
>> _______________________________________________
>> 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=0x3B6C5F1D2C7B6B02
Dominick Grift

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 644 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160816/64662c25/attachment-0001.bin 

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

[Fakim, Walid]

I'll take a look - thank you.

That gives me some good guidance in where I should be focusing my efforts - much appreciated.



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 16 August 2016 15:23
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/16/2016 03:50 PM, Dominick Grift wrote:
> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Quick question : From your comments, am understanding that for a 
>> service to run, it always makes sense to run that service as 
>> system_u:system_r:service_domain_t
> 
> Atleast system_r:service_domain_t, if this is started by the system.
> 
>>
>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>
> 
> The way confined admins commonly work is:

Here is a RedHat example of how such an adm role could look:

https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/policy/modules/roles/logadm.te

although i would not use the userdom_confined_admin_template because i would not want to allow privileged logins. Instead i would use the base_user_template for the role and require the user to log into the system with the unprivileged staff_r and then change to the privileged role with sudo manually

> 
> 1. the existing staff_r role is used to allow the admin to login.
> You would create a new selinux user id (for example 
> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
> 
> 2. then you would create a admin role. This role can be access via 
> sudo
> example: jboss_tomcat_adm_r
> that role is then also associated to the jboss_tomcat_adm_u selinux 
> id, so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r 
> system_r and jboss_tomcat_r)
> 
> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
> 
> 4. the user can now use sudo to change to his privileged 
> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
> 
> 5. now the user has context:
> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
> 
> + is associated with root
> 
> 6. this allows root associated with
> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
> 
> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
> service jboss_tomcat start
> 
> Then there is a rule that tells selinux when a process associated with 
> role jboss_tomcat_adm_r executes an init script file with type 
> jboss_tomcat_initrc_exec_t, then automatically role transition from 
> jboss_tomcat_adm_r to system_r
> 
> thus the service ends up with:
> 
> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
> 
> if it is started manually via the init script by the admin and with
> 
> system_u:system_r:jboss_tomcat_t
> 
> if it is started by the system user
> 
> I hope that clears at least some of this up
> 
> 
>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>> -----Original Message-----
>> From: refpolicy-bounces at oss.tresys.com 
>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>> Sent: 15 August 2016 16:30
>> To: Dominick Grift; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> Sounds good Dominick - Thanks for the help.
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 16:24
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>
>>> Your assumptions 1 and 2 are correct.
>>>
>>
>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>
>>> I also see your points about using system_u and system_r. 
>>>
>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>
>> Ok so you want a confined administrator (a user that can only manage 
>> the
>> apache-tomcat)
>>
>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>
>> Once that is done we can look at creating the confined admin.
>>
>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>
>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>
>> But first things first: deal with the service in the simplest possible way.
>>
>>>
>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>
>>> ====
>>>
>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>
>>> Does that give you enough to go by?
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 15:55
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>
>>> I am saying that, in my view and with the information i have to my 
>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>
>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>> SELinux user and role to confine my application
>>>
>>> I would need more infomation about the nature of this user. Is this 
>>> user a login user or a system user (can the user log into the system 
>>> or is it just a system user to run the application with?)
>>>
>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>
>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>
>>> I think i see where you might be going with this but I am not sure.
>>>
>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>
>>> Are the above two assumptions right?
>>>
>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>
>>>>
>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 15:13
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>
>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>
>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>
>>>> Basically now you have a jboss_t type that has at least 3 different
>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>> init daemon process
>>>>
>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>
>>>> But again, if it works for you then it works (dont fix what isnt
>>>> broken)
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 14:44
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>
>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>
>>>>> However I do not know your requirements, environment, and 
>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>
>>>>> If it works it works (and with work i mean not just if it runs but 
>>>>> also if your security goals are verified to be achieved)
>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 14:22
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick & All,
>>>>>>>
>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>
>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>
>>>>>>
>>>>>> You would do what you alway's do in such situations:
>>>>>>
>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>> rules inserted
>>>>>>
>>>>>> 2. reproduce the issues
>>>>>>
>>>>>> 3. look again for avc denials that may be related
>>>>>>
>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>> rules re-inserted
>>>>>>
>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>> bad
>>>>>>> interpreter: Permission denied
>>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>>>> tomcat version running installed via yum to compare parameters 
>>>>>>> when they are running etc)
>>>>>>>
>>>>>>> ========
>>>>>>>
>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>> chkconfig: 234 20 80
>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>> export JAVA_HOME
>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>> export PATH
>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>> export CATALINA_HOME
>>>>>>> case $1 in
>>>>>>> start)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>> ;;
>>>>>>> stop)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>> ;;
>>>>>>> restart)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>> ;;
>>>>>>> esac
>>>>>>> exit 0
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>
>>>>>>>
>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>
>>>>>>> ===============
>>>>>>>
>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>
>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>> Walid
>>>>>>> Sent: 03 August 2016 11:30
>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> Morning Dominick,
>>>>>>>
>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Borg-Cardona, Jack
>>>>>>> Sent: 03 August 2016 09:25
>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> 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<<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=0x3B6C
>>>>>>>>>>>>> 5F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B6
>>>>>> 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=0x3B6C5F1D2C7B
>>>>> 6B
>>>>> 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
>>>> B0
>>>> 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
>>> 02
>>> 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
>>
>> _______________________________________________
>> 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=0x3B6C5F1D2C7B6B02
Dominick Grift

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

[Fakim, Walid]

Hi Dominick,

Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?

e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.


Thanks.

Best Regards,

Walid Fakim

-----Original Message-----
From: Fakim, Walid 
Sent: 16 August 2016 15:32
To: 'Dominick Grift'; refpolicy at oss.tresys.com
Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

I'll take a look - thank you.

That gives me some good guidance in where I should be focusing my efforts - much appreciated.



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com]
Sent: 16 August 2016 15:23
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/16/2016 03:50 PM, Dominick Grift wrote:
> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Quick question : From your comments, am understanding that for a 
>> service to run, it always makes sense to run that service as 
>> system_u:system_r:service_domain_t
> 
> Atleast system_r:service_domain_t, if this is started by the system.
> 
>>
>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>
> 
> The way confined admins commonly work is:

Here is a RedHat example of how such an adm role could look:

https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/policy/modules/roles/logadm.te

although i would not use the userdom_confined_admin_template because i would not want to allow privileged logins. Instead i would use the base_user_template for the role and require the user to log into the system with the unprivileged staff_r and then change to the privileged role with sudo manually

> 
> 1. the existing staff_r role is used to allow the admin to login.
> You would create a new selinux user id (for example 
> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
> 
> 2. then you would create a admin role. This role can be access via 
> sudo
> example: jboss_tomcat_adm_r
> that role is then also associated to the jboss_tomcat_adm_u selinux 
> id, so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r 
> system_r and jboss_tomcat_r)
> 
> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
> 
> 4. the user can now use sudo to change to his privileged 
> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
> 
> 5. now the user has context:
> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
> 
> + is associated with root
> 
> 6. this allows root associated with
> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
> 
> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
> service jboss_tomcat start
> 
> Then there is a rule that tells selinux when a process associated with 
> role jboss_tomcat_adm_r executes an init script file with type 
> jboss_tomcat_initrc_exec_t, then automatically role transition from 
> jboss_tomcat_adm_r to system_r
> 
> thus the service ends up with:
> 
> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
> 
> if it is started manually via the init script by the admin and with
> 
> system_u:system_r:jboss_tomcat_t
> 
> if it is started by the system user
> 
> I hope that clears at least some of this up
> 
> 
>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>> -----Original Message-----
>> From: refpolicy-bounces at oss.tresys.com 
>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>> Sent: 15 August 2016 16:30
>> To: Dominick Grift; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> Sounds good Dominick - Thanks for the help.
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 16:24
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>
>>> Your assumptions 1 and 2 are correct.
>>>
>>
>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>
>>> I also see your points about using system_u and system_r. 
>>>
>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>
>> Ok so you want a confined administrator (a user that can only manage 
>> the
>> apache-tomcat)
>>
>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>
>> Once that is done we can look at creating the confined admin.
>>
>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>
>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>
>> But first things first: deal with the service in the simplest possible way.
>>
>>>
>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>
>>> ====
>>>
>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>
>>> Does that give you enough to go by?
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 15:55
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>
>>> I am saying that, in my view and with the information i have to my 
>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>
>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>> SELinux user and role to confine my application
>>>
>>> I would need more infomation about the nature of this user. Is this 
>>> user a login user or a system user (can the user log into the system 
>>> or is it just a system user to run the application with?)
>>>
>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>
>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>
>>> I think i see where you might be going with this but I am not sure.
>>>
>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>
>>> Are the above two assumptions right?
>>>
>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>
>>>>
>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 15:13
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>
>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>
>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>
>>>> Basically now you have a jboss_t type that has at least 3 different
>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>> init daemon process
>>>>
>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>
>>>> But again, if it works for you then it works (dont fix what isnt
>>>> broken)
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 14:44
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>
>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>
>>>>> However I do not know your requirements, environment, and 
>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>
>>>>> If it works it works (and with work i mean not just if it runs but 
>>>>> also if your security goals are verified to be achieved)
>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 14:22
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick & All,
>>>>>>>
>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>
>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>
>>>>>>
>>>>>> You would do what you alway's do in such situations:
>>>>>>
>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>> rules inserted
>>>>>>
>>>>>> 2. reproduce the issues
>>>>>>
>>>>>> 3. look again for avc denials that may be related
>>>>>>
>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>> rules re-inserted
>>>>>>
>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>> bad
>>>>>>> interpreter: Permission denied
>>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>>>> tomcat version running installed via yum to compare parameters 
>>>>>>> when they are running etc)
>>>>>>>
>>>>>>> ========
>>>>>>>
>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>> chkconfig: 234 20 80
>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>> export JAVA_HOME
>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>> export PATH
>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>> export CATALINA_HOME
>>>>>>> case $1 in
>>>>>>> start)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>> ;;
>>>>>>> stop)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>> ;;
>>>>>>> restart)
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>> ;;
>>>>>>> esac
>>>>>>> exit 0
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>
>>>>>>>
>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>
>>>>>>> ===============
>>>>>>>
>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>
>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>> Walid
>>>>>>> Sent: 03 August 2016 11:30
>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> Morning Dominick,
>>>>>>>
>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Borg-Cardona, Jack
>>>>>>> Sent: 03 August 2016 09:25
>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> 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<<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=0x3B6C
>>>>>>>>>>>>> 5F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B6
>>>>>> 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=0x3B6C5F1D2C7B
>>>>> 6B
>>>>> 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
>>>> B0
>>>> 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
>>> 02
>>> 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
>>
>> _______________________________________________
>> 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=0x3B6C5F1D2C7B6B02
Dominick Grift

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

[Dominick Grift]

On 08/19/2016 02:02 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
> 
> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.

I do not think that template was meant for that, but if it works if works.

I would, probably, just create an init_daemon_domain() for my jboss
application service instead using that template.

> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> -----Original Message-----
> From: Fakim, Walid 
> Sent: 16 August 2016 15:32
> To: 'Dominick Grift'; refpolicy at oss.tresys.com
> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> I'll take a look - thank you.
> 
> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 16 August 2016 15:23
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> Quick question : From your comments, am understanding that for a 
>>> service to run, it always makes sense to run that service as 
>>> system_u:system_r:service_domain_t
>>
>> Atleast system_r:service_domain_t, if this is started by the system.
>>
>>>
>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>
>>
>> The way confined admins commonly work is:
> 
> Here is a RedHat example of how such an adm role could look:
> 
> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/policy/modules/roles/logadm.te
> 
> although i would not use the userdom_confined_admin_template because i would not want to allow privileged logins. Instead i would use the base_user_template for the role and require the user to log into the system with the unprivileged staff_r and then change to the privileged role with sudo manually
> 
>>
>> 1. the existing staff_r role is used to allow the admin to login.
>> You would create a new selinux user id (for example 
>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>
>> 2. then you would create a admin role. This role can be access via 
>> sudo
>> example: jboss_tomcat_adm_r
>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>> id, so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r 
>> system_r and jboss_tomcat_r)
>>
>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>
>> 4. the user can now use sudo to change to his privileged 
>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>
>> 5. now the user has context:
>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>
>> + is associated with root
>>
>> 6. this allows root associated with
>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>
>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>> service jboss_tomcat start
>>
>> Then there is a rule that tells selinux when a process associated with 
>> role jboss_tomcat_adm_r executes an init script file with type 
>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>> jboss_tomcat_adm_r to system_r
>>
>> thus the service ends up with:
>>
>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>
>> if it is started manually via the init script by the admin and with
>>
>> system_u:system_r:jboss_tomcat_t
>>
>> if it is started by the system user
>>
>> I hope that clears at least some of this up
>>
>>
>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>> -----Original Message-----
>>> From: refpolicy-bounces at oss.tresys.com 
>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>> Sent: 15 August 2016 16:30
>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> Sounds good Dominick - Thanks for the help.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 16:24
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>
>>>> Your assumptions 1 and 2 are correct.
>>>>
>>>
>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>
>>>> I also see your points about using system_u and system_r. 
>>>>
>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>
>>> Ok so you want a confined administrator (a user that can only manage 
>>> the
>>> apache-tomcat)
>>>
>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>
>>> Once that is done we can look at creating the confined admin.
>>>
>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>
>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>
>>> But first things first: deal with the service in the simplest possible way.
>>>
>>>>
>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>
>>>> ====
>>>>
>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>
>>>> Does that give you enough to go by?
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 15:55
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>
>>>> I am saying that, in my view and with the information i have to my 
>>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>>
>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>> SELinux user and role to confine my application
>>>>
>>>> I would need more infomation about the nature of this user. Is this 
>>>> user a login user or a system user (can the user log into the system 
>>>> or is it just a system user to run the application with?)
>>>>
>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>
>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>
>>>> I think i see where you might be going with this but I am not sure.
>>>>
>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>
>>>> Are the above two assumptions right?
>>>>
>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>
>>>>>
>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 15:13
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>
>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>
>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>
>>>>> Basically now you have a jboss_t type that has at least 3 different
>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>> init daemon process
>>>>>
>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>
>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>> broken)
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 14:44
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>
>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>
>>>>>> However I do not know your requirements, environment, and 
>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>>
>>>>>> If it works it works (and with work i mean not just if it runs but 
>>>>>> also if your security goals are verified to be achieved)
>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 14:22
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>> Hi Dominick & All,
>>>>>>>>
>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>
>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>
>>>>>>>
>>>>>>> You would do what you alway's do in such situations:
>>>>>>>
>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>> rules inserted
>>>>>>>
>>>>>>> 2. reproduce the issues
>>>>>>>
>>>>>>> 3. look again for avc denials that may be related
>>>>>>>
>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>> rules re-inserted
>>>>>>>
>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>> bad
>>>>>>>> interpreter: Permission denied
>>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>>>>> tomcat version running installed via yum to compare parameters 
>>>>>>>> when they are running etc)
>>>>>>>>
>>>>>>>> ========
>>>>>>>>
>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>>> chkconfig: 234 20 80
>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>> export JAVA_HOME
>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>> export PATH
>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>> export CATALINA_HOME
>>>>>>>> case $1 in
>>>>>>>> start)
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>> ;;
>>>>>>>> stop)
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>> ;;
>>>>>>>> restart)
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>> ;;
>>>>>>>> esac
>>>>>>>> exit 0
>>>>>>>>
>>>>>>>> ==========
>>>>>>>>
>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>
>>>>>>>> ==========
>>>>>>>>
>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>
>>>>>>>>
>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>
>>>>>>>> ===============
>>>>>>>>
>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>
>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>> Walid
>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> Morning Dominick,
>>>>>>>>
>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> 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<<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=0x3B6C
>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7B
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B6
>>>>>>> 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=0x3B6C5F1D2C7B
>>>>>> 6B
>>>>>> 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
>>>>> B0
>>>>> 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
>>>> 02
>>>> 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
>>>
>>> _______________________________________________
>>> 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=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/20160819/de35bd40/attachment-0001.bin 

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

[Fakim, Walid]

The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 19 August 2016 14:14
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/19/2016 02:02 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
> 
> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.

I do not think that template was meant for that, but if it works if works.

I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.

> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> -----Original Message-----
> From: Fakim, Walid
> Sent: 16 August 2016 15:32
> To: 'Dominick Grift'; refpolicy at oss.tresys.com
> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> I'll take a look - thank you.
> 
> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 16 August 2016 15:23
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> Quick question : From your comments, am understanding that for a 
>>> service to run, it always makes sense to run that service as 
>>> system_u:system_r:service_domain_t
>>
>> Atleast system_r:service_domain_t, if this is started by the system.
>>
>>>
>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>
>>
>> The way confined admins commonly work is:
> 
> Here is a RedHat example of how such an adm role could look:
> 
> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/pol
> icy/modules/roles/logadm.te
> 
> although i would not use the userdom_confined_admin_template because i 
> would not want to allow privileged logins. Instead i would use the 
> base_user_template for the role and require the user to log into the 
> system with the unprivileged staff_r and then change to the privileged 
> role with sudo manually
> 
>>
>> 1. the existing staff_r role is used to allow the admin to login.
>> You would create a new selinux user id (for example 
>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>
>> 2. then you would create a admin role. This role can be access via 
>> sudo
>> example: jboss_tomcat_adm_r
>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>> id, so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r 
>> system_r and jboss_tomcat_r)
>>
>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>
>> 4. the user can now use sudo to change to his privileged 
>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>
>> 5. now the user has context:
>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>
>> + is associated with root
>>
>> 6. this allows root associated with
>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>
>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>> service jboss_tomcat start
>>
>> Then there is a rule that tells selinux when a process associated 
>> with role jboss_tomcat_adm_r executes an init script file with type 
>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>> jboss_tomcat_adm_r to system_r
>>
>> thus the service ends up with:
>>
>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>
>> if it is started manually via the init script by the admin and with
>>
>> system_u:system_r:jboss_tomcat_t
>>
>> if it is started by the system user
>>
>> I hope that clears at least some of this up
>>
>>
>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>> -----Original Message-----
>>> From: refpolicy-bounces at oss.tresys.com 
>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>> Sent: 15 August 2016 16:30
>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> Sounds good Dominick - Thanks for the help.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 16:24
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>
>>>> Your assumptions 1 and 2 are correct.
>>>>
>>>
>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>
>>>> I also see your points about using system_u and system_r. 
>>>>
>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>
>>> Ok so you want a confined administrator (a user that can only manage 
>>> the
>>> apache-tomcat)
>>>
>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>
>>> Once that is done we can look at creating the confined admin.
>>>
>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>
>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>
>>> But first things first: deal with the service in the simplest possible way.
>>>
>>>>
>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>
>>>> ====
>>>>
>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>
>>>> Does that give you enough to go by?
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 15:55
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>
>>>> I am saying that, in my view and with the information i have to my 
>>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>>
>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>> SELinux user and role to confine my application
>>>>
>>>> I would need more infomation about the nature of this user. Is this 
>>>> user a login user or a system user (can the user log into the 
>>>> system or is it just a system user to run the application with?)
>>>>
>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>
>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>
>>>> I think i see where you might be going with this but I am not sure.
>>>>
>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>
>>>> Are the above two assumptions right?
>>>>
>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>
>>>>>
>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 15:13
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>
>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>
>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>
>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>> different
>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>> init daemon process
>>>>>
>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>
>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>> broken)
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 14:44
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>
>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>
>>>>>> However I do not know your requirements, environment, and 
>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>>
>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>> but also if your security goals are verified to be achieved)
>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 14:22
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>> Hi Dominick & All,
>>>>>>>>
>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>
>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>
>>>>>>>
>>>>>>> You would do what you alway's do in such situations:
>>>>>>>
>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>> rules inserted
>>>>>>>
>>>>>>> 2. reproduce the issues
>>>>>>>
>>>>>>> 3. look again for avc denials that may be related
>>>>>>>
>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>> rules re-inserted
>>>>>>>
>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>> bad
>>>>>>>> interpreter: Permission denied
>>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>> parameters when they are running etc)
>>>>>>>>
>>>>>>>> ========
>>>>>>>>
>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>>> chkconfig: 234 20 80
>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>> export JAVA_HOME
>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>> export PATH
>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>> export CATALINA_HOME
>>>>>>>> case $1 in
>>>>>>>> start)
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>> ;;
>>>>>>>> stop)
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>> ;;
>>>>>>>> restart)
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>> ;;
>>>>>>>> esac
>>>>>>>> exit 0
>>>>>>>>
>>>>>>>> ==========
>>>>>>>>
>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>
>>>>>>>> ==========
>>>>>>>>
>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>
>>>>>>>>
>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>
>>>>>>>> ===============
>>>>>>>>
>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>
>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>> Walid
>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> Morning Dominick,
>>>>>>>>
>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> 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<<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=0x3B6
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>> 5
>>>>>>>>>>>>> F1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F
>>>>>>>>>>>> 1D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B6
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 6B
>>>>>> 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=0x3B6C5F1D2C7B
>>>>> 6
>>>>> B0
>>>>> 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
>>>> 02
>>>> 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
>>>
>>> _______________________________________________
>>> 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=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

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

[Dominick Grift]

On 08/19/2016 03:54 PM, Fakim, Walid wrote:
> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
> 
> 

The transition happens on the shell script, and the domain associated
with the shell script process should then be allowed to execute java

init_t (init) -> initrc_t (init script) -> myapp_t (java app shell script)

java_exec(myapp_t)

> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 19 August 2016 14:14
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>
>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
> 
> I do not think that template was meant for that, but if it works if works.
> 
> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
> 
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>> -----Original Message-----
>> From: Fakim, Walid
>> Sent: 16 August 2016 15:32
>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> I'll take a look - thank you.
>>
>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 16 August 2016 15:23
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Quick question : From your comments, am understanding that for a 
>>>> service to run, it always makes sense to run that service as 
>>>> system_u:system_r:service_domain_t
>>>
>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>
>>>>
>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>
>>>
>>> The way confined admins commonly work is:
>>
>> Here is a RedHat example of how such an adm role could look:
>>
>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/pol
>> icy/modules/roles/logadm.te
>>
>> although i would not use the userdom_confined_admin_template because i 
>> would not want to allow privileged logins. Instead i would use the 
>> base_user_template for the role and require the user to log into the 
>> system with the unprivileged staff_r and then change to the privileged 
>> role with sudo manually
>>
>>>
>>> 1. the existing staff_r role is used to allow the admin to login.
>>> You would create a new selinux user id (for example 
>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>
>>> 2. then you would create a admin role. This role can be access via 
>>> sudo
>>> example: jboss_tomcat_adm_r
>>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>>> id, so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r 
>>> system_r and jboss_tomcat_r)
>>>
>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>
>>> 4. the user can now use sudo to change to his privileged 
>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>
>>> 5. now the user has context:
>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>
>>> + is associated with root
>>>
>>> 6. this allows root associated with
>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>
>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>> service jboss_tomcat start
>>>
>>> Then there is a rule that tells selinux when a process associated 
>>> with role jboss_tomcat_adm_r executes an init script file with type 
>>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>>> jboss_tomcat_adm_r to system_r
>>>
>>> thus the service ends up with:
>>>
>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>
>>> if it is started manually via the init script by the admin and with
>>>
>>> system_u:system_r:jboss_tomcat_t
>>>
>>> if it is started by the system user
>>>
>>> I hope that clears at least some of this up
>>>
>>>
>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>> -----Original Message-----
>>>> From: refpolicy-bounces at oss.tresys.com 
>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>>> Sent: 15 August 2016 16:30
>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> Sounds good Dominick - Thanks for the help.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 16:24
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>>
>>>>> Your assumptions 1 and 2 are correct.
>>>>>
>>>>
>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>
>>>>> I also see your points about using system_u and system_r. 
>>>>>
>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>
>>>> Ok so you want a confined administrator (a user that can only manage 
>>>> the
>>>> apache-tomcat)
>>>>
>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>
>>>> Once that is done we can look at creating the confined admin.
>>>>
>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>
>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>
>>>> But first things first: deal with the service in the simplest possible way.
>>>>
>>>>>
>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>
>>>>> ====
>>>>>
>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>
>>>>> Does that give you enough to go by?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 15:55
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>
>>>>> I am saying that, in my view and with the information i have to my 
>>>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>
>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>> SELinux user and role to confine my application
>>>>>
>>>>> I would need more infomation about the nature of this user. Is this 
>>>>> user a login user or a system user (can the user log into the 
>>>>> system or is it just a system user to run the application with?)
>>>>>
>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>
>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>
>>>>> I think i see where you might be going with this but I am not sure.
>>>>>
>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>
>>>>> Are the above two assumptions right?
>>>>>
>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>
>>>>>>
>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 15:13
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>
>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>
>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>
>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>> different
>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>> init daemon process
>>>>>>
>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>
>>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>>> broken)
>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 14:44
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>
>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>
>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>
>>>>>>> However I do not know your requirements, environment, and 
>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>>>
>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>> Hi Dominick & All,
>>>>>>>>>
>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>
>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>
>>>>>>>>
>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>
>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>> rules inserted
>>>>>>>>
>>>>>>>> 2. reproduce the issues
>>>>>>>>
>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>
>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>> rules re-inserted
>>>>>>>>
>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>
>>>>>>>>> =====
>>>>>>>>>
>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>> bad
>>>>>>>>> interpreter: Permission denied
>>>>>>>>>
>>>>>>>>> =====
>>>>>>>>>
>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>> parameters when they are running etc)
>>>>>>>>>
>>>>>>>>> ========
>>>>>>>>>
>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>> export JAVA_HOME
>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>> export PATH
>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>> export CATALINA_HOME
>>>>>>>>> case $1 in
>>>>>>>>> start)
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>> ;;
>>>>>>>>> stop)
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>> ;;
>>>>>>>>> restart)
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>> ;;
>>>>>>>>> esac
>>>>>>>>> exit 0
>>>>>>>>>
>>>>>>>>> ==========
>>>>>>>>>
>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>
>>>>>>>>> ==========
>>>>>>>>>
>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>
>>>>>>>>> ===============
>>>>>>>>>
>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>
>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>> Walid
>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> Morning Dominick,
>>>>>>>>>
>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> 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<<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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B6
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 6B
>>>>>>> 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=0x3B6C5F1D2C7B
>>>>>> 6
>>>>>> B0
>>>>>> 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
>>>>> 02
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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=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/20160819/4656b20a/attachment-0001.bin 

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

[Fakim, Walid]

Ok - what would be a use case for the java_role_template?



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 19 August 2016 16:53
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/19/2016 03:54 PM, Fakim, Walid wrote:
> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
> 
> 

The transition happens on the shell script, and the domain associated with the shell script process should then be allowed to execute java

init_t (init) -> initrc_t (init script) -> myapp_t (java app shell script)

java_exec(myapp_t)

> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 19 August 2016 14:14
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>
>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
> 
> I do not think that template was meant for that, but if it works if works.
> 
> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
> 
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>> -----Original Message-----
>> From: Fakim, Walid
>> Sent: 16 August 2016 15:32
>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> I'll take a look - thank you.
>>
>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 16 August 2016 15:23
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Quick question : From your comments, am understanding that for a 
>>>> service to run, it always makes sense to run that service as 
>>>> system_u:system_r:service_domain_t
>>>
>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>
>>>>
>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>
>>>
>>> The way confined admins commonly work is:
>>
>> Here is a RedHat example of how such an adm role could look:
>>
>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/po
>> l
>> icy/modules/roles/logadm.te
>>
>> although i would not use the userdom_confined_admin_template because 
>> i would not want to allow privileged logins. Instead i would use the 
>> base_user_template for the role and require the user to log into the 
>> system with the unprivileged staff_r and then change to the 
>> privileged role with sudo manually
>>
>>>
>>> 1. the existing staff_r role is used to allow the admin to login.
>>> You would create a new selinux user id (for example 
>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>
>>> 2. then you would create a admin role. This role can be access via 
>>> sudo
>>> example: jboss_tomcat_adm_r
>>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>>> id, so theres now 3 roles associated with jboss_tomcat_adm_u 
>>> (staff_r system_r and jboss_tomcat_r)
>>>
>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>
>>> 4. the user can now use sudo to change to his privileged 
>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>
>>> 5. now the user has context:
>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>
>>> + is associated with root
>>>
>>> 6. this allows root associated with
>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>
>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>> service jboss_tomcat start
>>>
>>> Then there is a rule that tells selinux when a process associated 
>>> with role jboss_tomcat_adm_r executes an init script file with type 
>>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>>> jboss_tomcat_adm_r to system_r
>>>
>>> thus the service ends up with:
>>>
>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>
>>> if it is started manually via the init script by the admin and with
>>>
>>> system_u:system_r:jboss_tomcat_t
>>>
>>> if it is started by the system user
>>>
>>> I hope that clears at least some of this up
>>>
>>>
>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>> -----Original Message-----
>>>> From: refpolicy-bounces at oss.tresys.com 
>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>>> Sent: 15 August 2016 16:30
>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> Sounds good Dominick - Thanks for the help.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 16:24
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>>
>>>>> Your assumptions 1 and 2 are correct.
>>>>>
>>>>
>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>
>>>>> I also see your points about using system_u and system_r. 
>>>>>
>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>
>>>> Ok so you want a confined administrator (a user that can only 
>>>> manage the
>>>> apache-tomcat)
>>>>
>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>
>>>> Once that is done we can look at creating the confined admin.
>>>>
>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>
>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>
>>>> But first things first: deal with the service in the simplest possible way.
>>>>
>>>>>
>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>
>>>>> ====
>>>>>
>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>
>>>>> Does that give you enough to go by?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 15:55
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>
>>>>> I am saying that, in my view and with the information i have to my 
>>>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>
>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>> SELinux user and role to confine my application
>>>>>
>>>>> I would need more infomation about the nature of this user. Is 
>>>>> this user a login user or a system user (can the user log into the 
>>>>> system or is it just a system user to run the application with?)
>>>>>
>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>
>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>
>>>>> I think i see where you might be going with this but I am not sure.
>>>>>
>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>
>>>>> Are the above two assumptions right?
>>>>>
>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>
>>>>>>
>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 15:13
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>
>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>
>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>
>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>> different
>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>> init daemon process
>>>>>>
>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>
>>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>>> broken)
>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 14:44
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>
>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>
>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>
>>>>>>> However I do not know your requirements, environment, and 
>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>>>
>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>> Hi Dominick & All,
>>>>>>>>>
>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>
>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>
>>>>>>>>
>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>
>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>> rules inserted
>>>>>>>>
>>>>>>>> 2. reproduce the issues
>>>>>>>>
>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>
>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>> rules re-inserted
>>>>>>>>
>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>
>>>>>>>>> =====
>>>>>>>>>
>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>> bad
>>>>>>>>> interpreter: Permission denied
>>>>>>>>>
>>>>>>>>> =====
>>>>>>>>>
>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>> parameters when they are running etc)
>>>>>>>>>
>>>>>>>>> ========
>>>>>>>>>
>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>> export JAVA_HOME
>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>> export PATH
>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>> export CATALINA_HOME
>>>>>>>>> case $1 in
>>>>>>>>> start)
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>> ;;
>>>>>>>>> stop)
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>> ;;
>>>>>>>>> restart)
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>> ;;
>>>>>>>>> esac
>>>>>>>>> exit 0
>>>>>>>>>
>>>>>>>>> ==========
>>>>>>>>>
>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>
>>>>>>>>> ==========
>>>>>>>>>
>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>
>>>>>>>>> ===============
>>>>>>>>>
>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>
>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>> Walid
>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> Morning Dominick,
>>>>>>>>>
>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> 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<<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=0x3B
>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>> 5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B6
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 6B
>>>>>>> 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=0x3B6C5F1D2C7
>>>>>> B
>>>>>> 6
>>>>>> B0
>>>>>> 2
>>>>>> Dominick Grift
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>> 6B02
>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B
>>>>> 6
>>>>> B
>>>>> 02
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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=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

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

[Dominick Grift]

On 08/19/2016 07:21 PM, Fakim, Walid wrote:
> Ok - what would be a use case for the java_role_template?

Not quite sure ... but role_templates are generally for user
applications and not for system services

> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 19 August 2016 16:53
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>
>>
> 
> The transition happens on the shell script, and the domain associated with the shell script process should then be allowed to execute java
> 
> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell script)
> 
> java_exec(myapp_t)
> 
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 14:14
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>
>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>
>> I do not think that template was meant for that, but if it works if works.
>>
>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>> -----Original Message-----
>>> From: Fakim, Walid
>>> Sent: 16 August 2016 15:32
>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> I'll take a look - thank you.
>>>
>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 16 August 2016 15:23
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>> Hi Dominick,
>>>>>
>>>>> Quick question : From your comments, am understanding that for a 
>>>>> service to run, it always makes sense to run that service as 
>>>>> system_u:system_r:service_domain_t
>>>>
>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>
>>>>>
>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>
>>>>
>>>> The way confined admins commonly work is:
>>>
>>> Here is a RedHat example of how such an adm role could look:
>>>
>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/po
>>> l
>>> icy/modules/roles/logadm.te
>>>
>>> although i would not use the userdom_confined_admin_template because 
>>> i would not want to allow privileged logins. Instead i would use the 
>>> base_user_template for the role and require the user to log into the 
>>> system with the unprivileged staff_r and then change to the 
>>> privileged role with sudo manually
>>>
>>>>
>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>> You would create a new selinux user id (for example 
>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>
>>>> 2. then you would create a admin role. This role can be access via 
>>>> sudo
>>>> example: jboss_tomcat_adm_r
>>>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>>>> id, so theres now 3 roles associated with jboss_tomcat_adm_u 
>>>> (staff_r system_r and jboss_tomcat_r)
>>>>
>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>
>>>> 4. the user can now use sudo to change to his privileged 
>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>
>>>> 5. now the user has context:
>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>
>>>> + is associated with root
>>>>
>>>> 6. this allows root associated with
>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>
>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>> service jboss_tomcat start
>>>>
>>>> Then there is a rule that tells selinux when a process associated 
>>>> with role jboss_tomcat_adm_r executes an init script file with type 
>>>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>>>> jboss_tomcat_adm_r to system_r
>>>>
>>>> thus the service ends up with:
>>>>
>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>
>>>> if it is started manually via the init script by the admin and with
>>>>
>>>> system_u:system_r:jboss_tomcat_t
>>>>
>>>> if it is started by the system user
>>>>
>>>> I hope that clears at least some of this up
>>>>
>>>>
>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>> -----Original Message-----
>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
>>>>> Sent: 15 August 2016 16:30
>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> Sounds good Dominick - Thanks for the help.
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 16:24
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>>>
>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>
>>>>>
>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>
>>>>>> I also see your points about using system_u and system_r. 
>>>>>>
>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>
>>>>> Ok so you want a confined administrator (a user that can only 
>>>>> manage the
>>>>> apache-tomcat)
>>>>>
>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>
>>>>> Once that is done we can look at creating the confined admin.
>>>>>
>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>
>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>
>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>
>>>>>>
>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>
>>>>>> ====
>>>>>>
>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>
>>>>>> Does that give you enough to go by?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 15:55
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>
>>>>>> I am saying that, in my view and with the information i have to my 
>>>>>> disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>
>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>> SELinux user and role to confine my application
>>>>>>
>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>> this user a login user or a system user (can the user log into the 
>>>>>> system or is it just a system user to run the application with?)
>>>>>>
>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>
>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>
>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>
>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>
>>>>>> Are the above two assumptions right?
>>>>>>
>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>
>>>>>>>
>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 15:13
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>
>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>
>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>
>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>> different
>>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>>> init daemon process
>>>>>>>
>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>
>>>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>>>> broken)
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>
>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>
>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>>>>>
>>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>
>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>
>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>
>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>> rules inserted
>>>>>>>>>
>>>>>>>>> 2. reproduce the issues
>>>>>>>>>
>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>
>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>> rules re-inserted
>>>>>>>>>
>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>
>>>>>>>>>> =====
>>>>>>>>>>
>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>> bad
>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>
>>>>>>>>>> =====
>>>>>>>>>>
>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>>> parameters when they are running etc)
>>>>>>>>>>
>>>>>>>>>> ========
>>>>>>>>>>
>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>> export JAVA_HOME
>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>> export PATH
>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>> case $1 in
>>>>>>>>>> start)
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>> ;;
>>>>>>>>>> stop)
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>> ;;
>>>>>>>>>> restart)
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>> ;;
>>>>>>>>>> esac
>>>>>>>>>> exit 0
>>>>>>>>>>
>>>>>>>>>> ==========
>>>>>>>>>>
>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>
>>>>>>>>>> ==========
>>>>>>>>>>
>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>
>>>>>>>>>> ===============
>>>>>>>>>>
>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>
>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>>> Walid
>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> Morning Dominick,
>>>>>>>>>>
>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> 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<<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=0x3B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7B
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B6
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6B
>>>>>>>> 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=0x3B6C5F1D2C7
>>>>>>> B
>>>>>>> 6
>>>>>>> B0
>>>>>>> 2
>>>>>>> Dominick Grift
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>> 6B02
>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B
>>>>>> 6
>>>>>> B
>>>>>> 02
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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=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/20160819/2303264f/attachment-0001.bin 

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

[Fakim, Walid]

Hi Dominick,

Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 19 August 2016 18:23
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/19/2016 07:21 PM, Fakim, Walid wrote:
> Ok - what would be a use case for the java_role_template?

Not quite sure ... but role_templates are generally for user applications and not for system services

> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 19 August 2016 16:53
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>
>>
> 
> The transition happens on the shell script, and the domain associated 
> with the shell script process should then be allowed to execute java
> 
> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell 
> script)
> 
> java_exec(myapp_t)
> 
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 14:14
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>
>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>
>> I do not think that template was meant for that, but if it works if works.
>>
>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>> -----Original Message-----
>>> From: Fakim, Walid
>>> Sent: 16 August 2016 15:32
>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> I'll take a look - thank you.
>>>
>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 16 August 2016 15:23
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>> Hi Dominick,
>>>>>
>>>>> Quick question : From your comments, am understanding that for a 
>>>>> service to run, it always makes sense to run that service as 
>>>>> system_u:system_r:service_domain_t
>>>>
>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>
>>>>>
>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>
>>>>
>>>> The way confined admins commonly work is:
>>>
>>> Here is a RedHat example of how such an adm role could look:
>>>
>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/p
>>> o
>>> l
>>> icy/modules/roles/logadm.te
>>>
>>> although i would not use the userdom_confined_admin_template because 
>>> i would not want to allow privileged logins. Instead i would use the 
>>> base_user_template for the role and require the user to log into the 
>>> system with the unprivileged staff_r and then change to the 
>>> privileged role with sudo manually
>>>
>>>>
>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>> You would create a new selinux user id (for example 
>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>
>>>> 2. then you would create a admin role. This role can be access via 
>>>> sudo
>>>> example: jboss_tomcat_adm_r
>>>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>>>> id, so theres now 3 roles associated with jboss_tomcat_adm_u 
>>>> (staff_r system_r and jboss_tomcat_r)
>>>>
>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>
>>>> 4. the user can now use sudo to change to his privileged 
>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>
>>>> 5. now the user has context:
>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>
>>>> + is associated with root
>>>>
>>>> 6. this allows root associated with 
>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>
>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>> service jboss_tomcat start
>>>>
>>>> Then there is a rule that tells selinux when a process associated 
>>>> with role jboss_tomcat_adm_r executes an init script file with type 
>>>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>>>> jboss_tomcat_adm_r to system_r
>>>>
>>>> thus the service ends up with:
>>>>
>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>
>>>> if it is started manually via the init script by the admin and with
>>>>
>>>> system_u:system_r:jboss_tomcat_t
>>>>
>>>> if it is started by the system user
>>>>
>>>> I hope that clears at least some of this up
>>>>
>>>>
>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>> -----Original Message-----
>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>> Walid
>>>>> Sent: 15 August 2016 16:30
>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> Sounds good Dominick - Thanks for the help.
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 16:24
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>>>
>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>
>>>>>
>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>
>>>>>> I also see your points about using system_u and system_r. 
>>>>>>
>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>
>>>>> Ok so you want a confined administrator (a user that can only 
>>>>> manage the
>>>>> apache-tomcat)
>>>>>
>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>
>>>>> Once that is done we can look at creating the confined admin.
>>>>>
>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>
>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>
>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>
>>>>>>
>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>
>>>>>> ====
>>>>>>
>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>
>>>>>> Does that give you enough to go by?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 15:55
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>
>>>>>> I am saying that, in my view and with the information i have to 
>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>
>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>> SELinux user and role to confine my application
>>>>>>
>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>> this user a login user or a system user (can the user log into 
>>>>>> the system or is it just a system user to run the application 
>>>>>> with?)
>>>>>>
>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>
>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>
>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>
>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>
>>>>>> Are the above two assumptions right?
>>>>>>
>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>
>>>>>>>
>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 15:13
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>
>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>
>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>
>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>> different
>>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>>> init daemon process
>>>>>>>
>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>
>>>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>>>> broken)
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>
>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>
>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>> (maybe someone else on this list wants to suggest 
>>>>>>>> improvements?)
>>>>>>>>
>>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>
>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>
>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>
>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>> rules inserted
>>>>>>>>>
>>>>>>>>> 2. reproduce the issues
>>>>>>>>>
>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>
>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>> rules re-inserted
>>>>>>>>>
>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>
>>>>>>>>>> =====
>>>>>>>>>>
>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>> bad
>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>
>>>>>>>>>> =====
>>>>>>>>>>
>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>>> parameters when they are running etc)
>>>>>>>>>>
>>>>>>>>>> ========
>>>>>>>>>>
>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat 
>>>>>>>>>> #
>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>> export JAVA_HOME
>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>> export PATH
>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>> case $1 in
>>>>>>>>>> start)
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>> ;;
>>>>>>>>>> stop)
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>> ;;
>>>>>>>>>> restart)
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>> ;;
>>>>>>>>>> esac
>>>>>>>>>> exit 0
>>>>>>>>>>
>>>>>>>>>> ==========
>>>>>>>>>>
>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>
>>>>>>>>>> ==========
>>>>>>>>>>
>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>
>>>>>>>>>> ===============
>>>>>>>>>>
>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>
>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>>> Walid
>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> Morning Dominick,
>>>>>>>>>>
>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> 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<<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=0x3
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>> 5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B6
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 6
>>>>>>> B0
>>>>>>> 2
>>>>>>> Dominick Grift
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>> 02
>>>>>> Dominick Grift
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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=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

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

[Dominick Grift]

On 08/24/2016 04:16 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
> 

I think that might be only possible with selinux user space >= 2.4, and
i am not even sure if that is possible you would have to try it out

you would do something like this (might have syntax errors):

cat >myport.cil<<EOF
(type myport)
(typeattributeset port_type myport)
(portcon tcp 12345 (system_u object_r myport (s0 s0)))
EOF
sudo semodule -i myport.cil

seinfo --portcon | grep 12345

> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 19 August 2016 18:23
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>> Ok - what would be a use case for the java_role_template?
> 
> Not quite sure ... but role_templates are generally for user applications and not for system services
> 
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 16:53
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>
>>>
>>
>> The transition happens on the shell script, and the domain associated 
>> with the shell script process should then be allowed to execute java
>>
>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell 
>> script)
>>
>> java_exec(myapp_t)
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 14:14
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>
>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>
>>> I do not think that template was meant for that, but if it works if works.
>>>
>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>> -----Original Message-----
>>>> From: Fakim, Walid
>>>> Sent: 16 August 2016 15:32
>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> I'll take a look - thank you.
>>>>
>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 16 August 2016 15:23
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick,
>>>>>>
>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>> service to run, it always makes sense to run that service as 
>>>>>> system_u:system_r:service_domain_t
>>>>>
>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>
>>>>>>
>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>
>>>>>
>>>>> The way confined admins commonly work is:
>>>>
>>>> Here is a RedHat example of how such an adm role could look:
>>>>
>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/p
>>>> o
>>>> l
>>>> icy/modules/roles/logadm.te
>>>>
>>>> although i would not use the userdom_confined_admin_template because 
>>>> i would not want to allow privileged logins. Instead i would use the 
>>>> base_user_template for the role and require the user to log into the 
>>>> system with the unprivileged staff_r and then change to the 
>>>> privileged role with sudo manually
>>>>
>>>>>
>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>> You would create a new selinux user id (for example 
>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>
>>>>> 2. then you would create a admin role. This role can be access via 
>>>>> sudo
>>>>> example: jboss_tomcat_adm_r
>>>>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>>>>> id, so theres now 3 roles associated with jboss_tomcat_adm_u 
>>>>> (staff_r system_r and jboss_tomcat_r)
>>>>>
>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>
>>>>> 4. the user can now use sudo to change to his privileged 
>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>
>>>>> 5. now the user has context:
>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>
>>>>> + is associated with root
>>>>>
>>>>> 6. this allows root associated with 
>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>
>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>> service jboss_tomcat start
>>>>>
>>>>> Then there is a rule that tells selinux when a process associated 
>>>>> with role jboss_tomcat_adm_r executes an init script file with type 
>>>>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>>>>> jboss_tomcat_adm_r to system_r
>>>>>
>>>>> thus the service ends up with:
>>>>>
>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>
>>>>> if it is started manually via the init script by the admin and with
>>>>>
>>>>> system_u:system_r:jboss_tomcat_t
>>>>>
>>>>> if it is started by the system user
>>>>>
>>>>> I hope that clears at least some of this up
>>>>>
>>>>>
>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>> Walid
>>>>>> Sent: 15 August 2016 16:30
>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 16:24
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>>>>
>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>
>>>>>>
>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>
>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>
>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>
>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>> manage the
>>>>>> apache-tomcat)
>>>>>>
>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>
>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>
>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>
>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>
>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>
>>>>>>>
>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>
>>>>>>> ====
>>>>>>>
>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>
>>>>>>> Does that give you enough to go by?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 15:55
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>
>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>
>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>> SELinux user and role to confine my application
>>>>>>>
>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>> the system or is it just a system user to run the application 
>>>>>>> with?)
>>>>>>>
>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>
>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>
>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>
>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>
>>>>>>> Are the above two assumptions right?
>>>>>>>
>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>
>>>>>>>>
>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>
>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>
>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>
>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>> different
>>>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>>>> init daemon process
>>>>>>>>
>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>
>>>>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>>>>> broken)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>
>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>
>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>> (maybe someone else on this list wants to suggest 
>>>>>>>>> improvements?)
>>>>>>>>>
>>>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>
>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>
>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>
>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>> rules inserted
>>>>>>>>>>
>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>
>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>
>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>> rules re-inserted
>>>>>>>>>>
>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>
>>>>>>>>>>> =====
>>>>>>>>>>>
>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>> bad
>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>
>>>>>>>>>>> =====
>>>>>>>>>>>
>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>>>> parameters when they are running etc)
>>>>>>>>>>>
>>>>>>>>>>> ========
>>>>>>>>>>>
>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat 
>>>>>>>>>>> #
>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>> export PATH
>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>> case $1 in
>>>>>>>>>>> start)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>> ;;
>>>>>>>>>>> stop)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>> ;;
>>>>>>>>>>> restart)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>> ;;
>>>>>>>>>>> esac
>>>>>>>>>>> exit 0
>>>>>>>>>>>
>>>>>>>>>>> ==========
>>>>>>>>>>>
>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>
>>>>>>>>>>> ==========
>>>>>>>>>>>
>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>
>>>>>>>>>>> ===============
>>>>>>>>>>>
>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>
>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>>>> Walid
>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>
>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> 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<<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=0x3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B6
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6
>>>>>>>> B0
>>>>>>>> 2
>>>>>>>> Dominick Grift
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>> 02
>>>>>>> Dominick Grift
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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=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/20160824/fcc203e2/attachment-0001.bin 

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

[Dominick Grift]

On 08/24/2016 04:16 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
> 

This seems to work here:

cat >myport.cil<<EOF
(type myport)
(roletype object_r myport)
(typeattributeset port_type myport)
(portcon "tcp" 12345 (system_u object_r myport ((s0) (s0))))
EOF

sudo semodule -i myport.cil

seinfo --portcon | grep myport
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 19 August 2016 18:23
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>> Ok - what would be a use case for the java_role_template?
> 
> Not quite sure ... but role_templates are generally for user applications and not for system services
> 
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 16:53
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>
>>>
>>
>> The transition happens on the shell script, and the domain associated 
>> with the shell script process should then be allowed to execute java
>>
>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell 
>> script)
>>
>> java_exec(myapp_t)
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 14:14
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>
>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>
>>> I do not think that template was meant for that, but if it works if works.
>>>
>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>> -----Original Message-----
>>>> From: Fakim, Walid
>>>> Sent: 16 August 2016 15:32
>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> I'll take a look - thank you.
>>>>
>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 16 August 2016 15:23
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick,
>>>>>>
>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>> service to run, it always makes sense to run that service as 
>>>>>> system_u:system_r:service_domain_t
>>>>>
>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>
>>>>>>
>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>
>>>>>
>>>>> The way confined admins commonly work is:
>>>>
>>>> Here is a RedHat example of how such an adm role could look:
>>>>
>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/p
>>>> o
>>>> l
>>>> icy/modules/roles/logadm.te
>>>>
>>>> although i would not use the userdom_confined_admin_template because 
>>>> i would not want to allow privileged logins. Instead i would use the 
>>>> base_user_template for the role and require the user to log into the 
>>>> system with the unprivileged staff_r and then change to the 
>>>> privileged role with sudo manually
>>>>
>>>>>
>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>> You would create a new selinux user id (for example 
>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>
>>>>> 2. then you would create a admin role. This role can be access via 
>>>>> sudo
>>>>> example: jboss_tomcat_adm_r
>>>>> that role is then also associated to the jboss_tomcat_adm_u selinux 
>>>>> id, so theres now 3 roles associated with jboss_tomcat_adm_u 
>>>>> (staff_r system_r and jboss_tomcat_r)
>>>>>
>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>
>>>>> 4. the user can now use sudo to change to his privileged 
>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>
>>>>> 5. now the user has context:
>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>
>>>>> + is associated with root
>>>>>
>>>>> 6. this allows root associated with 
>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>
>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>> service jboss_tomcat start
>>>>>
>>>>> Then there is a rule that tells selinux when a process associated 
>>>>> with role jboss_tomcat_adm_r executes an init script file with type 
>>>>> jboss_tomcat_initrc_exec_t, then automatically role transition from 
>>>>> jboss_tomcat_adm_r to system_r
>>>>>
>>>>> thus the service ends up with:
>>>>>
>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>
>>>>> if it is started manually via the init script by the admin and with
>>>>>
>>>>> system_u:system_r:jboss_tomcat_t
>>>>>
>>>>> if it is started by the system user
>>>>>
>>>>> I hope that clears at least some of this up
>>>>>
>>>>>
>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>> Walid
>>>>>> Sent: 15 August 2016 16:30
>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 16:24
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>>>>>>
>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>
>>>>>>
>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>
>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>
>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>
>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>> manage the
>>>>>> apache-tomcat)
>>>>>>
>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>
>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>
>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>
>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>
>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>
>>>>>>>
>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>
>>>>>>> ====
>>>>>>>
>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>
>>>>>>> Does that give you enough to go by?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 15:55
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>
>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>
>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>> SELinux user and role to confine my application
>>>>>>>
>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>> the system or is it just a system user to run the application 
>>>>>>> with?)
>>>>>>>
>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>
>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>
>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>
>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>
>>>>>>> Are the above two assumptions right?
>>>>>>>
>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>
>>>>>>>>
>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>
>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>
>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>
>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>> different
>>>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>>>> init daemon process
>>>>>>>>
>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>
>>>>>>>> But again, if it works for you then it works (dont fix what isnt
>>>>>>>> broken)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>
>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>
>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>> (maybe someone else on this list wants to suggest 
>>>>>>>>> improvements?)
>>>>>>>>>
>>>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>
>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>
>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>
>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>> rules inserted
>>>>>>>>>>
>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>
>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>
>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>> rules re-inserted
>>>>>>>>>>
>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>
>>>>>>>>>>> =====
>>>>>>>>>>>
>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>> bad
>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>
>>>>>>>>>>> =====
>>>>>>>>>>>
>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>>>> parameters when they are running etc)
>>>>>>>>>>>
>>>>>>>>>>> ========
>>>>>>>>>>>
>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat 
>>>>>>>>>>> #
>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>> export PATH
>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>> case $1 in
>>>>>>>>>>> start)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>> ;;
>>>>>>>>>>> stop)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>> ;;
>>>>>>>>>>> restart)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>> ;;
>>>>>>>>>>> esac
>>>>>>>>>>> exit 0
>>>>>>>>>>>
>>>>>>>>>>> ==========
>>>>>>>>>>>
>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>
>>>>>>>>>>> ==========
>>>>>>>>>>>
>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>
>>>>>>>>>>> ===============
>>>>>>>>>>>
>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>
>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>>>> Walid
>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>
>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> 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<<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=0x3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B6
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6B
>>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6
>>>>>>>> B0
>>>>>>>> 2
>>>>>>>> Dominick Grift
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>> 02
>>>>>>> Dominick Grift
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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=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/20160824/a0e2fc3b/attachment-0001.bin 

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

[Fakim, Walid]

Unfortunately am getting this error :

[root at server2 protocode]# semodule -i myport.cil
libsepol.module_package_read_offsets: wrong magic number for module package:  expected 0xf97cff8f, got 0x70797428
libsemanage.parse_module_headers: Could not parse module data.
semodule:  Failed on myport.cil!

===

Am running this on CentOS 6.8



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 24 August 2016 16:21
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/24/2016 04:16 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
> 

This seems to work here:

cat >myport.cil<<EOF
(type myport)
(roletype object_r myport)
(typeattributeset port_type myport)
(portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF

sudo semodule -i myport.cil

seinfo --portcon | grep myport
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 19 August 2016 18:23
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>> Ok - what would be a use case for the java_role_template?
> 
> Not quite sure ... but role_templates are generally for user 
> applications and not for system services
> 
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 16:53
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>
>>>
>>
>> The transition happens on the shell script, and the domain associated 
>> with the shell script process should then be allowed to execute java
>>
>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>> script)
>>
>> java_exec(myapp_t)
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 14:14
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>
>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>
>>> I do not think that template was meant for that, but if it works if works.
>>>
>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>> -----Original Message-----
>>>> From: Fakim, Walid
>>>> Sent: 16 August 2016 15:32
>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> I'll take a look - thank you.
>>>>
>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 16 August 2016 15:23
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick,
>>>>>>
>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>> service to run, it always makes sense to run that service as 
>>>>>> system_u:system_r:service_domain_t
>>>>>
>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>
>>>>>>
>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>
>>>>>
>>>>> The way confined admins commonly work is:
>>>>
>>>> Here is a RedHat example of how such an adm role could look:
>>>>
>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/
>>>> p
>>>> o
>>>> l
>>>> icy/modules/roles/logadm.te
>>>>
>>>> although i would not use the userdom_confined_admin_template 
>>>> because i would not want to allow privileged logins. Instead i 
>>>> would use the base_user_template for the role and require the user 
>>>> to log into the system with the unprivileged staff_r and then 
>>>> change to the privileged role with sudo manually
>>>>
>>>>>
>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>> You would create a new selinux user id (for example 
>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>
>>>>> 2. then you would create a admin role. This role can be access via 
>>>>> sudo
>>>>> example: jboss_tomcat_adm_r
>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>> selinux id, so theres now 3 roles associated with 
>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>
>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>
>>>>> 4. the user can now use sudo to change to his privileged 
>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>
>>>>> 5. now the user has context:
>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>
>>>>> + is associated with root
>>>>>
>>>>> 6. this allows root associated with 
>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>
>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>> service jboss_tomcat start
>>>>>
>>>>> Then there is a rule that tells selinux when a process associated 
>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>
>>>>> thus the service ends up with:
>>>>>
>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>
>>>>> if it is started manually via the init script by the admin and 
>>>>> with
>>>>>
>>>>> system_u:system_r:jboss_tomcat_t
>>>>>
>>>>> if it is started by the system user
>>>>>
>>>>> I hope that clears at least some of this up
>>>>>
>>>>>
>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>> Walid
>>>>>> Sent: 15 August 2016 16:30
>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 15 August 2016 16:24
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bas
>>>>>>> h
>>>>>>>
>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>
>>>>>>
>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>
>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>
>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>
>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>> manage the
>>>>>> apache-tomcat)
>>>>>>
>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>
>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>
>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>
>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>
>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>
>>>>>>>
>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>
>>>>>>> ====
>>>>>>>
>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>
>>>>>>> Does that give you enough to go by?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 15:55
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>
>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>
>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>> SELinux user and role to confine my application
>>>>>>>
>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>> the system or is it just a system user to run the application
>>>>>>> with?)
>>>>>>>
>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>
>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>
>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>
>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>
>>>>>>> Are the above two assumptions right?
>>>>>>>
>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>
>>>>>>>>
>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>
>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>
>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>
>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>> different
>>>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>>>> init daemon process
>>>>>>>>
>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>
>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>> isnt
>>>>>>>> broken)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>
>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>
>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>> improvements?)
>>>>>>>>>
>>>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>
>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>
>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>
>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>> rules inserted
>>>>>>>>>>
>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>
>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>
>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>> rules re-inserted
>>>>>>>>>>
>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>
>>>>>>>>>>> =====
>>>>>>>>>>>
>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>> bad
>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>
>>>>>>>>>>> =====
>>>>>>>>>>>
>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>>>> parameters when they are running etc)
>>>>>>>>>>>
>>>>>>>>>>> ========
>>>>>>>>>>>
>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>> #
>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat 
>>>>>>>>>>> #
>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>> export PATH
>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>> case $1 in
>>>>>>>>>>> start)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>> ;;
>>>>>>>>>>> stop)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>> ;;
>>>>>>>>>>> restart)
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>> ;;
>>>>>>>>>>> esac
>>>>>>>>>>> exit 0
>>>>>>>>>>>
>>>>>>>>>>> ==========
>>>>>>>>>>>
>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>
>>>>>>>>>>> ==========
>>>>>>>>>>>
>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>
>>>>>>>>>>> ===============
>>>>>>>>>>>
>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>
>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>
>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> 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<<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=0x
>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>> 5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C7
>>>>>>>>>>>> B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B6
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6
>>>>>>>> B0
>>>>>>>> 2
>>>>>>>> Dominick Grift
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>> 6B02
>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 6
>>>>>>> B
>>>>>>> 02
>>>>>>> Dominick Grift
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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=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

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

[Dominick Grift]

On 08/24/2016 05:40 PM, Fakim, Walid wrote:
> Unfortunately am getting this error :
> 
> [root at server2 protocode]# semodule -i myport.cil
> libsepol.module_package_read_offsets: wrong magic number for module package:  expected 0xf97cff8f, got 0x70797428
> libsemanage.parse_module_headers: Could not parse module data.
> semodule:  Failed on myport.cil!
> 
> ===
> 
> Am running this on CentOS 6.8
> 
>

Yes, only works with selinux user space >=2.4

No, I am not aware of any other way's on older selinux systems

> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 24 August 2016 16:21
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>
> 
> This seems to work here:
> 
> cat >myport.cil<<EOF
> (type myport)
> (roletype object_r myport)
> (typeattributeset port_type myport)
> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
> 
> sudo semodule -i myport.cil
> 
> seinfo --portcon | grep myport
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 18:23
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>> Ok - what would be a use case for the java_role_template?
>>
>> Not quite sure ... but role_templates are generally for user 
>> applications and not for system services
>>
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 16:53
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>
>>>>
>>>
>>> The transition happens on the shell script, and the domain associated 
>>> with the shell script process should then be allowed to execute java
>>>
>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>> script)
>>>
>>> java_exec(myapp_t)
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 19 August 2016 14:14
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>> Hi Dominick,
>>>>>
>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>
>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>
>>>> I do not think that template was meant for that, but if it works if works.
>>>>
>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>> -----Original Message-----
>>>>> From: Fakim, Walid
>>>>> Sent: 16 August 2016 15:32
>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> I'll take a look - thank you.
>>>>>
>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 16 August 2016 15:23
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick,
>>>>>>>
>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>> system_u:system_r:service_domain_t
>>>>>>
>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>
>>>>>>>
>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>
>>>>>>
>>>>>> The way confined admins commonly work is:
>>>>>
>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>
>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/
>>>>> p
>>>>> o
>>>>> l
>>>>> icy/modules/roles/logadm.te
>>>>>
>>>>> although i would not use the userdom_confined_admin_template 
>>>>> because i would not want to allow privileged logins. Instead i 
>>>>> would use the base_user_template for the role and require the user 
>>>>> to log into the system with the unprivileged staff_r and then 
>>>>> change to the privileged role with sudo manually
>>>>>
>>>>>>
>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>> You would create a new selinux user id (for example 
>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>
>>>>>> 2. then you would create a admin role. This role can be access via 
>>>>>> sudo
>>>>>> example: jboss_tomcat_adm_r
>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>
>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>
>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>
>>>>>> 5. now the user has context:
>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>
>>>>>> + is associated with root
>>>>>>
>>>>>> 6. this allows root associated with 
>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>
>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>> service jboss_tomcat start
>>>>>>
>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>
>>>>>> thus the service ends up with:
>>>>>>
>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>
>>>>>> if it is started manually via the init script by the admin and 
>>>>>> with
>>>>>>
>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>
>>>>>> if it is started by the system user
>>>>>>
>>>>>> I hope that clears at least some of this up
>>>>>>
>>>>>>
>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>> Walid
>>>>>>> Sent: 15 August 2016 16:30
>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 16:24
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bas
>>>>>>>> h
>>>>>>>>
>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>
>>>>>>>
>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>
>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>
>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>
>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>> manage the
>>>>>>> apache-tomcat)
>>>>>>>
>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>
>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>
>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>
>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>
>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>
>>>>>>>>
>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>
>>>>>>>> ====
>>>>>>>>
>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>
>>>>>>>> Does that give you enough to go by?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>
>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>
>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>> SELinux user and role to confine my application
>>>>>>>>
>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>> the system or is it just a system user to run the application
>>>>>>>> with?)
>>>>>>>>
>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>
>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>
>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>
>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>
>>>>>>>> Are the above two assumptions right?
>>>>>>>>
>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>
>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>
>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>
>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>> different
>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. an 
>>>>>>>>> init daemon process
>>>>>>>>>
>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>
>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>> isnt
>>>>>>>>> broken)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>
>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>
>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>> improvements?)
>>>>>>>>>>
>>>>>>>>>> If it works it works (and with work i mean not just if it runs 
>>>>>>>>>> but also if your security goals are verified to be achieved)
>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>
>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>
>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>
>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>> rules inserted
>>>>>>>>>>>
>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>
>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>
>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>
>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>
>>>>>>>>>>>> =====
>>>>>>>>>>>>
>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>> bad
>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>
>>>>>>>>>>>> =====
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>> packaged tomcat version running installed via yum to compare 
>>>>>>>>>>>> parameters when they are running etc)
>>>>>>>>>>>>
>>>>>>>>>>>> ========
>>>>>>>>>>>>
>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>> #
>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: tomcat 
>>>>>>>>>>>> #
>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>> export PATH
>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>> case $1 in
>>>>>>>>>>>> start)
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>> ;;
>>>>>>>>>>>> stop)
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>> ;;
>>>>>>>>>>>> restart)
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>> ;;
>>>>>>>>>>>> esac
>>>>>>>>>>>> exit 0
>>>>>>>>>>>>
>>>>>>>>>>>> ==========
>>>>>>>>>>>>
>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>
>>>>>>>>>>>> ==========
>>>>>>>>>>>>
>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>
>>>>>>>>>>>> ===============
>>>>>>>>>>>>
>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>
>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>
>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> 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<<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=0x
>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7B
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B6
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 6B
>>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6
>>>>>>>>> B0
>>>>>>>>> 2
>>>>>>>>> Dominick Grift
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>> 6B02
>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6
>>>>>>>> B
>>>>>>>> 02
>>>>>>>> Dominick Grift
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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=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/20160824/a5712c28/attachment-0001.bin 

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

[Fakim, Walid]

Hi Dominick,

2 questions from a conceptual level:

1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?

2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?


Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 24 August 2016 16:43
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/24/2016 05:40 PM, Fakim, Walid wrote:
> Unfortunately am getting this error :
> 
> [root at server2 protocode]# semodule -i myport.cil
> libsepol.module_package_read_offsets: wrong magic number for module 
> package:  expected 0xf97cff8f, got 0x70797428
> libsemanage.parse_module_headers: Could not parse module data.
> semodule:  Failed on myport.cil!
> 
> ===
> 
> Am running this on CentOS 6.8
> 
>

Yes, only works with selinux user space >=2.4

No, I am not aware of any other way's on older selinux systems

> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 24 August 2016 16:21
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>
> 
> This seems to work here:
> 
> cat >myport.cil<<EOF
> (type myport)
> (roletype object_r myport)
> (typeattributeset port_type myport)
> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
> 
> sudo semodule -i myport.cil
> 
> seinfo --portcon | grep myport
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 19 August 2016 18:23
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>> Ok - what would be a use case for the java_role_template?
>>
>> Not quite sure ... but role_templates are generally for user 
>> applications and not for system services
>>
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 16:53
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>
>>>>
>>>
>>> The transition happens on the shell script, and the domain 
>>> associated with the shell script process should then be allowed to 
>>> execute java
>>>
>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>> script)
>>>
>>> java_exec(myapp_t)
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 19 August 2016 14:14
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>> Hi Dominick,
>>>>>
>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>
>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>
>>>> I do not think that template was meant for that, but if it works if works.
>>>>
>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>> -----Original Message-----
>>>>> From: Fakim, Walid
>>>>> Sent: 16 August 2016 15:32
>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> I'll take a look - thank you.
>>>>>
>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 16 August 2016 15:23
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick,
>>>>>>>
>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>> system_u:system_r:service_domain_t
>>>>>>
>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>
>>>>>>>
>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>
>>>>>>
>>>>>> The way confined admins commonly work is:
>>>>>
>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>
>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>> /
>>>>> p
>>>>> o
>>>>> l
>>>>> icy/modules/roles/logadm.te
>>>>>
>>>>> although i would not use the userdom_confined_admin_template 
>>>>> because i would not want to allow privileged logins. Instead i 
>>>>> would use the base_user_template for the role and require the user 
>>>>> to log into the system with the unprivileged staff_r and then 
>>>>> change to the privileged role with sudo manually
>>>>>
>>>>>>
>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>> You would create a new selinux user id (for example 
>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>
>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>> via sudo
>>>>>> example: jboss_tomcat_adm_r
>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>
>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>
>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>
>>>>>> 5. now the user has context:
>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>
>>>>>> + is associated with root
>>>>>>
>>>>>> 6. this allows root associated with 
>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>
>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>> service jboss_tomcat start
>>>>>>
>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>
>>>>>> thus the service ends up with:
>>>>>>
>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>
>>>>>> if it is started manually via the init script by the admin and 
>>>>>> with
>>>>>>
>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>
>>>>>> if it is started by the system user
>>>>>>
>>>>>> I hope that clears at least some of this up
>>>>>>
>>>>>>
>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>> Walid
>>>>>>> Sent: 15 August 2016 16:30
>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 15 August 2016 16:24
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>> s
>>>>>>>> h
>>>>>>>>
>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>
>>>>>>>
>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>
>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>
>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>
>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>> manage the
>>>>>>> apache-tomcat)
>>>>>>>
>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>
>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>
>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>
>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>
>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>
>>>>>>>>
>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>
>>>>>>>> ====
>>>>>>>>
>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>
>>>>>>>> Does that give you enough to go by?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>
>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>
>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>> SELinux user and role to confine my application
>>>>>>>>
>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>> the system or is it just a system user to run the application
>>>>>>>> with?)
>>>>>>>>
>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>
>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>
>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>
>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>
>>>>>>>> Are the above two assumptions right?
>>>>>>>>
>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>
>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>
>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>
>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>> different
>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>> an init daemon process
>>>>>>>>>
>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>
>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>> isnt
>>>>>>>>> broken)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>
>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>
>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>> improvements?)
>>>>>>>>>>
>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>> achieved)
>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>
>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>
>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>
>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>> rules inserted
>>>>>>>>>>>
>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>
>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>
>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>
>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>
>>>>>>>>>>>> =====
>>>>>>>>>>>>
>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>> bad
>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>
>>>>>>>>>>>> =====
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>
>>>>>>>>>>>> ========
>>>>>>>>>>>>
>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>> #
>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>> tomcat #
>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>> export PATH
>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>> case $1 in
>>>>>>>>>>>> start)
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>> ;;
>>>>>>>>>>>> stop)
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>> ;;
>>>>>>>>>>>> restart)
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>> ;;
>>>>>>>>>>>> esac
>>>>>>>>>>>> exit 0
>>>>>>>>>>>>
>>>>>>>>>>>> ==========
>>>>>>>>>>>>
>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>
>>>>>>>>>>>> ==========
>>>>>>>>>>>>
>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>
>>>>>>>>>>>> ===============
>>>>>>>>>>>>
>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>
>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>
>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>> 5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>> F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7B
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B6
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 6B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6
>>>>>>>>> B0
>>>>>>>>> 2
>>>>>>>>> Dominick Grift
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>> 6B02
>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 6
>>>>>>>> B
>>>>>>>> 02
>>>>>>>> Dominick Grift
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>> 6B02
>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> 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

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

[Dominick Grift]

On 08/31/2016 04:50 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> 2 questions from a conceptual level:
> 
> 1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?
> 

No, system users aren't login users (they dont login via login programs
such as sshd, gdm etc)

> 2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?

processes that are "unconfined" should be able to interact with and
confined processes by default.

Confined processes aren't able to interact with unconfined processes.

So for example your unconfined process is by default allowed to send
messages via dbus to confined processes, but confined processes are not
allowed to reply to unconfined processes.

> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 24 August 2016 16:43
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/24/2016 05:40 PM, Fakim, Walid wrote:
>> Unfortunately am getting this error :
>>
>> [root at server2 protocode]# semodule -i myport.cil
>> libsepol.module_package_read_offsets: wrong magic number for module 
>> package:  expected 0xf97cff8f, got 0x70797428
>> libsemanage.parse_module_headers: Could not parse module data.
>> semodule:  Failed on myport.cil!
>>
>> ===
>>
>> Am running this on CentOS 6.8
>>
>>
> 
> Yes, only works with selinux user space >=2.4
> 
> No, I am not aware of any other way's on older selinux systems
> 
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 24 August 2016 16:21
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>>
>>
>> This seems to work here:
>>
>> cat >myport.cil<<EOF
>> (type myport)
>> (roletype object_r myport)
>> (typeattributeset port_type myport)
>> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
>>
>> sudo semodule -i myport.cil
>>
>> seinfo --portcon | grep myport
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 18:23
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>>> Ok - what would be a use case for the java_role_template?
>>>
>>> Not quite sure ... but role_templates are generally for user 
>>> applications and not for system services
>>>
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 19 August 2016 16:53
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>>
>>>>>
>>>>
>>>> The transition happens on the shell script, and the domain 
>>>> associated with the shell script process should then be allowed to 
>>>> execute java
>>>>
>>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>>> script)
>>>>
>>>> java_exec(myapp_t)
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 19 August 2016 14:14
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick,
>>>>>>
>>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>>
>>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>>
>>>>> I do not think that template was meant for that, but if it works if works.
>>>>>
>>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Fakim, Walid
>>>>>> Sent: 16 August 2016 15:32
>>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> I'll take a look - thank you.
>>>>>>
>>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 16 August 2016 15:23
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>>> Hi Dominick,
>>>>>>>>
>>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>>> system_u:system_r:service_domain_t
>>>>>>>
>>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>>
>>>>>>>>
>>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>>
>>>>>>>
>>>>>>> The way confined admins commonly work is:
>>>>>>
>>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>>
>>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>>> /
>>>>>> p
>>>>>> o
>>>>>> l
>>>>>> icy/modules/roles/logadm.te
>>>>>>
>>>>>> although i would not use the userdom_confined_admin_template 
>>>>>> because i would not want to allow privileged logins. Instead i 
>>>>>> would use the base_user_template for the role and require the user 
>>>>>> to log into the system with the unprivileged staff_r and then 
>>>>>> change to the privileged role with sudo manually
>>>>>>
>>>>>>>
>>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>>> You would create a new selinux user id (for example 
>>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>>
>>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>>> via sudo
>>>>>>> example: jboss_tomcat_adm_r
>>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>>
>>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>>
>>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>>
>>>>>>> 5. now the user has context:
>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>
>>>>>>> + is associated with root
>>>>>>>
>>>>>>> 6. this allows root associated with 
>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>
>>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>>> service jboss_tomcat start
>>>>>>>
>>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>>
>>>>>>> thus the service ends up with:
>>>>>>>
>>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>>
>>>>>>> if it is started manually via the init script by the admin and 
>>>>>>> with
>>>>>>>
>>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>>
>>>>>>> if it is started by the system user
>>>>>>>
>>>>>>> I hope that clears at least some of this up
>>>>>>>
>>>>>>>
>>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>> Walid
>>>>>>>> Sent: 15 August 2016 16:30
>>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 16:24
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>>> s
>>>>>>>>> h
>>>>>>>>>
>>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>>
>>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>>
>>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>>
>>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>>> manage the
>>>>>>>> apache-tomcat)
>>>>>>>>
>>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>>
>>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>>
>>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>>
>>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>>
>>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>>
>>>>>>>>> ====
>>>>>>>>>
>>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>>
>>>>>>>>> Does that give you enough to go by?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>>
>>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>>
>>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>>> SELinux user and role to confine my application
>>>>>>>>>
>>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>>> the system or is it just a system user to run the application
>>>>>>>>> with?)
>>>>>>>>>
>>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>>
>>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>>
>>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>>
>>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>>
>>>>>>>>> Are the above two assumptions right?
>>>>>>>>>
>>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>>
>>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>>
>>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>>
>>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>>> different
>>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>>> an init daemon process
>>>>>>>>>>
>>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>>
>>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>>> isnt
>>>>>>>>>> broken)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>>
>>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>>> improvements?)
>>>>>>>>>>>
>>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>>> achieved)
>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>>> rules inserted
>>>>>>>>>>>>
>>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>>
>>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>>
>>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>>
>>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>>
>>>>>>>>>>>>> =====
>>>>>>>>>>>>>
>>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>>> bad
>>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>>
>>>>>>>>>>>>> =====
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========
>>>>>>>>>>>>>
>>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>>> #
>>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>>> tomcat #
>>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>>> export PATH
>>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>>> case $1 in
>>>>>>>>>>>>> start)
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>>> ;;
>>>>>>>>>>>>> stop)
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>>> ;;
>>>>>>>>>>>>> restart)
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>>> ;;
>>>>>>>>>>>>> esac
>>>>>>>>>>>>> exit 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>
>>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>>
>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>
>>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>>
>>>>>>>>>>>>> ===============
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B6
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 6B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 6
>>>>>>>>>> B0
>>>>>>>>>> 2
>>>>>>>>>> Dominick Grift
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>> 6B02
>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6
>>>>>>>>> B
>>>>>>>>> 02
>>>>>>>>> Dominick Grift
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>> 6B02
>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> 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
> 


-- 
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/20160831/b418d95b/attachment-0001.bin 

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

[Fakim, Walid]

To go a bit further, imagine the following scenario :

rsyslogd running unconfined needs to send some logs to a remote log collector. The "/var/log/myapp_log" files have a custom type my_app_log_t which is defined and used as part of the myapp policy.

By default, will rsyslogd have access to those files? My guess would be not unless defined somewhere in the policy? Or would we have to also confine rsyslogd and define some allow rules between rsyslogd and myapp to make this happen?

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 31 August 2016 17:37
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/31/2016 04:50 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> 2 questions from a conceptual level:
> 
> 1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?
> 

No, system users aren't login users (they dont login via login programs
such as sshd, gdm etc)

> 2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?

processes that are "unconfined" should be able to interact with and
confined processes by default.

Confined processes aren't able to interact with unconfined processes.

So for example your unconfined process is by default allowed to send
messages via dbus to confined processes, but confined processes are not
allowed to reply to unconfined processes.

> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 24 August 2016 16:43
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/24/2016 05:40 PM, Fakim, Walid wrote:
>> Unfortunately am getting this error :
>>
>> [root at server2 protocode]# semodule -i myport.cil
>> libsepol.module_package_read_offsets: wrong magic number for module 
>> package:  expected 0xf97cff8f, got 0x70797428
>> libsemanage.parse_module_headers: Could not parse module data.
>> semodule:  Failed on myport.cil!
>>
>> ===
>>
>> Am running this on CentOS 6.8
>>
>>
> 
> Yes, only works with selinux user space >=2.4
> 
> No, I am not aware of any other way's on older selinux systems
> 
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 24 August 2016 16:21
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>>
>>
>> This seems to work here:
>>
>> cat >myport.cil<<EOF
>> (type myport)
>> (roletype object_r myport)
>> (typeattributeset port_type myport)
>> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
>>
>> sudo semodule -i myport.cil
>>
>> seinfo --portcon | grep myport
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 19 August 2016 18:23
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>>> Ok - what would be a use case for the java_role_template?
>>>
>>> Not quite sure ... but role_templates are generally for user 
>>> applications and not for system services
>>>
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 19 August 2016 16:53
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>>
>>>>>
>>>>
>>>> The transition happens on the shell script, and the domain 
>>>> associated with the shell script process should then be allowed to 
>>>> execute java
>>>>
>>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>>> script)
>>>>
>>>> java_exec(myapp_t)
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 19 August 2016 14:14
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick,
>>>>>>
>>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>>
>>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>>
>>>>> I do not think that template was meant for that, but if it works if works.
>>>>>
>>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Fakim, Walid
>>>>>> Sent: 16 August 2016 15:32
>>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> I'll take a look - thank you.
>>>>>>
>>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 16 August 2016 15:23
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>>> Hi Dominick,
>>>>>>>>
>>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>>> system_u:system_r:service_domain_t
>>>>>>>
>>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>>
>>>>>>>>
>>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>>
>>>>>>>
>>>>>>> The way confined admins commonly work is:
>>>>>>
>>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>>
>>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>>> /
>>>>>> p
>>>>>> o
>>>>>> l
>>>>>> icy/modules/roles/logadm.te
>>>>>>
>>>>>> although i would not use the userdom_confined_admin_template 
>>>>>> because i would not want to allow privileged logins. Instead i 
>>>>>> would use the base_user_template for the role and require the user 
>>>>>> to log into the system with the unprivileged staff_r and then 
>>>>>> change to the privileged role with sudo manually
>>>>>>
>>>>>>>
>>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>>> You would create a new selinux user id (for example 
>>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>>
>>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>>> via sudo
>>>>>>> example: jboss_tomcat_adm_r
>>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>>
>>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>>
>>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>>
>>>>>>> 5. now the user has context:
>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>
>>>>>>> + is associated with root
>>>>>>>
>>>>>>> 6. this allows root associated with 
>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>
>>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>>> service jboss_tomcat start
>>>>>>>
>>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>>
>>>>>>> thus the service ends up with:
>>>>>>>
>>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>>
>>>>>>> if it is started manually via the init script by the admin and 
>>>>>>> with
>>>>>>>
>>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>>
>>>>>>> if it is started by the system user
>>>>>>>
>>>>>>> I hope that clears at least some of this up
>>>>>>>
>>>>>>>
>>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>> Walid
>>>>>>>> Sent: 15 August 2016 16:30
>>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 15 August 2016 16:24
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>>> s
>>>>>>>>> h
>>>>>>>>>
>>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>>
>>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>>
>>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>>
>>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>>> manage the
>>>>>>>> apache-tomcat)
>>>>>>>>
>>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>>
>>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>>
>>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>>
>>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>>
>>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>>
>>>>>>>>> ====
>>>>>>>>>
>>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>>
>>>>>>>>> Does that give you enough to go by?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>>
>>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>>
>>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>>> SELinux user and role to confine my application
>>>>>>>>>
>>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>>> the system or is it just a system user to run the application
>>>>>>>>> with?)
>>>>>>>>>
>>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>>
>>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>>
>>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>>
>>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>>
>>>>>>>>> Are the above two assumptions right?
>>>>>>>>>
>>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>>
>>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>>
>>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>>
>>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>>> different
>>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>>> an init daemon process
>>>>>>>>>>
>>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>>
>>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>>> isnt
>>>>>>>>>> broken)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>>
>>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>>> improvements?)
>>>>>>>>>>>
>>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>>> achieved)
>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>>> rules inserted
>>>>>>>>>>>>
>>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>>
>>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>>
>>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>>
>>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>>
>>>>>>>>>>>>> =====
>>>>>>>>>>>>>
>>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>>> bad
>>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>>
>>>>>>>>>>>>> =====
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========
>>>>>>>>>>>>>
>>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>>> #
>>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>>> tomcat #
>>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>>> export PATH
>>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>>> case $1 in
>>>>>>>>>>>>> start)
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>>> ;;
>>>>>>>>>>>>> stop)
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>>> ;;
>>>>>>>>>>>>> restart)
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>>> ;;
>>>>>>>>>>>>> esac
>>>>>>>>>>>>> exit 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>
>>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>>
>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>
>>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>>
>>>>>>>>>>>>> ===============
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C7
>>>>>>>>>>>>>> B
>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>> F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7B
>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B6
>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 6B
>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 6
>>>>>>>>>> B0
>>>>>>>>>> 2
>>>>>>>>>> Dominick Grift
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>> 6B02
>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 6
>>>>>>>>> B
>>>>>>>>> 02
>>>>>>>>> Dominick Grift
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>> 6B02
>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>> 7
>>>>>>>> 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
> 


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

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

[Dominick Grift]

On 09/01/2016 03:26 PM, Fakim, Walid wrote:
> To go a bit further, imagine the following scenario :
> 
> rsyslogd running unconfined needs to send some logs to a remote log collector. The "/var/log/myapp_log" files have a custom type my_app_log_t which is defined and used as part of the myapp policy.
> 
> By default, will rsyslogd have access to those files? My guess would be not unless defined somewhere in the policy? Or would we have to also confine rsyslogd and define some allow rules between rsyslogd and myapp to make this happen?
> 

Yes it will have access, provided that the policy is written properly.

here is how that works:

there is a type attribute called file_type, and this type attribute
should be associated with all file types.

so if you create for example:

type mylogfile_t;
logging_log_file(mylogfile_t)

then the logging_log_file macro will associate the mylogfile_t type with
the file_type type attribute automatically.

The same goes for example for unconfined processes

there is a type attribute that is associated with unconfined processes
via unconfined_domain()

so on a higher level there is a rule that uses type attributes to catch
it all, for example:

allow unconfined_domain_type file_type:file *;

So since the mylogfile_t type is associated with file_type via
logging_log_file(), and since myprocesstype_t is associated with
unconfined_domain_type via unconfined_domain() it is automatically allowed.

So as long as the policy is written properly, it should just work.

> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 31 August 2016 17:37
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/31/2016 04:50 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> 2 questions from a conceptual level:
>>
>> 1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?
>>
> 
> No, system users aren't login users (they dont login via login programs
> such as sshd, gdm etc)
> 
>> 2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?
> 
> processes that are "unconfined" should be able to interact with and
> confined processes by default.
> 
> Confined processes aren't able to interact with unconfined processes.
> 
> So for example your unconfined process is by default allowed to send
> messages via dbus to confined processes, but confined processes are not
> allowed to reply to unconfined processes.
> 
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com] 
>> Sent: 24 August 2016 16:43
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/24/2016 05:40 PM, Fakim, Walid wrote:
>>> Unfortunately am getting this error :
>>>
>>> [root at server2 protocode]# semodule -i myport.cil
>>> libsepol.module_package_read_offsets: wrong magic number for module 
>>> package:  expected 0xf97cff8f, got 0x70797428
>>> libsemanage.parse_module_headers: Could not parse module data.
>>> semodule:  Failed on myport.cil!
>>>
>>> ===
>>>
>>> Am running this on CentOS 6.8
>>>
>>>
>>
>> Yes, only works with selinux user space >=2.4
>>
>> No, I am not aware of any other way's on older selinux systems
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 24 August 2016 16:21
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>>>
>>>
>>> This seems to work here:
>>>
>>> cat >myport.cil<<EOF
>>> (type myport)
>>> (roletype object_r myport)
>>> (typeattributeset port_type myport)
>>> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
>>>
>>> sudo semodule -i myport.cil
>>>
>>> seinfo --portcon | grep myport
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 19 August 2016 18:23
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>>>> Ok - what would be a use case for the java_role_template?
>>>>
>>>> Not quite sure ... but role_templates are generally for user 
>>>> applications and not for system services
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 19 August 2016 16:53
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>>>
>>>>>>
>>>>>
>>>>> The transition happens on the shell script, and the domain 
>>>>> associated with the shell script process should then be allowed to 
>>>>> execute java
>>>>>
>>>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>>>> script)
>>>>>
>>>>> java_exec(myapp_t)
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 19 August 2016 14:14
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick,
>>>>>>>
>>>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>>>
>>>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>>>
>>>>>> I do not think that template was meant for that, but if it works if works.
>>>>>>
>>>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Fakim, Walid
>>>>>>> Sent: 16 August 2016 15:32
>>>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> I'll take a look - thank you.
>>>>>>>
>>>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 16 August 2016 15:23
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>>>> Hi Dominick,
>>>>>>>>>
>>>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>>>> system_u:system_r:service_domain_t
>>>>>>>>
>>>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The way confined admins commonly work is:
>>>>>>>
>>>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>>>
>>>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>>>> /
>>>>>>> p
>>>>>>> o
>>>>>>> l
>>>>>>> icy/modules/roles/logadm.te
>>>>>>>
>>>>>>> although i would not use the userdom_confined_admin_template 
>>>>>>> because i would not want to allow privileged logins. Instead i 
>>>>>>> would use the base_user_template for the role and require the user 
>>>>>>> to log into the system with the unprivileged staff_r and then 
>>>>>>> change to the privileged role with sudo manually
>>>>>>>
>>>>>>>>
>>>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>>>> You would create a new selinux user id (for example 
>>>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>>>
>>>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>>>> via sudo
>>>>>>>> example: jboss_tomcat_adm_r
>>>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>>>
>>>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>>>
>>>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>>>
>>>>>>>> 5. now the user has context:
>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>
>>>>>>>> + is associated with root
>>>>>>>>
>>>>>>>> 6. this allows root associated with 
>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>
>>>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>>>> service jboss_tomcat start
>>>>>>>>
>>>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>>>
>>>>>>>> thus the service ends up with:
>>>>>>>>
>>>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>>>
>>>>>>>> if it is started manually via the init script by the admin and 
>>>>>>>> with
>>>>>>>>
>>>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>>>
>>>>>>>> if it is started by the system user
>>>>>>>>
>>>>>>>> I hope that clears at least some of this up
>>>>>>>>
>>>>>>>>
>>>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>> Walid
>>>>>>>>> Sent: 15 August 2016 16:30
>>>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 16:24
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>>>> s
>>>>>>>>>> h
>>>>>>>>>>
>>>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>>>
>>>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>>>
>>>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>>>
>>>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>>>> manage the
>>>>>>>>> apache-tomcat)
>>>>>>>>>
>>>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>>>
>>>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>>>
>>>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>>>
>>>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>>>
>>>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>>>
>>>>>>>>>> ====
>>>>>>>>>>
>>>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>>>
>>>>>>>>>> Does that give you enough to go by?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>>>
>>>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>>>
>>>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>>>> SELinux user and role to confine my application
>>>>>>>>>>
>>>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>>>> the system or is it just a system user to run the application
>>>>>>>>>> with?)
>>>>>>>>>>
>>>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>>>
>>>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>>>
>>>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>>>
>>>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>>>
>>>>>>>>>> Are the above two assumptions right?
>>>>>>>>>>
>>>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>>>
>>>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>>>
>>>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>>>
>>>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>>>> different
>>>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>>>> an init daemon process
>>>>>>>>>>>
>>>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>>>
>>>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>>>> isnt
>>>>>>>>>>> broken)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>>>
>>>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>>>> improvements?)
>>>>>>>>>>>>
>>>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>>>> achieved)
>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>>>> rules inserted
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>>>
>>>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>>>> bad
>>>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ========
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>>>> #
>>>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>>>> tomcat #
>>>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>>>> export PATH
>>>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>>>> case $1 in
>>>>>>>>>>>>>> start)
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>> stop)
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>> restart)
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>> esac
>>>>>>>>>>>>>> exit 0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ===============
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7B
>>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B6
>>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 6B
>>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 6
>>>>>>>>>>> B0
>>>>>>>>>>> 2
>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>>> 6B02
>>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 6
>>>>>>>>>> B
>>>>>>>>>> 02
>>>>>>>>>> Dominick Grift
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>> 6B02
>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>>> 7
>>>>>>>>> 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
>>
> 
> 


-- 
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/20160901/cadcb2f8/attachment-0001.bin 

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

[Fakim, Walid]

Hi Dominick,

Just to clarify (for my own understanding):

---

Unconfined domain syslog_t could interact with confined process domain myapp_t  and resources of type myapp_log_t as long as this is explicitly allowed in myapp policy. 

But it wouldn't be allowed by default.

Is that correct?

---



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 01 September 2016 14:35
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 09/01/2016 03:26 PM, Fakim, Walid wrote:
> To go a bit further, imagine the following scenario :
> 
> rsyslogd running unconfined needs to send some logs to a remote log collector. The "/var/log/myapp_log" files have a custom type my_app_log_t which is defined and used as part of the myapp policy.
> 
> By default, will rsyslogd have access to those files? My guess would be not unless defined somewhere in the policy? Or would we have to also confine rsyslogd and define some allow rules between rsyslogd and myapp to make this happen?
> 

Yes it will have access, provided that the policy is written properly.

here is how that works:

there is a type attribute called file_type, and this type attribute
should be associated with all file types.

so if you create for example:

type mylogfile_t;
logging_log_file(mylogfile_t)

then the logging_log_file macro will associate the mylogfile_t type with
the file_type type attribute automatically.

The same goes for example for unconfined processes

there is a type attribute that is associated with unconfined processes
via unconfined_domain()

so on a higher level there is a rule that uses type attributes to catch
it all, for example:

allow unconfined_domain_type file_type:file *;

So since the mylogfile_t type is associated with file_type via
logging_log_file(), and since myprocesstype_t is associated with
unconfined_domain_type via unconfined_domain() it is automatically allowed.

So as long as the policy is written properly, it should just work.

> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 31 August 2016 17:37
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/31/2016 04:50 PM, Fakim, Walid wrote:
>> Hi Dominick,
>>
>> 2 questions from a conceptual level:
>>
>> 1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?
>>
> 
> No, system users aren't login users (they dont login via login programs
> such as sshd, gdm etc)
> 
>> 2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?
> 
> processes that are "unconfined" should be able to interact with and
> confined processes by default.
> 
> Confined processes aren't able to interact with unconfined processes.
> 
> So for example your unconfined process is by default allowed to send
> messages via dbus to confined processes, but confined processes are not
> allowed to reply to unconfined processes.
> 
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com] 
>> Sent: 24 August 2016 16:43
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/24/2016 05:40 PM, Fakim, Walid wrote:
>>> Unfortunately am getting this error :
>>>
>>> [root at server2 protocode]# semodule -i myport.cil
>>> libsepol.module_package_read_offsets: wrong magic number for module 
>>> package:  expected 0xf97cff8f, got 0x70797428
>>> libsemanage.parse_module_headers: Could not parse module data.
>>> semodule:  Failed on myport.cil!
>>>
>>> ===
>>>
>>> Am running this on CentOS 6.8
>>>
>>>
>>
>> Yes, only works with selinux user space >=2.4
>>
>> No, I am not aware of any other way's on older selinux systems
>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 24 August 2016 16:21
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>>>> Hi Dominick,
>>>>
>>>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>>>
>>>
>>> This seems to work here:
>>>
>>> cat >myport.cil<<EOF
>>> (type myport)
>>> (roletype object_r myport)
>>> (typeattributeset port_type myport)
>>> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
>>>
>>> sudo semodule -i myport.cil
>>>
>>> seinfo --portcon | grep myport
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 19 August 2016 18:23
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>>>> Ok - what would be a use case for the java_role_template?
>>>>
>>>> Not quite sure ... but role_templates are generally for user 
>>>> applications and not for system services
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 19 August 2016 16:53
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>>>
>>>>>>
>>>>>
>>>>> The transition happens on the shell script, and the domain 
>>>>> associated with the shell script process should then be allowed to 
>>>>> execute java
>>>>>
>>>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>>>> script)
>>>>>
>>>>> java_exec(myapp_t)
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 19 August 2016 14:14
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>>>> Hi Dominick,
>>>>>>>
>>>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>>>
>>>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>>>
>>>>>> I do not think that template was meant for that, but if it works if works.
>>>>>>
>>>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Fakim, Walid
>>>>>>> Sent: 16 August 2016 15:32
>>>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> I'll take a look - thank you.
>>>>>>>
>>>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 16 August 2016 15:23
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>>>> Hi Dominick,
>>>>>>>>>
>>>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>>>> system_u:system_r:service_domain_t
>>>>>>>>
>>>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The way confined admins commonly work is:
>>>>>>>
>>>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>>>
>>>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>>>> /
>>>>>>> p
>>>>>>> o
>>>>>>> l
>>>>>>> icy/modules/roles/logadm.te
>>>>>>>
>>>>>>> although i would not use the userdom_confined_admin_template 
>>>>>>> because i would not want to allow privileged logins. Instead i 
>>>>>>> would use the base_user_template for the role and require the user 
>>>>>>> to log into the system with the unprivileged staff_r and then 
>>>>>>> change to the privileged role with sudo manually
>>>>>>>
>>>>>>>>
>>>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>>>> You would create a new selinux user id (for example 
>>>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>>>
>>>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>>>> via sudo
>>>>>>>> example: jboss_tomcat_adm_r
>>>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>>>
>>>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>>>
>>>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>>>
>>>>>>>> 5. now the user has context:
>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>
>>>>>>>> + is associated with root
>>>>>>>>
>>>>>>>> 6. this allows root associated with 
>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>
>>>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>>>> service jboss_tomcat start
>>>>>>>>
>>>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>>>
>>>>>>>> thus the service ends up with:
>>>>>>>>
>>>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>>>
>>>>>>>> if it is started manually via the init script by the admin and 
>>>>>>>> with
>>>>>>>>
>>>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>>>
>>>>>>>> if it is started by the system user
>>>>>>>>
>>>>>>>> I hope that clears at least some of this up
>>>>>>>>
>>>>>>>>
>>>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>> Walid
>>>>>>>>> Sent: 15 August 2016 16:30
>>>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Walid Fakim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>> Sent: 15 August 2016 16:24
>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>
>>>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>>>> s
>>>>>>>>>> h
>>>>>>>>>>
>>>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>>>
>>>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>>>
>>>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>>>
>>>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>>>> manage the
>>>>>>>>> apache-tomcat)
>>>>>>>>>
>>>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>>>
>>>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>>>
>>>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>>>
>>>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>>>
>>>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>>>
>>>>>>>>>> ====
>>>>>>>>>>
>>>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>>>
>>>>>>>>>> Does that give you enough to go by?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>>>
>>>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>>>
>>>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>>>> SELinux user and role to confine my application
>>>>>>>>>>
>>>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>>>> the system or is it just a system user to run the application
>>>>>>>>>> with?)
>>>>>>>>>>
>>>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>>>
>>>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>>>
>>>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>>>
>>>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>>>
>>>>>>>>>> Are the above two assumptions right?
>>>>>>>>>>
>>>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>>>
>>>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>>>
>>>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>>>
>>>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>>>> different
>>>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>>>> an init daemon process
>>>>>>>>>>>
>>>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>>>
>>>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>>>> isnt
>>>>>>>>>>> broken)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>>>
>>>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>>>> improvements?)
>>>>>>>>>>>>
>>>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>>>> achieved)
>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>>>> rules inserted
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>>>
>>>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>>>> bad
>>>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ========
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>>>> #
>>>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>>>> tomcat #
>>>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>>>> export PATH
>>>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>>>> case $1 in
>>>>>>>>>>>>>> start)
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>> stop)
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>> restart)
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>> esac
>>>>>>>>>>>>>> exit 0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ===============
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C7
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>>> F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7B
>>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B6
>>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 6B
>>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 6
>>>>>>>>>>> B0
>>>>>>>>>>> 2
>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>>> 6B02
>>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 6
>>>>>>>>>> B
>>>>>>>>>> 02
>>>>>>>>>> Dominick Grift
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>> 6B02
>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>>> 7
>>>>>>>>> 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
>>
> 
> 


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

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

[Dominick Grift]

On 09/02/2016 01:43 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Just to clarify (for my own understanding):
> 
> ---
> 
> Unconfined domain syslog_t could interact with confined process domain myapp_t  and resources of type myapp_log_t as long as this is explicitly allowed in myapp policy. 
> 
> But it wouldn't be allowed by default.
> 
> Is that correct?
> 

I think there is some miscommunication, as i tried to explain that it
does n't have to be "explicitly" allowed. Instead it, if you write
proper refpolicy, it will automatically "implicitly" be allowed. Also
syslog_t is not unconfined.

You should just try it out. Experience is the best lesson.

> ---
> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 01 September 2016 14:35
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 09/01/2016 03:26 PM, Fakim, Walid wrote:
>> To go a bit further, imagine the following scenario :
>>
>> rsyslogd running unconfined needs to send some logs to a remote log collector. The "/var/log/myapp_log" files have a custom type my_app_log_t which is defined and used as part of the myapp policy.
>>
>> By default, will rsyslogd have access to those files? My guess would be not unless defined somewhere in the policy? Or would we have to also confine rsyslogd and define some allow rules between rsyslogd and myapp to make this happen?
>>
> 
> Yes it will have access, provided that the policy is written properly.
> 
> here is how that works:
> 
> there is a type attribute called file_type, and this type attribute
> should be associated with all file types.
> 
> so if you create for example:
> 
> type mylogfile_t;
> logging_log_file(mylogfile_t)
> 
> then the logging_log_file macro will associate the mylogfile_t type with
> the file_type type attribute automatically.
> 
> The same goes for example for unconfined processes
> 
> there is a type attribute that is associated with unconfined processes
> via unconfined_domain()
> 
> so on a higher level there is a rule that uses type attributes to catch
> it all, for example:
> 
> allow unconfined_domain_type file_type:file *;
> 
> So since the mylogfile_t type is associated with file_type via
> logging_log_file(), and since myprocesstype_t is associated with
> unconfined_domain_type via unconfined_domain() it is automatically allowed.
> 
> So as long as the policy is written properly, it should just work.
> 
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com] 
>> Sent: 31 August 2016 17:37
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/31/2016 04:50 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> 2 questions from a conceptual level:
>>>
>>> 1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?
>>>
>>
>> No, system users aren't login users (they dont login via login programs
>> such as sshd, gdm etc)
>>
>>> 2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?
>>
>> processes that are "unconfined" should be able to interact with and
>> confined processes by default.
>>
>> Confined processes aren't able to interact with unconfined processes.
>>
>> So for example your unconfined process is by default allowed to send
>> messages via dbus to confined processes, but confined processes are not
>> allowed to reply to unconfined processes.
>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com] 
>>> Sent: 24 August 2016 16:43
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/24/2016 05:40 PM, Fakim, Walid wrote:
>>>> Unfortunately am getting this error :
>>>>
>>>> [root at server2 protocode]# semodule -i myport.cil
>>>> libsepol.module_package_read_offsets: wrong magic number for module 
>>>> package:  expected 0xf97cff8f, got 0x70797428
>>>> libsemanage.parse_module_headers: Could not parse module data.
>>>> semodule:  Failed on myport.cil!
>>>>
>>>> ===
>>>>
>>>> Am running this on CentOS 6.8
>>>>
>>>>
>>>
>>> Yes, only works with selinux user space >=2.4
>>>
>>> No, I am not aware of any other way's on older selinux systems
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 24 August 2016 16:21
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>>>>> Hi Dominick,
>>>>>
>>>>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>>>>
>>>>
>>>> This seems to work here:
>>>>
>>>> cat >myport.cil<<EOF
>>>> (type myport)
>>>> (roletype object_r myport)
>>>> (typeattributeset port_type myport)
>>>> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
>>>>
>>>> sudo semodule -i myport.cil
>>>>
>>>> seinfo --portcon | grep myport
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 19 August 2016 18:23
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>>>>> Ok - what would be a use case for the java_role_template?
>>>>>
>>>>> Not quite sure ... but role_templates are generally for user 
>>>>> applications and not for system services
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 19 August 2016 16:53
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The transition happens on the shell script, and the domain 
>>>>>> associated with the shell script process should then be allowed to 
>>>>>> execute java
>>>>>>
>>>>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>>>>> script)
>>>>>>
>>>>>> java_exec(myapp_t)
>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 19 August 2016 14:14
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>>>>> Hi Dominick,
>>>>>>>>
>>>>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>>>>
>>>>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>>>>
>>>>>>> I do not think that template was meant for that, but if it works if works.
>>>>>>>
>>>>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Fakim, Walid
>>>>>>>> Sent: 16 August 2016 15:32
>>>>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> I'll take a look - thank you.
>>>>>>>>
>>>>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 16 August 2016 15:23
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>>>>> Hi Dominick,
>>>>>>>>>>
>>>>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>>>>> system_u:system_r:service_domain_t
>>>>>>>>>
>>>>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The way confined admins commonly work is:
>>>>>>>>
>>>>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>>>>
>>>>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>>>>> /
>>>>>>>> p
>>>>>>>> o
>>>>>>>> l
>>>>>>>> icy/modules/roles/logadm.te
>>>>>>>>
>>>>>>>> although i would not use the userdom_confined_admin_template 
>>>>>>>> because i would not want to allow privileged logins. Instead i 
>>>>>>>> would use the base_user_template for the role and require the user 
>>>>>>>> to log into the system with the unprivileged staff_r and then 
>>>>>>>> change to the privileged role with sudo manually
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>>>>> You would create a new selinux user id (for example 
>>>>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>>>>
>>>>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>>>>> via sudo
>>>>>>>>> example: jboss_tomcat_adm_r
>>>>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>>>>
>>>>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>>>>
>>>>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>>>>
>>>>>>>>> 5. now the user has context:
>>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>>
>>>>>>>>> + is associated with root
>>>>>>>>>
>>>>>>>>> 6. this allows root associated with 
>>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>>
>>>>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>>>>> service jboss_tomcat start
>>>>>>>>>
>>>>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>>>>
>>>>>>>>> thus the service ends up with:
>>>>>>>>>
>>>>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>>>>
>>>>>>>>> if it is started manually via the init script by the admin and 
>>>>>>>>> with
>>>>>>>>>
>>>>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>>>>
>>>>>>>>> if it is started by the system user
>>>>>>>>>
>>>>>>>>> I hope that clears at least some of this up
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>>> Walid
>>>>>>>>>> Sent: 15 August 2016 16:30
>>>>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 16:24
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>>>>> s
>>>>>>>>>>> h
>>>>>>>>>>>
>>>>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>>>>
>>>>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>>>>
>>>>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>>>>
>>>>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>>>>> manage the
>>>>>>>>>> apache-tomcat)
>>>>>>>>>>
>>>>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>>>>
>>>>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>>>>
>>>>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>>>>
>>>>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>>>>
>>>>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>>>>
>>>>>>>>>>> ====
>>>>>>>>>>>
>>>>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>>>>
>>>>>>>>>>> Does that give you enough to go by?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>>>>
>>>>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>>>>
>>>>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>>>>> SELinux user and role to confine my application
>>>>>>>>>>>
>>>>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>>>>> the system or is it just a system user to run the application
>>>>>>>>>>> with?)
>>>>>>>>>>>
>>>>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>>>>
>>>>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>>>>
>>>>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>>>>
>>>>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>>>>
>>>>>>>>>>> Are the above two assumptions right?
>>>>>>>>>>>
>>>>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>>>>
>>>>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>>>>
>>>>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>>>>
>>>>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>>>>> different
>>>>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>>>>> an init daemon process
>>>>>>>>>>>>
>>>>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>>>>
>>>>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>>>>> isnt
>>>>>>>>>>>> broken)
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>>>>
>>>>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>>>>> improvements?)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>>>>> achieved)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>>>>> rules inserted
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>>>>> bad
>>>>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>>>>> tomcat #
>>>>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>>>>> export PATH
>>>>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>>>>> case $1 in
>>>>>>>>>>>>>>> start)
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>>> stop)
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>>> restart)
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>>> esac
>>>>>>>>>>>>>>> exit 0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ===============
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7B
>>>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B6
>>>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 6B
>>>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 6
>>>>>>>>>>>> B0
>>>>>>>>>>>> 2
>>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>>>> 6B02
>>>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 6
>>>>>>>>>>> B
>>>>>>>>>>> 02
>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>>> 6B02
>>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>>>> 7
>>>>>>>>>> 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
>>>
>>
>>
> 
> 


-- 
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/20160902/3a2c3f34/attachment-0001.bin 

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

[Fakim, Walid]

Will do - I'll be back with some more questions am sure ;) . Have a good weekend!


Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 02 September 2016 15:14
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 09/02/2016 01:43 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Just to clarify (for my own understanding):
> 
> ---
> 
> Unconfined domain syslog_t could interact with confined process domain myapp_t  and resources of type myapp_log_t as long as this is explicitly allowed in myapp policy. 
> 
> But it wouldn't be allowed by default.
> 
> Is that correct?
> 

I think there is some miscommunication, as i tried to explain that it
does n't have to be "explicitly" allowed. Instead it, if you write
proper refpolicy, it will automatically "implicitly" be allowed. Also
syslog_t is not unconfined.

You should just try it out. Experience is the best lesson.

> ---
> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com] 
> Sent: 01 September 2016 14:35
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 09/01/2016 03:26 PM, Fakim, Walid wrote:
>> To go a bit further, imagine the following scenario :
>>
>> rsyslogd running unconfined needs to send some logs to a remote log collector. The "/var/log/myapp_log" files have a custom type my_app_log_t which is defined and used as part of the myapp policy.
>>
>> By default, will rsyslogd have access to those files? My guess would be not unless defined somewhere in the policy? Or would we have to also confine rsyslogd and define some allow rules between rsyslogd and myapp to make this happen?
>>
> 
> Yes it will have access, provided that the policy is written properly.
> 
> here is how that works:
> 
> there is a type attribute called file_type, and this type attribute
> should be associated with all file types.
> 
> so if you create for example:
> 
> type mylogfile_t;
> logging_log_file(mylogfile_t)
> 
> then the logging_log_file macro will associate the mylogfile_t type with
> the file_type type attribute automatically.
> 
> The same goes for example for unconfined processes
> 
> there is a type attribute that is associated with unconfined processes
> via unconfined_domain()
> 
> so on a higher level there is a rule that uses type attributes to catch
> it all, for example:
> 
> allow unconfined_domain_type file_type:file *;
> 
> So since the mylogfile_t type is associated with file_type via
> logging_log_file(), and since myprocesstype_t is associated with
> unconfined_domain_type via unconfined_domain() it is automatically allowed.
> 
> So as long as the policy is written properly, it should just work.
> 
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com] 
>> Sent: 31 August 2016 17:37
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/31/2016 04:50 PM, Fakim, Walid wrote:
>>> Hi Dominick,
>>>
>>> 2 questions from a conceptual level:
>>>
>>> 1) If a process runs as a daemon/service under a system user (e.g. tomcat), does this user need to be confined as well? If so, does it need to be mapped to an SELinux login user via semanage login even though this may not be a login user?
>>>
>>
>> No, system users aren't login users (they dont login via login programs
>> such as sshd, gdm etc)
>>
>>> 2) Assuming the tomcat process is running confined and that we have another security agent process running unconfined, will the security agent process be able to interact and explore the tomcat process and files unless explicitly allowed via rule definitions in a policy?
>>
>> processes that are "unconfined" should be able to interact with and
>> confined processes by default.
>>
>> Confined processes aren't able to interact with unconfined processes.
>>
>> So for example your unconfined process is by default allowed to send
>> messages via dbus to confined processes, but confined processes are not
>> allowed to reply to unconfined processes.
>>
>>>
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com] 
>>> Sent: 24 August 2016 16:43
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/24/2016 05:40 PM, Fakim, Walid wrote:
>>>> Unfortunately am getting this error :
>>>>
>>>> [root at server2 protocode]# semodule -i myport.cil
>>>> libsepol.module_package_read_offsets: wrong magic number for module 
>>>> package:  expected 0xf97cff8f, got 0x70797428
>>>> libsemanage.parse_module_headers: Could not parse module data.
>>>> semodule:  Failed on myport.cil!
>>>>
>>>> ===
>>>>
>>>> Am running this on CentOS 6.8
>>>>
>>>>
>>>
>>> Yes, only works with selinux user space >=2.4
>>>
>>> No, I am not aware of any other way's on older selinux systems
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 24 August 2016 16:21
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/24/2016 04:16 PM, Fakim, Walid wrote:
>>>>> Hi Dominick,
>>>>>
>>>>> Is there a way to programmatically via a module create a port_type domain with reference to specific port numbers, e.g. a combination of tcp 80,443,9000 etc? By that mean I some way other than by using semanage --portcon?
>>>>>
>>>>
>>>> This seems to work here:
>>>>
>>>> cat >myport.cil<<EOF
>>>> (type myport)
>>>> (roletype object_r myport)
>>>> (typeattributeset port_type myport)
>>>> (portcon "tcp" 12345 (system_u object_r myport ((s0) (s0)))) EOF
>>>>
>>>> sudo semodule -i myport.cil
>>>>
>>>> seinfo --portcon | grep myport
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 19 August 2016 18:23
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/19/2016 07:21 PM, Fakim, Walid wrote:
>>>>>> Ok - what would be a use case for the java_role_template?
>>>>>
>>>>> Not quite sure ... but role_templates are generally for user 
>>>>> applications and not for system services
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>> Sent: 19 August 2016 16:53
>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> On 08/19/2016 03:54 PM, Fakim, Walid wrote:
>>>>>>> The init script launches a shell script which further down calls java - so will init_daemon_domain suffice? It's similar to a tomcat startup script.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The transition happens on the shell script, and the domain 
>>>>>> associated with the shell script process should then be allowed to 
>>>>>> execute java
>>>>>>
>>>>>> init_t (init) -> initrc_t (init script) -> myapp_t (java app shell
>>>>>> script)
>>>>>>
>>>>>> java_exec(myapp_t)
>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Walid Fakim
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>> Sent: 19 August 2016 14:14
>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>
>>>>>>> On 08/19/2016 02:02 PM, Fakim, Walid wrote:
>>>>>>>> Hi Dominick,
>>>>>>>>
>>>>>>>> Is java_role_template the right interface to use for applications running java where we would want to create a new java domain?
>>>>>>>>
>>>>>>>> e.g. My application runs on java and I wanted to give the new domain jboss_t all the permissions to access all java resources so I've used java_role_template.
>>>>>>>
>>>>>>> I do not think that template was meant for that, but if it works if works.
>>>>>>>
>>>>>>> I would, probably, just create an init_daemon_domain() for my jboss application service instead using that template.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Fakim, Walid
>>>>>>>> Sent: 16 August 2016 15:32
>>>>>>>> To: 'Dominick Grift'; refpolicy at oss.tresys.com
>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> I'll take a look - thank you.
>>>>>>>>
>>>>>>>> That gives me some good guidance in where I should be focusing my efforts - much appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Walid Fakim
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>> Sent: 16 August 2016 15:23
>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>
>>>>>>>> On 08/16/2016 03:50 PM, Dominick Grift wrote:
>>>>>>>>> On 08/16/2016 03:36 PM, Fakim, Walid wrote:
>>>>>>>>>> Hi Dominick,
>>>>>>>>>>
>>>>>>>>>> Quick question : From your comments, am understanding that for a 
>>>>>>>>>> service to run, it always makes sense to run that service as 
>>>>>>>>>> system_u:system_r:service_domain_t
>>>>>>>>>
>>>>>>>>> Atleast system_r:service_domain_t, if this is started by the system.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The way confined admins commonly work is:
>>>>>>>>
>>>>>>>> Here is a RedHat example of how such an adm role could look:
>>>>>>>>
>>>>>>>> https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base
>>>>>>>> /
>>>>>>>> p
>>>>>>>> o
>>>>>>>> l
>>>>>>>> icy/modules/roles/logadm.te
>>>>>>>>
>>>>>>>> although i would not use the userdom_confined_admin_template 
>>>>>>>> because i would not want to allow privileged logins. Instead i 
>>>>>>>> would use the base_user_template for the role and require the user 
>>>>>>>> to log into the system with the unprivileged staff_r and then 
>>>>>>>> change to the privileged role with sudo manually
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. the existing staff_r role is used to allow the admin to login.
>>>>>>>>> You would create a new selinux user id (for example 
>>>>>>>>> jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.
>>>>>>>>>
>>>>>>>>> 2. then you would create a admin role. This role can be access 
>>>>>>>>> via sudo
>>>>>>>>> example: jboss_tomcat_adm_r
>>>>>>>>> that role is then also associated to the jboss_tomcat_adm_u 
>>>>>>>>> selinux id, so theres now 3 roles associated with 
>>>>>>>>> jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)
>>>>>>>>>
>>>>>>>>> 3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t
>>>>>>>>>
>>>>>>>>> 4. the user can now use sudo to change to his privileged 
>>>>>>>>> jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s
>>>>>>>>>
>>>>>>>>> 5. now the user has context:
>>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>>
>>>>>>>>> + is associated with root
>>>>>>>>>
>>>>>>>>> 6. this allows root associated with 
>>>>>>>>> jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t
>>>>>>>>>
>>>>>>>>> to manage the system service: example: sudo -r jboss_tomcat_adm_r 
>>>>>>>>> service jboss_tomcat start
>>>>>>>>>
>>>>>>>>> Then there is a rule that tells selinux when a process associated 
>>>>>>>>> with role jboss_tomcat_adm_r executes an init script file with 
>>>>>>>>> type jboss_tomcat_initrc_exec_t, then automatically role 
>>>>>>>>> transition from jboss_tomcat_adm_r to system_r
>>>>>>>>>
>>>>>>>>> thus the service ends up with:
>>>>>>>>>
>>>>>>>>> jboss_tomcat_adm_u:system_r:jboss_tomcat_t
>>>>>>>>>
>>>>>>>>> if it is started manually via the init script by the admin and 
>>>>>>>>> with
>>>>>>>>>
>>>>>>>>> system_u:system_r:jboss_tomcat_t
>>>>>>>>>
>>>>>>>>> if it is started by the system user
>>>>>>>>>
>>>>>>>>> I hope that clears at least some of this up
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>>>>>> Walid
>>>>>>>>>> Sent: 15 August 2016 16:30
>>>>>>>>>> To: Dominick Grift; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> Sounds good Dominick - Thanks for the help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Walid Fakim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>> Sent: 15 August 2016 16:24
>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>
>>>>>>>>>> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>>>>>>>>>>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/ba
>>>>>>>>>>> s
>>>>>>>>>>> h
>>>>>>>>>>>
>>>>>>>>>>> Your assumptions 1 and 2 are correct.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
>>>>>>>>>>
>>>>>>>>>>> I also see your points about using system_u and system_r. 
>>>>>>>>>>>
>>>>>>>>>>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
>>>>>>>>>>
>>>>>>>>>> Ok so you want a confined administrator (a user that can only 
>>>>>>>>>> manage the
>>>>>>>>>> apache-tomcat)
>>>>>>>>>>
>>>>>>>>>> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
>>>>>>>>>>
>>>>>>>>>> Once that is done we can look at creating the confined admin.
>>>>>>>>>>
>>>>>>>>>> Because your current module is a little unwieldy. I cannot make sense of all of it.
>>>>>>>>>>
>>>>>>>>>> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
>>>>>>>>>>
>>>>>>>>>> But first things first: deal with the service in the simplest possible way.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>>>>>>>>>>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>>>>>>>>>>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>>>>>>>>>>
>>>>>>>>>>> ====
>>>>>>>>>>>
>>>>>>>>>>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>>>>>>>>>>
>>>>>>>>>>> Does that give you enough to go by?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>> Sent: 15 August 2016 15:55
>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>
>>>>>>>>>>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>>>>>>>>>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>>>>>>>>>>
>>>>>>>>>>> I am saying that, in my view and with the information i have to 
>>>>>>>>>>> my disposal, there is no to create additional "_u"'s and "_r"'s
>>>>>>>>>>>
>>>>>>>>>>>  How can I link my linux user say jbosslinuxuser to the correct 
>>>>>>>>>>> SELinux user and role to confine my application
>>>>>>>>>>>
>>>>>>>>>>> I would need more infomation about the nature of this user. Is 
>>>>>>>>>>> this user a login user or a system user (can the user log into 
>>>>>>>>>>> the system or is it just a system user to run the application
>>>>>>>>>>> with?)
>>>>>>>>>>>
>>>>>>>>>>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>>>>>>>>>>
>>>>>>>>>>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>>>>>>>>>>
>>>>>>>>>>> I think i see where you might be going with this but I am not sure.
>>>>>>>>>>>
>>>>>>>>>>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>>>>>>>>>>
>>>>>>>>>>> Are the above two assumptions right?
>>>>>>>>>>>
>>>>>>>>>>> what does: grep jbosslinuxuser /etc/passwd return?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>> Sent: 15 August 2016 15:13
>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>>>>>>>>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>>>>>>>>>>
>>>>>>>>>>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>>>>>>>>>>
>>>>>>>>>>>> Why does that user need to be a login user? Isnt that just a system user?
>>>>>>>>>>>>
>>>>>>>>>>>> Basically now you have a jboss_t type that has at least 3 
>>>>>>>>>>>> different
>>>>>>>>>>>> uses: 1. a login shell process, 2. an application process 3. 
>>>>>>>>>>>> an init daemon process
>>>>>>>>>>>>
>>>>>>>>>>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>>>>>>>>>>
>>>>>>>>>>>> But again, if it works for you then it works (dont fix what 
>>>>>>>>>>>> isnt
>>>>>>>>>>>> broken)
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>>>>>>>>>>> Nice one - thanks I'll give that a shot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>>>>>>>>>>
>>>>>>>>>>>>> However I do not know your requirements, environment, and 
>>>>>>>>>>>>> properties so I can't really suggest alternative approaches, improvements.
>>>>>>>>>>>>> (maybe someone else on this list wants to suggest
>>>>>>>>>>>>> improvements?)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If it works it works (and with work i mean not just if it 
>>>>>>>>>>>>> runs but also if your security goals are verified to be 
>>>>>>>>>>>>> achieved)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>>>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>>>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>>>>>>>>>>> Hi Dominick & All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You would do what you alway's do in such situations:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>>>>>>>>>>> rules inserted
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. reproduce the issues
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. look again for avc denials that may be related
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>>>>>>>>>>> rules re-inserted
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>>>>>>>>>>> bad
>>>>>>>>>>>>>>> interpreter: Permission denied
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> =====
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>>>>>>>>>>> service (I called this apache-tomcat as I also have the 
>>>>>>>>>>>>>>> packaged tomcat version running installed via yum to 
>>>>>>>>>>>>>>> compare parameters when they are running etc)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash 
>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>> description: Tomcat Start Stop Restart # processname: 
>>>>>>>>>>>>>>> tomcat #
>>>>>>>>>>>>>>> chkconfig: 234 20 80
>>>>>>>>>>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>>>>>>>>>>> export JAVA_HOME
>>>>>>>>>>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>>>>>>>>>>> export PATH
>>>>>>>>>>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>>>>>>>>>>> export CATALINA_HOME
>>>>>>>>>>>>>>> case $1 in
>>>>>>>>>>>>>>> start)
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>>> stop)
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>>> restart)
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>>>>>>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>>>>>>>>>>> ;;
>>>>>>>>>>>>>>> esac
>>>>>>>>>>>>>>> exit 0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ==========
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>>>>>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>>>>>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ===============
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>>>>>>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of 
>>>>>>>>>>>>>>> Fakim, Walid
>>>>>>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift; 
>>>>>>>>>>>>>>> refpolicy at oss.tresys.com
>>>>>>>>>>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Morning Dominick,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Walid Fakim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Borg-Cardona, Jack
>>>>>>>>>>>>>>> Sent: 03 August 2016 09:25
>>>>>>>>>>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>>>>>>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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<<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=0
>>>>>>>>>>>>>>>>>>>>> x
>>>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>>> 5F
>>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>>>> 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=0x
>>>>>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>>>> F1
>>>>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>> 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=0x3
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>>>> 1D
>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>> 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=0x3B
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>> D2
>>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> 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=0x3B6
>>>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>>> 2C
>>>>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>> 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=0x3B6C
>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>> C7
>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>> 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=0x3B6C5
>>>>>>>>>>>>>>> F
>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> D
>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>> C
>>>>>>>>>>>>>>> 7B
>>>>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> D
>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> C
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> B6
>>>>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>>>>> D
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> C
>>>>>>>>>>>>> 7
>>>>>>>>>>>>> B
>>>>>>>>>>>>> 6B
>>>>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> B
>>>>>>>>>>>> 6
>>>>>>>>>>>> B0
>>>>>>>>>>>> 2
>>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>>>> 6B02
>>>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 6
>>>>>>>>>>> B
>>>>>>>>>>> 02
>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
>>>>>>>>>> 6B02
>>>>>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C
>>>>>>>>>> 7
>>>>>>>>>> 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
>>>
>>
>>
> 
> 


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

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

[Fakim, Walid]

That clears it up pretty well - many thanks Dominick.



Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 16 August 2016 14:50
To: Fakim, Walid; refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

On 08/16/2016 03:36 PM, Fakim, Walid wrote:
> Hi Dominick,
> 
> Quick question : From your comments, am understanding that for a 
> service to run, it always makes sense to run that service as 
> system_u:system_r:service_domain_t

Atleast system_r:service_domain_t, if this is started by the system.

> 
> What needs to be done properly rather, is that the contexts are set up correctly to allow a linux user (e.g. jboss_tomcat) to administer this confined application via the right SELinux user and role mappings. Obviously, the right permissions to map everything together from user, to role to domain needs to be accounted for to allow seamless transitions where required and for the service to run smoothly.
> 

The way confined admins commonly work is:

1. the existing staff_r role is used to allow the admin to login.
You would create a new selinux user id (for example jboss_tomcat_adm_u), then associate the staff_r role and system_r role with that user id.

2. then you would create a admin role. This role can be access via sudo
example: jboss_tomcat_adm_r
that role is then also associated to the jboss_tomcat_adm_u selinux id, so theres now 3 roles associated with jboss_tomcat_adm_u (staff_r system_r and jboss_tomcat_r)

3. The user logs in with jboss_tomcat_adm_u:staff_r:staff_t

4. the user can now use sudo to change to his privileged jboss_tomcat_adm ruleset: sudo -r jboss_tomcat_adm_r -s

5. now the user has context:
jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t

+ is associated with root

6. this allows root associated with
jboss_tomcat_adm_u:jboss_tomcat_adm_r:jboss_tomcat_adm_t

to manage the system service: example: sudo -r jboss_tomcat_adm_r service jboss_tomcat start

Then there is a rule that tells selinux when a process associated with role jboss_tomcat_adm_r executes an init script file with type jboss_tomcat_initrc_exec_t, then automatically role transition from jboss_tomcat_adm_r to system_r

thus the service ends up with:

jboss_tomcat_adm_u:system_r:jboss_tomcat_t

if it is started manually via the init script by the admin and with

system_u:system_r:jboss_tomcat_t

if it is started by the system user

I hope that clears at least some of this up


> It may be an oversimplification, but is that the gist of it? Unfortunately, I cannot give too much away but am trying to be as clear as I can from my own limited knowledge and understanding. I am using tomcat here mostly as a testbed that I can play with to further my understanding as on a high level it is doing something similar (application running java and requiring other 'interfaces' such as networking etc) to what we need in our production environment.
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com 
> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
> Sent: 15 August 2016 16:30
> To: Dominick Grift; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> Sounds good Dominick - Thanks for the help.
> 
> 
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:dac.override at gmail.com]
> Sent: 15 August 2016 16:24
> To: Fakim, Walid; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
> 
> On 08/15/2016 05:12 PM, Fakim, Walid wrote:
>> jboss_tomcat:x:503:503::/opt/jboss/apache-tomcat-6.0.45:/bin/bash
>>
>> Your assumptions 1 and 2 are correct.
>>
> 
> Then why is user jboss_tomcat associated with a shell? associate it with /sbin/nologin instead because this "system user" is not supposed to have a login shell.
> 
>> I also see your points about using system_u and system_r. 
>>
>> The user is actually called jboss_tomcat. Currently I have the SElinux user jbossman and role jboss_r but the linux user is not yet 'linked' to any SElinux user and role.
> 
> Ok so you want a confined administrator (a user that can only manage 
> the
> apache-tomcat)
> 
> For now i would advice that you wait with the confined admin. First just create the policy for your system service and make sure that works.
> 
> Once that is done we can look at creating the confined admin.
> 
> Because your current module is a little unwieldy. I cannot make sense of all of it.
> 
> So if you remove all the noise from the module and stick with the basic service , then i can hopefully make more sense of it and review that and when that looks solid we can look at adding the confined admin user. I will help you with that then if you want.
> 
> But first things first: deal with the service in the simplest possible way.
> 
>>
>> [root at server2 staff]# semanage user -l | egrep 'SELinux|jboss'
>> SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
>> jbossman        user       s0         s0-s0:c0.c1023                 jboss_r
>>
>> ====
>>
>> jboss_tomcat is supposed to be an unprivileged user who can only start/stop the apache-tomcat service and perform some application-related maintenance.
>>
>> Does that give you enough to go by?
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Walid Fakim
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:dac.override at gmail.com]
>> Sent: 15 August 2016 15:55
>> To: Fakim, Walid; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>
>> On 08/15/2016 04:35 PM, Fakim, Walid wrote:
>>> OK - If I understood you correctly, you're saying the generic system_u user and system_r role do the job of what I need.
>>
>> I am saying that, in my view and with the information i have to my 
>> disposal, there is no to create additional "_u"'s and "_r"'s
>>
>>  How can I link my linux user say jbosslinuxuser to the correct 
>> SELinux user and role to confine my application
>>
>> I would need more infomation about the nature of this user. Is this 
>> user a login user or a system user (can the user log into the system 
>> or is it just a system user to run the application with?)
>>
>> If this is a real login user, then what context is associated with that user currently. and what privileges is this user supposed to have.
>>
>>  but at the same time not give jbosslinuxuser full system privileges via system_u and system_r?
>>
>> I think i see where you might be going with this but I am not sure.
>>
>> 1. your jboss application is a system service (init daemon) 2. your jboss application does not run as root but instead it runs with the jbosslinuxuser identity.
>>
>> Are the above two assumptions right?
>>
>> what does: grep jbosslinuxuser /etc/passwd return?
>>
>>>
>>> I may be convoluting the whole thing more than is necessary but that's my current understanding and dilemma.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>>
>>> Walid Fakim
>>>
>>>
>>> -----Original Message-----
>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>> Sent: 15 August 2016 15:13
>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>
>>> On 08/15/2016 04:07 PM, Fakim, Walid wrote:
>>>> Thanks Dominick - The .te file is strange in what way? It seems to be doing the job at the moment although I do plan to streamline it further it's fully working as expected. Is it strange in that the policies look more like interface definitions? We haven't quite decided whether to go down the proper route of having interfaces that we can call or whether to have everything directly in the .te file (we understand it may not be the best approach but we have to work with what resources and time we have).
>>>>
>>>> To give you an overview, we are trying to confine a java application (I used tomcat as an example since it uses java as well) that will interact with a few other interfaces and needs some level of network access. We also want that application to run as a non-privileged user that can be used for startup but also stop and restart the service as and when needed without a reboot.
>>>
>>> Why does that user need to be a login user? Isnt that just a system user?
>>>
>>> Basically now you have a jboss_t type that has at least 3 different
>>> uses: 1. a login shell process, 2. an application process 3. an init 
>>> daemon process
>>>
>>> I suspect you dont need that login user stuff, and you dont need the jboss_r role. Basically i suspect that you dont need a lot of what you have there.
>>>
>>> But again, if it works for you then it works (dont fix what isnt
>>> broken)
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Walid Fakim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>> Sent: 15 August 2016 14:44
>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>
>>>> On 08/15/2016 03:32 PM, Fakim, Walid wrote:
>>>>> Nice one - thanks I'll give that a shot.
>>>>>
>>>>> Otherwise, are there some obvious gotchas (or DOs and DON'Ts) when trying to start up a service as a non-priv user like tomcat does for example?
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> Not that I am aware of but i just took a quick look at your .te file and it looks strange to me (to say the least).
>>>>
>>>> However I do not know your requirements, environment, and 
>>>> properties so I can't really suggest alternative approaches, improvements.
>>>> (maybe someone else on this list wants to suggest improvements?)
>>>>
>>>> If it works it works (and with work i mean not just if it runs but 
>>>> also if your security goals are verified to be achieved)
>>>>
>>>>> Best Regards,
>>>>>
>>>>> Walid Fakim
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dominick Grift [mailto:dac.override at gmail.com]
>>>>> Sent: 15 August 2016 14:22
>>>>> To: Fakim, Walid; refpolicy at oss.tresys.com
>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>
>>>>> On 08/15/2016 03:15 PM, Fakim, Walid wrote:
>>>>>> Hi Dominick & All,
>>>>>>
>>>>>> Since our last exchange, we've done quite a bit of overhaul work to get our policy working. As a POC policy module, I used a basic tomcat service as a 'reference/template' service to confine and modelled our policy module on the RHEL Centos tomcat policy.
>>>>>>
>>>>>> It all seems to work nicely in permissive mode up  to the point where there are no more denied messages in the audit log. However, when I switch to enforcing mode, the service fails to start up at boot with the following error:
>>>>>>
>>>>>
>>>>> You would do what you alway's do in such situations:
>>>>>
>>>>> 1. run semodule -DB to build/load the policy without the "dontaudit"
>>>>> rules inserted
>>>>>
>>>>> 2. reproduce the issues
>>>>>
>>>>> 3. look again for avc denials that may be related
>>>>>
>>>>> 4. run semodule -B to build/load the policy with the "dontaudit" 
>>>>> rules re-inserted
>>>>>
>>>>> When you have some avc denials that look related, you start by processing them all. Then see if the issue is fixed. Then after you confirmed that the issue is fixed. You comment individual rules one by one until you have identified which rules are needed and which rules are not needed.
>>>>>
>>>>>> =====
>>>>>>
>>>>>> -sh: /opt/jboss/apache-tomcat-6.0.45/bin/catalina.sh: /bin/sh: 
>>>>>> bad
>>>>>> interpreter: Permission denied
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> Here is the init script that we run to start up the "apache-tomcat" 
>>>>>> service (I called this apache-tomcat as I also have the packaged 
>>>>>> tomcat version running installed via yum to compare parameters 
>>>>>> when they are running etc)
>>>>>>
>>>>>> ========
>>>>>>
>>>>>> [root at server2 ~]# cat /etc/init.d/apache-tomcat #!/bin/bash #
>>>>>> description: Tomcat Start Stop Restart # processname: tomcat #
>>>>>> chkconfig: 234 20 80
>>>>>> JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
>>>>>> export JAVA_HOME
>>>>>> PATH=$JAVA_HOME/bin:$PATH
>>>>>> export PATH
>>>>>> CATALINA_HOME=/opt/jboss/apache-tomcat-6.0.45
>>>>>> export CATALINA_HOME
>>>>>> case $1 in
>>>>>> start)
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                        "
>>>>>> ;;
>>>>>> stop)
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"                                                                                        
>>>>>> ;;
>>>>>> restart)
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh stop"
>>>>>> /sbin/runuser -s /bin/sh - jboss_tomcat -c "$CATALINA_HOME/bin/catalina.sh start                                                                                       "
>>>>>> ;;
>>>>>> esac
>>>>>> exit 0
>>>>>>
>>>>>> ==========
>>>>>>
>>>>>> When the service starts up in permissive mode, this is what we see from pstree (I've copied in tomcat as well for reference):
>>>>>>
>>>>>> ==========
>>>>>>
>>>>>> |-java,tomcat,`system_u:system_r:tomcat_t:s0' -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory ...
>>>>>>   |   |-{java},`system_u:system_r:tomcat_t:s0'
>>>>>>
>>>>>>
>>>>>>   |-java,jboss_tomcat,`system_u:jboss_r:jboss_java_t:s0' ...
>>>>>>   |   |-{java},`system_u:jboss_r:jboss_java_t:s0'
>>>>>>
>>>>>> ===============
>>>>>>
>>>>>> I've attached the policy module .te file for convenience as well.
>>>>>>
>>>>>> We are obviously missing something around the start up process but not sure what at this point so would appreciate you guys expert view on this.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: refpolicy-bounces at oss.tresys.com 
>>>>>> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, 
>>>>>> Walid
>>>>>> Sent: 03 August 2016 11:30
>>>>>> To: Borg-Cardona, Jack; Dominick Grift; refpolicy at oss.tresys.com
>>>>>> Subject: Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> Morning Dominick,
>>>>>>
>>>>>> Indeed, we'll take some time out to digest that and come up with a solution based on your clarification.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Walid Fakim
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Borg-Cardona, Jack
>>>>>> Sent: 03 August 2016 09:25
>>>>>> To: Dominick Grift; Fakim, Walid; refpolicy at oss.tresys.com
>>>>>> Subject: RE: [refpolicy] Compile Error when using the userdom_login_user_template() macro...
>>>>>>
>>>>>> 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<<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=0x3B6C5
>>>>>>>>>>>> F
>>>>>>>>>>>> 1
>>>>>>>>>>>> D
>>>>>>>>>>>> 2
>>>>>>>>>>>> C
>>>>>>>>>>>> 7
>>>>>>>>>>>> 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=0x3B6C5F
>>>>>>>>>>> 1
>>>>>>>>>>> D
>>>>>>>>>>> 2
>>>>>>>>>>> C
>>>>>>>>>>> 7
>>>>>>>>>>> B
>>>>>>>>>>> 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=0x3B6C5F1
>>>>>>>>>> D
>>>>>>>>>> 2
>>>>>>>>>> C
>>>>>>>>>> 7
>>>>>>>>>> B
>>>>>>>>>> 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=0x3B6C5F1D
>>>>>>>>> 2
>>>>>>>>> C
>>>>>>>>> 7
>>>>>>>>> B
>>>>>>>>> 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=0x3B6C5F1D2
>>>>>>>> C
>>>>>>>> 7
>>>>>>>> B
>>>>>>>> 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=0x3B6C5F1D2C
>>>>>>> 7
>>>>>>> B
>>>>>>> 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=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
> 
> _______________________________________________
> 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=0x3B6C5F1D2C7B6B02
Dominick Grift

[refpolicy] --EXTERNAL--Re: Compile Error when using the userdom_login_user_template() macro...

[Parker, Michael D.]

Hmmm.....just a beginners curiousity....why a type jbossd_t instead of jboss_t in your definition?

***** ***** *****
Michael D. Parker
General Atomics - EMS
Michael.d.parker at ga.com  <<<<< NOTE: Remember to include my middle initial >>>>>
+1 858 964 6675 / Office 86-1319
16969 Mesamint Street / San Diego / CA / 92127

************************************************************************
CONFIDENTIALITY NOTICE: This communication is intended to be confidential to the 
person(s) to whom it is addressed.  If you are not the intended recipient or the agent of the 
intended recipient or if you are unable to deliver this communication to the intended 
recipient, you must not read, use or disseminate this information.  If you have received 
this communication in error,please advise the sender immediately by telephone and delete 
this messageand any attachments without retaining a copy.
*************************************************************************


-----Original Message-----
From: refpolicy-bounces@oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
Sent: Tuesday, August 02, 2016 1:05 PM
To: Dominick Grift <dac.override@gmail.com>; refpolicy at oss.tresys.com
Subject: --EXTERNAL--Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

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.



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=0x3B6C5F1D2C7B6
>>>> 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=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

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] --EXTERNAL--Re: Compile Error when using the userdom_login_user_template() macro...

[Fakim, Walid]

A beginners answer ;) .... not sure why jbossd_t was used - I'll have to check with my colleagues who worked on this previously.

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Parker, Michael D. [mailto:Michael.D.Parker at ga.com] 
Sent: 02 August 2016 21:49
To: Fakim, Walid; Dominick Grift; refpolicy at oss.tresys.com
Subject: RE: --EXTERNAL--Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

Hmmm.....just a beginners curiousity....why a type jbossd_t instead of jboss_t in your definition?

***** ***** *****
Michael D. Parker
General Atomics - EMS
Michael.d.parker at ga.com  <<<<< NOTE: Remember to include my middle initial >>>>>
+1 858 964 6675 / Office 86-1319
16969 Mesamint Street / San Diego / CA / 92127

************************************************************************
CONFIDENTIALITY NOTICE: This communication is intended to be confidential to the
person(s) to whom it is addressed.  If you are not the intended recipient or the agent of the intended recipient or if you are unable to deliver this communication to the intended recipient, you must not read, use or disseminate this information.  If you have received this communication in error,please advise the sender immediately by telephone and delete this messageand any attachments without retaining a copy.
*************************************************************************


-----Original Message-----
From: refpolicy-bounces@oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Fakim, Walid
Sent: Tuesday, August 02, 2016 1:05 PM
To: Dominick Grift <dac.override@gmail.com>; refpolicy at oss.tresys.com
Subject: --EXTERNAL--Re: [refpolicy] Compile Error when using the userdom_login_user_template() macro...

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.



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=0x3B6C5F1D2C7B6
>>>> 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=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

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy