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.
Bug 1161592 - 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 NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 21
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F21FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-11-07 12:21 UTC by Petr Vobornik
Modified: 2015-04-09 16:45 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1210421 (view as bug list)
Environment:
Last Closed: 2014-11-07 14:49:49 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Petr Vobornik 2014-11-07 12:21:21 UTC 
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
Comment 1 Martin Kosek 2014-11-07 12:52:50 UTC 
This is Fedora 21 Final blocker as it blocks FreeIPA server installation, Stephen is already in copy.
Comment 2 Fedora Blocker Bugs Application 2014-11-07 12:58:08 UTC 
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"
Comment 3 Miroslav Grepl 2014-11-07 13:25:07 UTC 
Could you confirm it happens also if you remove /tmp/kadmin_0 a re-test it with ipa-server-install?
Comment 4 Miroslav Grepl 2014-11-07 13:27:12 UTC 
Something created "kadmin_0" in /tmp with tmp_t. Have you ever run in permissive mode?
Comment 5 Nalin Dahyabhai 2014-11-07 13:48:07 UTC 
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.
Comment 6 Petr Vobornik 2014-11-07 14:46:54 UTC 
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.
Comment 7 Stephen Gallagher 2014-11-07 14:49:49 UTC 
OK, closing as NOTABUG. I will reopen it if it reappears during testing.

Thanks for the quick response, folks!
Comment 8 Miroslav Grepl 2014-11-07 14:51:26 UTC 
Of course I meant /vat/tmp//kadmin_0.


Basically this was probably caused by a combination of these reasons.
Comment 9 Brian J. Murrell 2015-03-26 15:53:18 UTC 
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?
Comment 10 Miroslav Grepl 2015-04-09 16:45:33 UTC 
(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.
Note You need to log in before you can comment on or make changes to this bug.