Skip to content

Instantly share code, notes, and snippets.

@vinzent
Created August 20, 2016 06:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vinzent/ec269970142a723bd6a184707ade66b2 to your computer and use it in GitHub Desktop.
Save vinzent/ec269970142a723bd6a184707ade66b2 to your computer and use it in GitHub Desktop.
SELinux Java App system service type transition
Am 19.08.2016 um 17:53 schrieb 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@gmail.com]
>> Sent: 19 August 2016 14:14
>> To: Fakim, Walid; refpolicy@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@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@gmail.com]
>>> Sent: 16 August 2016 15:23
>>> To: Fakim, Walid; refpolicy@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@oss.tresys.com
>>>>> [mailto:refpolicy-bounces@oss.tresys.com] On Behalf Of Fakim, Walid
>>>>> Sent: 15 August 2016 16:30
>>>>> To: Dominick Grift; refpolicy@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@gmail.com]
>>>>> Sent: 15 August 2016 16:24
>>>>> To: Fakim, Walid; refpolicy@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@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@gmail.com]
>>>>>> Sent: 15 August 2016 15:55
>>>>>> To: Fakim, Walid; refpolicy@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@gmail.com]
>>>>>>> Sent: 15 August 2016 15:13
>>>>>>> To: Fakim, Walid; refpolicy@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@gmail.com]
>>>>>>>> Sent: 15 August 2016 14:44
>>>>>>>> To: Fakim, Walid; refpolicy@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@gmail.com]
>>>>>>>>> Sent: 15 August 2016 14:22
>>>>>>>>> To: Fakim, Walid; refpolicy@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@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@oss.tresys.com] On Behalf Of Fakim,
>>>>>>>>>> Walid
>>>>>>>>>> Sent: 03 August 2016 11:30
>>>>>>>>>> To: Borg-Cardona, Jack; Dominick Grift;
>>>>>>>>>> refpolicy@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@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@gmail.com]
>>>>>>>>>> Sent: 03 August 2016 08:29
>>>>>>>>>> To: Fakim, Walid; refpolicy@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@gmail.com]
>>>>>>>>>>> Sent: 02 August 2016 21:16
>>>>>>>>>>> To: Fakim, Walid; refpolicy@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@gmail.com]
>>>>>>>>>>>> Sent: 02 August 2016 20:13
>>>>>>>>>>>> To: Fakim, Walid; refpolicy@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@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@gmail.com]
>>>>>>>>>>>>> Sent: 01 August 2016 15:49
>>>>>>>>>>>>> To: Fakim, Walid; refpolicy@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@gmail.com]
>>>>>>>>>>>>>> Sent: 28 July 2016 15:36
>>>>>>>>>>>>>> To: Fakim, Walid; refpolicy@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@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@oss.tresys.com
>>>>>>>>>>>>>>> [mailto:refpolicy-bounces@oss.tresys.com] On Behalf Of
>>>>>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>>>>> Sent: 28 July 2016 12:53
>>>>>>>>>>>>>>> To: refpolicy@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@oss.tresys.com
>>>>>>>>>>>>>>>> [mailto:refpolicy-bounces@oss.tresys.com] On Behalf Of
>>>>>>>>>>>>>>>> Dominick Grift
>>>>>>>>>>>>>>>> Sent: 28 July 2016 10:44
>>>>>>>>>>>>>>>> To: refpolicy@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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment