How would tools like “paster” work with SELinux?

blog about projects which use/used a tool like the paster to create own application servers. Now let’s talk about other specific example – Thin (Ruby web server).

Previously, we had all services using Thin running in the thin_t SELinux domain type. But we did not realize there are many projects which use Thin in different ways and we could not treat all of them just by one SELinux domain type. So we re-wrote the thin policy to provide

thin_domain_template()

But how to use this interface? I will show you on AEOLUS-CONFIGSERVER example.

AEOLUS-CONFIGSERVER scenario

# yum install aeolus-configserver
# rpm -qi aeolus-configserver
Description :
The Aeolus Config Server, a service for storing and retrieving VM configurations

At First (read the previous blog for more details) we need to add a helper script which calls the thin binary from this helper script instead of either an init script or a systemd unit file.

# rpm -ql aeolus-configserver |grep wrapper
/usr/bin/aeolus-configserver-thinwrapper
# cat /usr/bin/aeolus-configserver-thinwrapper

#!/bin/bash

/usr/bin/thin start -c $CONFIG_SERVER_DIR -l $THIN_LOG \
-P $THIN_PID -a $THIN_IP -e $RACK_ENV \
–user $AEOLUS_USER –group $AEOLUS_GROUP \
-d –prefix=${PREFIX} -R $CONFIG_SERVER_RACKUP -p $CONFIG_SERVER_PORT

Now the following steps are needed to get an initial policy.

1. Create a new policy file.

# echo “policy_module(aeolus_configserver,1.0)” > aeolus_configserver.te

2. Use the template.

# echo “thin_domain_template(aeolus_configserver)” >> aeolus_configserver.te

You can check the thin_domain_template() on

http://git.fedorahosted.org/cgit/selinux-policy.git/tree/thin.if?h=master_contrib

3. Compile/load it.

# make -f /usr/share/selinux/devel/Makefile aeolus_configserver.pp
# semodule -i aeolus_configserver.pp

4. What will we get?

The following basic types will be created

# seinfo -t |grep configserver
thin_aeolus_configserver_exec_t
thin_aeolus_configserver_t

by “thin_domain_template(aeolus_configserver)“.

* thin_aeolus_configserver_exec_t type is an executable type for the aeolus-configserver-thinwrapper helper script.

# ls -Z /usr/bin/aeolus-configserver-thinwrapper
-rwxr-xr-x. root root system_u:object_r:thin_aeolus_configserver_exec_t:s0 /usr/bin/aeolus-configserver-thinwrapper

* thin_aeolus_configserver_t domain type is a domain type for an aeolus-configserver thin process.

With these types we can see the following transition

initrc_t @ thin_aeolus_configserver_exec_t –> thin_aeolus_configserver_t @ thin_exec_t –> thin_aeolus_configserver_t

But without this helper script you would see

initrc_t @ thin_exec_t –> thin_t

which means your project runs in the thin domain type defaultly and probably would not work. We have limited rules for the thin_t domain type because we want to know about this fact.

Now back to the thin_aeolus_configserver_t domain type. This type also got the thin_domain attribute. Basic rules are defined by the policy for all thin domains which are covered by this attribute.

FOREMAN start point

If you call

thin_domain_template(foreman)

you will get

# seinfo -t |grep foreman
thin_foreman_exec_t
thin_foreman_t

and thin_foreman_t will have the thin_domain attribute with the following basic rules

http://git.fedorahosted.org/cgit/selinux-policy.git/tree/thin.te?h=master_contrib

Check the thin_domain local policy section.

Note: You can also see the policy which has been created for aeolus-configserver.

Note: there is a new tool for this called “sepolicy”.

But sometimes either you or I need to create a local test policy without these tools. Basically we start with

# vim mypol.te

and add needed declarations for mypol.te policy file. For example

# cat mypol.te
policy_module(mypol,1.0)
require{
type ping_t;
type openshift_initrc_t;
}
dontaudit ping_t openshift_initrc_t:fifo_file write;

Then we just compile/load this policy module.

# make -f /usr/share/selinux/devel/Makefile mypol.pp
# semodule -i mypol.pp

Based on this example we came up with a new VIM template for *.te policy file which would help us so we do not have to remember all these statements nor write them over and over. You can download this template from

http://mgrepl.fedorapeople.org/template.te

and execute

# cp template.te /usr/share/vim/vimfiles/

After that just add the line to your /etc/vimrc file.

autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec
+ autocmd BufNewFile *.te 0r /usr/share/vim/vimfiles/template.te
augroup END

Now you can try to create a new local policy.

# vim mypolicy.te

What do you think? Would you like to add some additional examples or comments?

The paster tool is a python script. The script is called either from an init script or a systemd unit file by a project. This means we can have multiple calling of this script to create running daemons. We have the following transition

initrc_t @ bin_t -> initrc_t

