From: walid.fakim@cgi.com (Fakim, Walid) Date: Fri, 2 Sep 2016 11:43:11 +0000 Subject: [refpolicy] Compile Error when using the userdom_login_user_template() macro... In-Reply-To: <26f58b10-10ba-04e7-c17f-ccefb8342d1d@gmail.com> References: <53E0DE5B854BBC4EA982E3197A0C96D24B111CB0@SE-EX021.groupinfra.com> <67130EC7AFA3FE4E9290B03665B351F401E74A@SE-EX021.groupinfra.com> <03fad2ee-a1b3-c935-b113-e163f7ce519f@gmail.com> <67130EC7AFA3FE4E9290B03665B351F401F953@SE-EX021.groupinfra.com> <67130EC7AFA3FE4E9290B03665B351F401F9FF@SE-EX021.groupinfra.com> <67130EC7AFA3FE4E9290B03665B351F401FB5F@SE-EX021.groupinfra.com> <73aa20d5-58a9-dac8-8f6a-2ae2faeca221@gmail.com> <67130EC7AFA3FE4E9290B03665B351F402169F@SE-EX021.groupinfra.com> <45140f5b-fb93-1834-2220-23df5f13acd5@gmail.com> <67130EC7AFA3FE4E9290B03665B351F4021780@SE-EX021.groupinfra.com> <2bda2222-aa3e-a21f-eeca-86cd47c96549@gmail.com> <67130EC7AFA3FE4E9290B03665B351F4023AE5@SE-EX021.groupinfra.com> <3f55acae-78a9-8193-6747-ab454f901842@gmail.com> <67130EC7AFA3FE4E9290B03665B351F4024188@SE-EX021.groupinfra.com> <26f58b10-10ba-04e7-c17f-ccefb8342d1d@gmail.com> Message-ID: <67130EC7AFA3FE4E9290B03665B351F402460A@SE-EX021.groupinfra.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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<>> (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<>>>>>>>>>>>>> type myjava_exec_t; >>>>>>>>>>>>>> application_executable_file(myjava_exec_t) >>>>>>>>>>>>>> EOF >>>>>>>>>>>>>> >>>>>>>>>>>>>> cat >myjava.fc<>>>>>>>>>>>>> /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<>>>>>>>>>>>>>>>>>>> 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