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

[walid.fakim@cgi.com (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