Probably you know this is wrong. We should confine daemons running in the initrc_t domain type. We had this issue with the piranha package. I did not know everything about the paster tool. I added the piranha_web_exec_t label for the paster python script and we got the following transition

initrc_t @ piranha_web_exec_t -> piranha_web_t

which is what we wanted. But this change caused TurboGears2 application servers running with piranha_web_t domain type. It was obviously wrong.

What happened?

turbogears init script @ paster -> TurboGears2 application server
initrc_t @ piranha_web_exec_t -> piranha_web_t

You see the problem. How could we solve issues like this? The solution is pretty easy because we know how SELinux and transitions work. We can just do

initrc_t @ $1_exec_t ->$1_t @ bin_t -> $1_t

What is “?_exec_t” in this case? It can be a script which is called from either an init script or a systemd unit file and this script then calls the pastor python script with arguments. Then we get what we want

initrc_t @ piranha_web_exec_t -> piranha_web_t @ bin_t -> piranha_web_t
initrc_t @ turbogears_exec_t -> turbogears_t @ bin_t -> turbogears_t

and we can leave the pastor python script labeled as bin_t.

We can apply this solution for other projects.

We go through all new bugs every day in the morning. So there are two periods per day because Dan is from USA and I am from Czech Republic.

We add appropriate fixes to the selinux-policy repo on fedorahosted.org first and then we commit changes also to the selinux-policy git repo on fedoraproject.org. But this does not mean we do a new build immediately. The main reason is we want to cover as much bugs by a build as possible. So we do a new build either at the end of the day or the next day. Of course if a build is required we do it when is needed.

Also we are not able to do a new update with an each build. In this case, you can easily download new builds from koji and install them. So if you see

“Fixed in selinux-policy-<version>”

as a comment in a bug, you get a new build very soon. If not, then I have overslept and just ping me. I would like to thank all for testing/using a new builds from koji.

“Ho do I know whether I need to use the optional_policy block or not?”

When we write policy we can choose to have the policy either shipped within the base policy or as as module.

We use the modules config files to specify whether a policy is in the base or module.

We have a different modules config file for each policy type that we ship

modules-targeted.conf
modules-mls.conf
modules-minimum.conf

which contain statements like

# Layer: kernel
# Module: domain
# Required in base
#
# Core policy for domains.
#
domain = base

# Layer: system
# Module: init
#
# System initialization programs (init and init scripts).
#
init = module

What does either “base” or “module” mean? The note says

# For modular policies, modules set to “base” will be
# included in the base module. “module” will be compiled
# as individual loadable modules.

The base.pp policy module contains core policy modules which are needed for the basic confinement of your system focused on the core operating system. The base.pp module can not be removed from your policy.

But what about “module”. This is different. Theoretically these modules are all optional. Meaning you should be able to remove them from the policy if you wanted to.

You can list the modules using:

$ semodule -l

There are some exceptions for modules like miscfiles, authlogin, init,
systemd, sysnetwork. We define them as “module” in the modules-*.conf
file but they can not be removed.

Another way of looking at this would be to examine the directories in
which we ship the interfaces. We ship interface files in /usr/share/selinux/devel/include/ subdirs

system kernel roles services admin apps

Interfaces in system and kernel are core to the system, while interfaces in the other directories as optional.

Let’s say you write a policy and you need to use a rpm interface because your application execute rpm -qi. First, we need to examine that the rpm module is not a part of the base.pp policy module

$ semodule -l | grep rpm
rpm 1.12.0

Ok, I see it is not. So I will call a rpm interface with the optional_policy block.

