This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1280530 - Fernet tokens cannot read key files with SELInux enabled
Fernet tokens cannot read key files with SELInux enabled
Status: CLOSED CURRENTRELEASE
Product: RDO
Classification: Community
Component: openstack-keystone (Show other bugs)
trunk
Unspecified Unspecified
unspecified Severity unspecified
: ---
: trunk
Assigned To: Nathan Kinder
Shai Revivo
: Reopened
Depends On:
Blocks: 1300690
  Show dependency treegraph
 
Reported: 2015-11-11 20:46 EST by Adam Young
Modified: 2017-06-18 03:13 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-18 03:13:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Young 2015-11-11 20:46:31 EST
Description of problem:

type=AVC msg=audit(1447271600.161:353): avc:  denied  { write } for  pid=4616 comm="httpd" name="fernet-keys" dev="dm-1" ino=1706000 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=dir
type=SYSCALL msg=audit(1447271600.161:353): arch=c000003e syscall=21 success=no exit=-13 a0=7f2ebf240b10 a1=2 a2=7f2ed1d1af88 a3=0 items=0 ppid=2714 pid=4616 auid=4294967295 uid=163 gid=163 euid=163 suid=163 fsuid=163 egid=163 sgid=163 fsgid=163 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1447271602.313:354): avc:  denied  { write } for  pid=4648 comm="httpd" name="fernet-keys" dev="dm-1" ino=1706000 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=dir
type=SYSCALL msg=audit(1447271602.313:354): arch=c000003e syscall=21 success=no exit=-13 a0=7f2ebf60a4c0 a1=2 a2=7f2ed1d1af88 a3=0 items=0 ppid=2714 pid=4648 auid=4294967295 uid=163 gid=163 euid=163 suid=163 fsuid=163 egid=163 sgid=163 fsgid=163 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
Version-Release number of selected component (if applicable):


httpd needs to be able to read the fernet-keys
Comment 1 Nerijus 2016-01-19 08:42:12 EST
After setting the SELinux policy below, Keystone has started to work under WSGI. But allowing /etc write access for httpd is not something desirable, I'd guess.

require {
        type httpd_t;
        type etc_t;
        class dir write;
}

#============= httpd_t ==============
allow httpd_t etc_t:dir write;
Comment 2 Simon Sekidde 2016-01-20 12:20:37 EST
(In reply to Nerijus from comment #1)
> After setting the SELinux policy below, Keystone has started to work under
> WSGI. But allowing /etc write access for httpd is not something desirable,
> I'd guess.

Not a good idea. 

If you change the label for the path /etc/keystone/fernet-keys to something like keystone_cgi_ra_content_t or keystone_cgi_rw_content_t does this fix your problem?
Comment 3 Nerijus 2016-01-21 02:51:10 EST
(In reply to Simon Sekidde from comment #2)
> (In reply to Nerijus from comment #1)
> > After setting the SELinux policy below, Keystone has started to work under
> > WSGI. But allowing /etc write access for httpd is not something desirable,
> > I'd guess.
> 
> Not a good idea. 
> 
> If you change the label for the path /etc/keystone/fernet-keys to something
> like keystone_cgi_ra_content_t or keystone_cgi_rw_content_t does this fix
> your problem?

Simon, your suggestion fixed the problem. I've done the following:
/usr/sbin/semanage fcontext -a -t keystone_cgi_ra_content_t "/etc/keystone/fernet-keys(/.*)?"
/sbin/restorecon -R -v /etc/keystone/fernet-keys

And Keystone has started to issue the tokens. Am I right in thinking that "ra" in keystone_cgi_ra_content_t context means read-only access and "rw" in another of your suggested means read and write?
Now need to ensure that fernet rotation won't change context of key files...
Comment 4 Lukas Vrabec 2016-01-21 07:48:21 EST
Nejirus, 
Do we know who created "/etc/keystone/fernet-keys"? 
We need to find out which process creating this. Then in SELinux policy we add proper rules to create this dir with correct label.
Comment 5 Nerijus 2016-01-21 08:19:39 EST
(In reply to Lukas Vrabec from comment #4)
> Nejirus, 
> Do we know who created "/etc/keystone/fernet-keys"? 
> We need to find out which process creating this. Then in SELinux policy we
> add proper rules to create this dir with correct label.

In usual case it would be 'keystone_manage fernet_setup' command. In my case it's Chef recipe. We run 3 controllers cluster and Chef w/ custom wrapper script is taking care of fernet key distribution across the cluster.
Comment 6 Nerijus 2016-01-21 09:31:52 EST
(In reply to Nerijus from comment #5)
> (In reply to Lukas Vrabec from comment #4)
> > Nejirus, 
> > Do we know who created "/etc/keystone/fernet-keys"? 
> > We need to find out which process creating this. Then in SELinux policy we
> > add proper rules to create this dir with correct label.
> 
> In usual case it would be 'keystone_manage fernet_setup' command. In my case
> it's Chef recipe. We run 3 controllers cluster and Chef w/ custom wrapper
> script is taking care of fernet key distribution across the cluster.

OTOH, we use 'keystone_manage fernet_rotate' inside the wrapper script. Just to be on the safe side we put 'restorecon' at the end of it. So, if anything has messed up the file contexts, it would be restored.
Comment 8 Ken Savich 2016-05-10 10:01:24 EDT
Any news on this issue? I've been running into this on OSP 8 as well.
Comment 9 Nathan Kinder 2016-05-10 12:58:10 EDT
This looks to be a problem in Liberty that was fixed in later OpenStack releases.  The keystone WSGI process should not need wrtie access on the directory where the fernet key(s) reside, but the AVC clearly shows that it is trying to access that directory with write permission.  In the Liberty tree, this happens during a permissions check on the keys directory:

https://github.com/openstack/keystone/blob/stable/liberty/keystone/token/providers/fernet/utils.py#L34-L41

If you look at the Mitaka branch, this method has been changed to only check for write access in certain cases (largely just for use by the keystone_manage CLI, which is unconfined):

https://github.com/openstack/keystone/blob/stable/mitaka/keystone/token/providers/fernet/utils.py#L34-L38
Comment 10 Chandan Kumar 2016-05-19 11:56:28 EDT
This bug is against a Version which has reached End of Life.
If it's still present in supported release (http://releases.openstack.org), please update Version and reopen.
Comment 11 Adam Young 2016-05-20 13:34:47 EDT
This was fixed in Mitaka and is in Stable.

Note You need to log in before you can comment on or make changes to this bug.