Bug 1210421

Summary:	SELinux is preventing kadmind from unlink and write access on the file kadmin_0
Product:	Red Hat Enterprise Linux 6	Reporter:	Brian J. Murrell <brian>
Component:	selinux-policy	Assignee:	Miroslav Grepl <mgrepl>
Status:	CLOSED ERRATA	QA Contact:	Milos Malik <mmalik>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.6	CC:	brian, dominick.grift, dwalsh, extras-qa, lvrabec, mgrepl, mkosek, mmalik, nalin, plautrba, pvoborni, pvrabec, robatino, sgallagh, ssekidde
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	selinux-policy-3.7.19-266.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1161592
Clones:	1220763 (view as bug list)		Environment:
Last Closed:	2015-07-22 07:13:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Brian J. Murrell 2015-04-09 16:54:18 UTC

Opening this bug since it happens on RHEL 6.6 also.

+++ This bug was initially created as a clone of Bug #1161592 +++

Description of problem:
ipa-server-install fails on configuaration of kadmin:

  systemctl start kadmin.service 

errors out.

Version-Release number of selected component (if applicable):
freeipa-server-4.1.1-1
krb5-server-1.12.2-8.fc21.x86_64
selinux-policy-3.13.1-92.fc21.noarch

How reproducible:
Always

Steps to Reproduce:
1. run ipa-server-install
or then just 
1. systemctl start kadmin.service


Actual results:
ipa-server-install fails on configuration of kadmin

Expected results:
ipa-server-install finishes successfully 

Additional info:

found 2 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing kadmind from unlink access on the file kadmin_0.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that kadmind should be allowed unlink access on the kadmin_0 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep kadmind /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:kadmind_t:s0
Target Context                system_u:object_r:tmp_t:s0
Target Objects                kadmin_0 [ file ]
Source                        kadmind
Source Path                   kadmind
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM                    selinux-policy-3.13.1-92.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     obfuscated
Platform                      Linux obfuscated
                              3.16.3-300.fc21.x86_64 #1 SMP Wed Sep 17 20:54:02
                              UTC 2014 x86_64 x86_64
Alert Count                   8
First Seen                    2014-11-07 12:14:58 CET
Last Seen                     2014-11-07 12:14:58 CET
Local ID                      8965a9af-8310-43d7-94ff-d63c89029193

Raw Audit Messages
type=AVC msg=audit(1415358898.900:118): avc:  denied  { unlink } for  pid=2706 comm="kadmind" name="kadmin_0" dev="dm-0" ino=411321 scontext=system_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0


Hash: kadmind,kadmind_t,tmp_t,file,unlink

--------------------------------------------------------------------------------

SELinux is preventing kadmind from write access on the file kadmin_0.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that kadmind should be allowed write access on the kadmin_0 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep kadmind /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:kadmind_t:s0
Target Context                system_u:object_r:tmp_t:s0
Target Objects                kadmin_0 [ file ]
Source                        kadmind
Source Path                   kadmind
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM                    selinux-policy-3.13.1-92.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     obfuscated
Platform                      Linux obfuscated
                              3.16.3-300.fc21.x86_64 #1 SMP Wed Sep 17 20:54:02
                              UTC 2014 x86_64 x86_64
Alert Count                   8
First Seen                    2014-11-07 12:14:58 CET
Last Seen                     2014-11-07 12:14:58 CET
Local ID                      d985fe2c-dded-423d-af45-31e3e220085a

Raw Audit Messages
type=AVC msg=audit(1415358898.905:123): avc:  denied  { write } for  pid=2706 comm="kadmind" name="kadmin_0" dev="dm-0" ino=411321 scontext=system_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0


Hash: kadmind,kadmind_t,tmp_t,file,write

--- Additional comment from Martin Kosek on 2014-11-07 07:52:50 EST ---

This is Fedora 21 Final blocker as it blocks FreeIPA server installation, Stephen is already in copy.

--- Additional comment from Fedora Blocker Bugs Application on 2014-11-07 07:58:08 EST ---

Proposed as a Blocker for 21-final by Fedora user sgallagh using the blocker tracking app because:

 Proposed criterion: https://lists.fedoraproject.org/pipermail/server/2014-November/001551.html

From Alpha Criteria:
"Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode"

--- Additional comment from Miroslav Grepl on 2014-11-07 08:25:07 EST ---

Could you confirm it happens also if you remove /tmp/kadmin_0 a re-test it with ipa-server-install?

--- Additional comment from Miroslav Grepl on 2014-11-07 08:27:12 EST ---