optional_policy(`
rpm_exec(mydomain_t)
‘)

It means that our policy does not cover the matahari-qmf-rpcd service which probably has been shipped recently. I know nothing about this service and I want to confine it. I am not sure if we have a policy for Matahari project so I use the selinux-policy-doc package to check it.

$ rpm -q selinux-policy-doc
selinux-policy-doc-3.10.0-96.fc17.noarch

The package is installed and I am able to find whether a policy exists

$ grep -r matahari /usr/share/selinux/devel/include/ |wc -l
256

There is a policy which I could use. We are interested in the /usr/share/selinux/devel/include/services/matahari.if policy file and the matahari_domain_template() interface. A template interface is a special interface to create a basic set of rules for services – template interfaces generate domain, executable and file types for a service.

In our case I declare the following local policy.

$ cat mymatahari.te
policy_module(mymatahari,1.0)

matahari_domain_template(rpcd)

Then I load and install it.

$ make -f /usr/share/selinux/devel/Makefile mymatahari.pp
$ semodule -i mymatahari.pp

You can see what types were added.

$ seinfo -t |grep matahari_rpc
matahari_rpcd_unit_file_t
matahari_rpcd_exec_t
matahari_rpcd_t

These three types were created by the matahari_domain_template() interface and we use them for an initial confinement. Now we need to tell SELinux that the matahari-qmf-rpcd service started by systemd should end up in the matahari_rpcd_t domain.

$ chcon -t matahari_rpcd_exec_t `which matahari-qmf-rpcd`
$ systemctl restart matahari-rpc.service
$ ps -eZ |grep matahari
system_u:system_r:matahari_rpcd_t:s0 3338 ? 00:00:00 matahari-qmf-rp

You are done and you have this new service running in the proper domain. Now you can use ausearch/audit2allow tools to check AVC messages

$ ausearch -m avc -ts recent |audit2allow
#============= matahari_rpcd_t ==============
allow matahari_rpcd_t bin_t:file getattr;
allow matahari_rpcd_t passwd_file_t:file { read getattr open };
allow matahari_rpcd_t usr_t:file { read getattr open };

The next step would be either file a new bug with these AVC messages and with the local policy or use the audit2allow tool to generate rules for the mymatahari.te policy file.

$ ausearch -m avc -ts recent |audit2allow -R |grep \(matahari >> mymatahari.te
$ make -f /usr/share/selinux/devel/Makefile mymatahari.pp
$ semodule -i mymatahari.pp

I guess you know tools like strace, gdb, which help us with debugging. Today I would like to show you how SELinux could help us to understand what an application, a script or a command does.

I have recently got the following AVC msg:

type=AVC msg=audit(1328313263.274:55): avc: denied { read } for pid=869 comm=”smartdnotify” name=”group” dev=(removed) ino=293602 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:passwd_file_t:s0 tclass=filenode=(removed)

which tells me that the fsdaemon_t domain is trying to access to the /etc/group file with the passwd_file_t label.

$ grep -r passwd_file_t /etc/selinux/targeted/contexts/files/

So I need to find a part of code which needs this access. Usually we see a similar AVC message if a getpw* function is called. That is the time for nm and grep commands.

$ nm -D PATHTO_BINARY |grep getpw
$ grep -r getpw SOURCE_CODE

If you get a result, you will be happy. If not, you need to continue with finding.

Our issue is a case where the smartdnotify command, which causes AVC message, is a shell script. I looked at this script and I got it.

$ cat /usr/libexec/smartmontools/smartdnotify |grep who
for t in $(who | awk ‘{ print $2; }’ | grep -e ‘^tty’ -e ‘^pts/’)

But what to do if you don’t know that the “who” command reads the /etc/group file? You could try to use SELinux to find out an answer. Everything what you need to do is to use SELinux tools.

1. Turn on full auditing system.
$ echo “-w /etc/shadow -p w” >> /etc/audit/audit.rules
$ service auditd restart

2. Generate a local test policy for the “who” command (or your application).
$ sepolgen -n debugwho -t 0 PATHTO/who

3. Remove the context declaration from the debugwho.fc policy file. It might cause a problem with a duplicate declaration.
$ echo “#no context” > debugwho.fc
$ sh debugwho.sh
$ chcon -t debugwho_exec_t PATHTO/who

Now you have loaded debug policy and you need to run the “who” command in this domain.

$ runcon -t system_u -r system_r -t initrc_t — runcon debugwho_t — who

The following transition will happen:

unconfined_t -> initrc_t -> debugwho_t

$ ausearch -m avc -ts recet |grep passwd

type=AVC msg=audit(1328540990.575:125): avc: denied { read } for pid=2258 comm=”who” name=”group” dev=”dm-1″ ino=527060 scontext=system_u:system_r:debugwho_t:s0-s0:c0.c1023 tcontext=system_u:object_r:passwd_file_t:s0 tclass=file

and you won.

Imagine you use it for more complicated applications, services which use python bindings for example.

Now back to the problem. This guy got a similar error message:

“/usr/bin/semodule_link: loading package libsepol.print_missing_requirements: rhcs’s global requirements were not met: type/attribute corosync_exec_t
/usr/bin/semodule_link: Error while linking packages”

through building of his custom policy.

We use “optional_policy” statement to declare a rule which could be invalid if an appropriate module (module containing a declaration of an interface) is disabled/removed or is not declared. Probably the following example is better than my definition.

optional_policy(`
corosync_exec(fenced_t)
‘)

allows the fenced binary to execute the Corosync Cluster Engine. Now how could this rule become invalid? Easily by disabling of the corosync policy module which contains this interface definition.

# semodule -d corosync

This is a way how we do the policy really modular. You can remove a module from the policy and everything should work fine, only a daemon or a user program will be without SELinux protection. You can check this out and make your policy being as minimal as you wish. Just be careful with removing of the unconfineduser policy module (see http://danwalsh.livejournal.com/42394.html).

So if you use an interface without “optional” statement and you disable/remove or do not add a module declaration into the module-*.conf file, you will get exactly the same error message.

Note: If the “optional_policy” declaration contains more rules then all these rules will become invalid for this block.