Bug 1138424

What's needed is a transition rule.  When apache (httpd_t) executes /var/www/cgi-bin/keystone/*, transition the new process to keystone_t.

I believe we want to have keystone_cgi_script_t for it.

Created attachment 934922 [details]
proposed policy and scripts to compile and test

Some more information here  (I've been working on this issue with Nathan Kinder as well) - mod_wsgi does not exec the keystone scripts - instead it loads them as data and runs them in python interpreters inside the httpd subprocess.  As a result, a domain autotrans on the exec of the scripts will not trigger. I've written some test code to allow mod_wsgi to dynamically change context after the fork, just as it changes the user, process group, et al, but this brings up other questionable choices.

In particular, SELinux is not in favor of switching within a process.  In this case, we're doing it directly after a fork, but we're still doing it within the process and not on an exec boundary.

A better choice could be to actually cause keystone to do the exec and switch that way, but then it's no longer in the apache process, which may cause issues for things such as the SAML and federation support as of Juno.  This is also quite a bit more work.

Short question - I can make this work this way (dynamic transition on mod_wsgi fork), but is doing that appropriate?

commit 141011af28212092f96b0719c754b91c5077c670
Author: Lukas Vrabec <lvrabec>
Date:   Mon Oct 6 16:13:54 2014 +0200

    Make keystone_cgi_script_t domain. BZ (#1138424)

I still see this AVC when running keystone in httpd with selinux-policy-3.13.1-6.el7.noarch:

-----------------------------------------------------------------------------
type=AVC msg=audit(1413506204.808:77): avc:  denied  { open } for  pid=5219 comm="httpd" path="/var/log/keystone/keystone.log" dev="vda1" ino=18431067 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:keystone_log_t:s0 tclass=file
-----------------------------------------------------------------------------

The following rule is recommended by audit2allow:

  allow httpd_t keystone_log_t:file open;

I suspect that this is due to httpd opening keystone.log prior to the transition.

If I disable dontaudit rules, I also see this AVC in permissive mode:

type=AVC msg=audit(1413510114.291:718): avc:  denied  { name_bind } for  pid=3929 comm="httpd" src=5000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:commplex_main_port_t:s0 tclass=tcp_socket

Unfortunately, port 5000 is a standard keystone port, but it's already labeled as commplex_main_port_t in the base policy.  Is it possible to define an alias to allow this port to be used for either purpose?

I am able to run keystone in httpd using selinux-policy-3.13.1-6.el7.noarch along with this custom policy module:

---------------------------------------------------------------
policy_module(keystone-test,1.0.0)

require {
    type httpd_t;
    type keystone_log_t;
    type commplex_main_port_t;
}

typealias commplex_main_port_t alias keystone_main_port_t;

allow httpd_t keystone_log_t:file open;
allow httpd_t keystone_main_port_t:tcp_socket name_bind;
---------------------------------------------------------------

As you can see, I chose to alias commplex_main_port_t.  This required a new type of keystone_main_port_t since I couldn't redefine keystone_port_t as an alias.  This new alias name is appropriate, as port 5000 is referred to as the keystone "main" port, while 35357 is the keystone "admin" port.  If there is a better way to handle this, feel free to change it.  We just need to ensure that httpd_t can name_bind to ports 5000 and 35357.

One additional thing to point out is that I think the current rules for port 35357 are incorrect, but they happen to be working by chance.

When running keystone in httpd, we need httpd_t to be able to 'name_bind' to the ports.  The current policy around port 35357 (labeled keystone_port_t) allows keystone_t to name_bind.  This is needed when running keystone_all, but it doesn't work for httpd.

Since Keystone's admin port (35357) is in the ephemeral port range, httpd_t is allowed to bind to it.  I tested this my modifyin gthe httpd config to use port 35358, and it binds to the port just fine in enforcing mode.

We need to allow http_t to name_bind to keystone_port_t and keystone_main_port_t (or whatever alias/label you choose to use for port 5000).

Sent scratch builds to Nathan, waiting for reply to push to selinux-policy build.

*** Bug 1157658 has been marked as a duplicate of this bug. ***

(In reply to Lukas Vrabec from comment #13)
> Sent scratch builds to Nathan, waiting for reply to push to selinux-policy
> build.

It still fails in enforcing and audit2allow shows the following with
dontaudit rules turned off:

  allow httpd_t commplex_main_port_t:tcp_socket name_bind;
  allow httpd_t keystone_log_t:file open;

These would be solved with the changes I described in comment#11.

commit 21f2ce906ab407ae02bf4ce20c5d0315a364e86f
Author: Lukas Vrabec <lvrabec>
Date:   Mon Nov 10 15:34:53 2014 +0100

    Label keystone cgi files as keystone_cgi_script_exec_t. BZ(1138424)

There are some issues being seen with the new policy as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1174795#c11:

type=AVC msg=audit(1418833963.580:1474): avc:  denied  { getattr } for  pid=15900 comm="keystone-all" path="/usr/share/keystone/keystone-dist.conf" dev="sda1" ino=925373 scontext=system_u:system_r:keystone_t:s0 tcontext=system_u:object_r:keystone_cgi_script_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1418833963.580:1475): avc:  denied  { read } for  pid=15900 comm="keystone-all" name="keystone-dist.conf" dev="sda1" ino=925373 scontext=system_u:system_r:keystone_t:s0 tcontext=system_u:object_r:keystone_cgi_script_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1418833963.580:1476): avc:  denied  { open } for  pid=15900 comm="keystone-all" path="/usr/share/keystone/keystone-dist.conf" dev="sda1" ino=925373 scontext=system_u:system_r:keystone_t:s0 tcontext=system_u:object_r:keystone_cgi_script_exec_t:s0 tclass=file permissive=1

These AVCs were reported on Fedora (rawhide), but I believe that they apply for RHEL 7.1 as well.

The /usr/share/keystone/keystone-dist.conf file looks like a configuration file, so it should be labeled either etc_t or usr_t. Does it work after execution of following command?

# chcon -t usr_t /usr/share/keystone/keystone-dist.conf

(In reply to Milos Malik from comment #19)
> The /usr/share/keystone/keystone-dist.conf file looks like a configuration
> file, so it should be labeled either etc_t or usr_t. Does it work after
> execution of following command?
> 
> # chcon -t usr_t /usr/share/keystone/keystone-dist.conf

No, this wasn't enough to make it work.  I had to recursively label the /usr/share/keystone directory as usr_t to make it work.  Here is the labels prior to using chcon:

---------------------------------------------------------------------------
[rhosuser@rhos ~]$ ls -laZ /usr/share/keystone
drwxr-xr-x. root root     system_u:object_r:keystone_cgi_script_exec_t:s0 .
drwxr-xr-x. root root     system_u:object_r:usr_t:s0       ..
-rw-r--r--. root keystone system_u:object_r:keystone_cgi_script_exec_t:s0 keystone-dist.conf
-rw-r--r--. root keystone system_u:object_r:keystone_cgi_script_exec_t:s0 keystone-dist-paste.ini
-rw-r--r--. root keystone system_u:object_r:keystone_cgi_script_exec_t:s0 keystone.wsgi
-rw-r--r--. root keystone system_u:object_r:keystone_cgi_script_exec_t:s0 policy.v3cloudsample.json
-rwxr-xr-x. root root     system_u:object_r:keystone_cgi_script_exec_t:s0 sample_data.sh
-rw-r--r--. root keystone system_u:object_r:keystone_cgi_script_exec_t:s0 wsgi-keystone.conf
---------------------------------------------------------------------------

The keystone_cgi_script_exec_t label for /usr/share/keystone and it's contents works fine when running keystone in httpd, but not when it uses eventlet (keystone-all).  Both httpd and eventlet deployment methods work with a label of usr_t for /usr/share/keystone and it's contents, so I think that is the correct solution.

I do however still encounter failures starting keystone in httpd in enforcing mode.  The start failures are due to the following AVC messages as seen when starting keystone in httpd in permissive mode (with dontaudit rules disabled):

---------------------------------------------------------------------------
type=AVC msg=audit(1420693901.582:15510): avc:  denied  { name_bind } for  pid=1147 comm="httpd" src=5000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:commplex_main_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1420694028.935:15621): avc:  denied  { open } for  pid=1363 comm="httpd" path="/var/log/keystone/keystone.log" dev="vda1" ino=25700381 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:keystone_log_t:s0 tclass=file
---------------------------------------------------------------------------

We still need the changes I recommended in comment#11 to allow keystone to work in httpd, plus we need to correct the label for /usr/share/keystone to allow keystone to run in eventlet.  Basically, both supported deployment methods for keystone are broken in enforcing mode, so this is important to get addressed for RHEL 7.1.

I forgot to mention that the testing in comment#20 was using the selinux-policy-3.13.1-14.el7.noarch package.

Adding the below rule to fix httpd_t.

allow httpd_t keystone_log_t:file open;
corenet_tcp_bind_commplex_main_port(httpd_t)

^ to openstack-selinux

After using Ryan's latest openstack-selinux package, there is still the problem around the keystone_cgi_script_exec_t on /usr/share/keystone when deploying in eventlet.  To work around that, I'm defining the following fcontext before running packstack:

  semanage fcontext -a -t usr_t /usr/share/keystone\(/.\*\)\?

There are still some other unrelated AVCs that prevent packstack from completing in enforcing mode, but I'll file a separate bug for those.

All that remains here is to correct the label used for /usr/share/keystone(/.*)? to usr_t in selinux-policy.

If we change it to usr_t we don't get a transition. What is a path to CGI scripts?

The Keystone CGI scripts are placed in /var/www/cgi-bin/keystone:

[rhosuser@rhos ~]$ sudo ls -laZ /var/www/cgi-bin/keystone
drwxr-xr-x. keystone keystone system_u:object_r:httpd_sys_script_exec_t:s0 .
drwxr-xr-x. root     root     system_u:object_r:httpd_sys_script_exec_t:s0 ..
-rw-r--r--. keystone keystone system_u:object_r:httpd_sys_script_exec_t:s0 admin
-rw-r--r--. keystone keystone system_u:object_r:httpd_sys_script_exec_t:s0 main

I don't see the transition occurring, regardless of the label that is used on the CGI scripts.  As a test, I set the following fcontext rules before installing keystone:

  semanage fcontext -a -t usr_t /usr/share/keystone\(/.\*\)\?
  semanage fcontext -a -t keystone_cgi_script_exec_t /var/www/cgi-bin/keystone\(/.\*\)\?

This results in the keystone (mod_wsgi) processes running as httpd_t:

-----------------------------------------------------------------------------------------
[rhosuser@rhos ~]$ ps -efZ | grep keystone
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 rhosuser 990 7879  0 15:45 pts/0 00:00:00 grep --color=auto keystone
system_u:system_r:httpd_t:s0    keystone 28858 28857  0 14:59 ?        00:00:07 keystone-admin  -DFOREGROUND
system_u:system_r:httpd_t:s0    keystone 28859 28857  0 14:59 ?        00:00:00 keystone-main   -DFOREGROUND
-----------------------------------------------------------------------------------------

I will note that keystone seems to be working fine in enforcing mode as httpd_t though after setting the above fcontext rules using these packages:

  selinux-policy-3.13.1-14.el7.noarch
  openstack-selinux-0.6.11-1.el7ost.noarch

commit 420fe90411dd264136d08f084273e019a35ff03e
Author: Miroslav Grepl <mgrepl>
Date:   Mon Jan 12 12:10:08 2015 +0100

    Fix labeling for keystone CGI scripts.

I no longer see the AVCs described in this bug when deploying keystone in httpd with selinux-policy-3.13.1-16.el7, so the fixes appear to be working.

I do see an unrelated glance AVC during installation of RHEL OSP that seems to be newly introduced as of selinux-policy-3.13.1-15.el7.  I've opened bug 1181818 to track that issue.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0458.html