Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1210421 - SELinux is preventing kadmind from unlink and write access on the file kadmin_0
Summary: SELinux is preventing kadmind from unlink and write access on the file kadmin_0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-09 16:54 UTC by Brian J. Murrell
Modified: 2015-07-22 07:13 UTC (History)
15 users (show)

Fixed In Version: selinux-policy-3.7.19-266.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 1161592
: 1220763 (view as bug list)
Environment:
Last Closed: 2015-07-22 07:13:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1375 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2015-07-20 18:07:47 UTC

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


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