Something created "kadmin_0" in /tmp with tmp_t. Have you ever run in permissive mode?

--- Additional comment from Nalin Dahyabhai on 2014-11-07 08:48:07 EST ---

More likely it's kadmind's replay cache, which would be in /var/tmp, and would usually be labeled kadmind_tmp_t when it's created by kadmind.

--- Additional comment from Petr Vobornik on 2014-11-07 09:46:54 EST ---

removal of /var/tmp/kadmin_0 fixes the issue and FreeIPA is successfully installed. kadmin_0 is recreated with correct kadmind_tmp_t label.

Seems that comment 4 is the source of the error. Therefore probably NOT A BUG.

Cause of the mistake:
* server was initially installed with old SELinux Policy.  
* installation was run in permissive mode
* SELinux Policy was updated
* installation was run in enforcing mode

On new clear vm with updated policy and in enforcing mode the installation succeeds.

Sorry for noise.

--- Additional comment from Stephen Gallagher on 2014-11-07 09:49:49 EST ---

OK, closing as NOTABUG. I will reopen it if it reappears during testing.

Thanks for the quick response, folks!

--- Additional comment from Miroslav Grepl on 2014-11-07 09:51:26 EST ---

Of course I meant /vat/tmp//kadmin_0.


Basically this was probably caused by a combination of these reasons.

--- Additional comment from Brian J. Murrell on 2015-03-26 11:53:18 EDT ---

I hit this issue on RHEL 6.6 also.  It happened to me because I switched a system from selinux disabled to selinux enforcing.  But I did invoke an autorelabel between those two states.

It seems like a bug that /var/tmp/kadmin_0 can be left around and not relabeled by an autolabel.

Could we get this reopened as such?

--- Additional comment from Miroslav Grepl on 2015-04-09 12:45:33 EDT ---

(In reply to Brian J. Murrell from comment #9)
> I hit this issue on RHEL 6.6 also.  It happened to me because I switched a
> system from selinux disabled to selinux enforcing.  But I did invoke an
> autorelabel between those two states.
> 
> It seems like a bug that /var/tmp/kadmin_0 can be left around and not
> relabeled by an autolabel.
> 
> Could we get this reopened as such?

If so, please open a new RHEL6 bug.

Comment 2 Miroslav Grepl 2015-04-12 08:48:52 UTC

Brian,
what is your reproducer on RHEL6?

Comment 3 Brian J. Murrell 2015-04-18 13:18:27 UTC

It happened to me because I switched a system from selinux disabled to selinux enforcing.  But I did invoke an autorelabel between those two states.

It seems like a bug that /var/tmp/kadmin_0 can be left around and not relabeled by an autolabel.

Comment 4 Daniel Walsh 2015-04-20 16:02:19 UTC

matchpathcon /var/tmp/kadmin_0
/var/tmp/kadmin_0	<<none>>

Looks like we have no label for this.

Comment 5 Milos Malik 2015-04-22 11:53:24 UTC

I talked to pkis, who is a kerberos QE, and he told me that following file will most likely suffer from the same problem:

# matchpathcon /var/tmp/kiprop_0
/var/tmp/kiprop_0	<<none>>
#

Comment 6 Miroslav Grepl 2015-04-30 12:12:33 UTC

(In reply to Milos Malik from comment #5)
> I talked to pkis, who is a kerberos QE, and he told me that following file
> will most likely suffer from the same problem:
> 
> # matchpathcon /var/tmp/kiprop_0
> /var/tmp/kiprop_0	<<none>>
> #

And should we use also kadmind_tmp_t labeling for it?

Comment 7 Milos Malik 2015-05-07 10:13:12 UTC

It would be better to label the /var/tmp/kiprop_0 as krb5kdc_tmp_t, because:

# sesearch -s kpropd_t -t tmp_t -T
Found 2 semantic te rules:
   type_transition kpropd_t tmp_t : file krb5kdc_tmp_t; 
   type_transition kpropd_t tmp_t : dir krb5kdc_tmp_t; 

#

Comment 8 Miroslav Grepl 2015-05-12 07:01:09 UTC

commit 2d83c73a710ba8fe59e62cdea02446b4c2071d1e
Author: Miroslav Grepl <mgrepl>
Date:   Tue May 12 09:00:46 2015 +0200

    Add labeling for /var/tmp/kadmin_0 and /var/tmp/kiprop_0.

Comment 11 errata-xmlrpc 2015-07-22 07:13:19 UTC

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-1375.html