Red Hat Bugzilla – Full Text Bug Listing
|Summary:||PolicyKit authentication in Fedora 18 Alpha TC3 results in selinux denial|
|Product:||[Fedora] Fedora||Reporter:||Jan Sedlák <jsedlak>|
|Component:||selinux-policy||Assignee:||Miroslav Grepl <mgrepl>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||awilliam, dan.mashal, dominick.grift, dwalsh, jreznik, kevin, kparal, mgrepl, mkrizek, msivak, robatino, tmraz|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-09-12 19:51:31 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||752654, 846844|
Description Jan Sedlák 2012-08-28 07:55:33 EDT
Created attachment 607489 [details] selinux denial message Description of problem: In KDE, F18 Alpha TC3, everytime that something wants to use "kdesu" for graphical sudo (e. g. installing packages), kdesu window is immediately closed and selinux denial is displayed. How reproducible: Always. Steps to Reproduce: 1. Install KDE with F18 Alpha TC3 2. Open Apper, default GUI instalator of packages 3. Try to install any package Actual results: Kdesu pops up, but it's closed immediately, selinux warning is displayed and user is unable to give his password and proceed with installation. Expected results: User should be able to give his password and install packages.
Comment 1 Jan Sedlák 2012-08-28 07:58:00 EDT
Proposing as blockerbug per criterion: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops".
Comment 2 Miroslav Grepl 2012-08-28 09:02:47 EDT
Jan, what is path to "system-auth-ac" Also if you execute # cat denial |audit2allow -M mypol # semodule i mypol.pp Does it work then?
Comment 3 Jan Sedlák 2012-08-29 07:01:30 EDT
Path to system-auth-ac is /etc/pam.d/system-auth-ac (or what else should it be?) [garret@localhost Documents]$ ll /etc/pam.d/system-auth-ac -rw-r--r--. 1 root root 949 Aug 29 06:31 /etc/pam.d/system-auth-ac And I cannot execute this command, because "denial" file doesn't exist (or I don't know where to find it). Selinux said that I have to execute: grep polkit-agent-he /var/log/audit/audit.log | audit2allow -M mypoll semodule -i mypol.pp then I have to execute: /sbin/restorecon -v /etc/pam.d/system-auth-ac and then it works.
Comment 4 Miroslav Grepl 2012-08-29 07:46:14 EDT
Are you able to re-create it? I allowed this rule to make this working until we have a fix.
Comment 5 Adam Williamson 2012-08-29 12:44:57 EDT
Discussed at 2012-08-29 blocker review meeting. We agreed this sounds rather like a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=849990 - apper uses PolicyKit, not kdesu, and the symptoms described here sound rather similar to that bug. So we decided to delay blocker evaluation until Jan, Jaroslav and Martin can get together and compare notes to be clear whether this is a dupe.
Comment 6 Jaroslav Reznik 2012-08-29 12:46:52 EDT
Ok, just retested - the restorecon really fixes this bug and also https://bugzilla.redhat.com/show_bug.cgi?id=849990 (should be closed as a dupe of this one). This bug just needs s/kdesu/polkit auth agent (gnome/kde).
Comment 7 Adam Williamson 2012-08-29 13:28:46 EDT
Discussed at 2012-08-29 blocker review meeting. Turns out this and 849990 are dupes. This is a cleaner bug so we'll mark 849990 as a dupe of this, and transfer the blocker status here. Correcting summary.
Comment 8 Adam Williamson 2012-08-29 13:29:13 EDT
*** Bug 849990 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Grepl 2012-09-03 02:05:10 EDT
I see on my GNOME # ls -Z /etc/pam.d/system-auth-ac -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/pam.d/system-auth-ac # matchpathcon /etc/pam.d/system-auth-ac /etc/pam.d/system-auth-ac system_u:object_r:etc_t:s0 So the problem is the file is re-created with etc_runtime_t label. Anyway it should work with the latest policy build. How is this file re-created? Does it happen only on fresh install from Alpha?
Comment 10 Tomas Mraz 2012-09-04 06:31:25 EDT
The file is created by authconfig during the anaconda kickstart processing AFAIK.
Comment 11 Martin Krizek 2012-09-04 06:58:02 EDT
On F18 Alpha TC5 KDE, I am asked for root password when appropriate. I ran 'Applications -> Administration -> Authentication' and also tried to install a application in Apper and was asked for root password on both.
Comment 12 Daniel Walsh 2012-09-04 16:21:32 EDT
If authconfig was run by firstboot or init it could create a file with this label.
Comment 13 Adam Williamson 2012-09-04 16:34:38 EDT
miroslav: "- Allow polkit-agent-helper to read system-auth-ac" in 3.11.1-14.fc18 is what fixes this, yes? If so, https://admin.fedoraproject.org/updates/FEDORA-2012-12934/selinux-policy-3.11.1-14.fc18 should be marked as fixing this bug. thanks!
Comment 14 Tomas Mraz 2012-09-04 16:40:41 EDT
It can be also run by firstboot.
Comment 15 Miroslav Grepl 2012-09-05 00:19:09 EDT
(In reply to comment #13) > miroslav: "- Allow polkit-agent-helper to read system-auth-ac" in > 3.11.1-14.fc18 is what fixes this, yes? If so, > https://admin.fedoraproject.org/updates/FEDORA-2012-12934/selinux-policy-3. > 11.1-14.fc18 should be marked as fixing this bug. thanks! Yes it allows to read etc_runtime_t also.
Comment 16 Jaroslav Reznik 2012-09-05 09:27:06 EDT
(In reply to comment #14) > It can be also run by firstboot. Ok, this could be the issue - as TC3 was known for non working Firstboot, I bet the firstboot was skipped. As on TC5 with Firstboot properly runned during the first boot, it works for me with selinux-policy-3.11.1-7 as could be found in TC5. Jan, did you use firstboot? Could you retry with TC5 and firstboot?
Comment 17 Adam Williamson 2012-09-07 20:41:00 EDT
firstboot does have code to run 'authconfig-gtk --firstboot' when creating a user. So that ties in. It's in modules/create_user.py . I'm going to mark this as ON_QA. TC6 was a bit busted, but we should be able to confirm for sure that this works OK with TC7/RC1, which should land tonight or tomorrow.
Comment 18 Dan Mashal 2012-09-07 20:55:26 EDT
This is fixed on pretc7-1 netinstall.
Comment 19 Kamil Páral 2012-09-11 09:34:11 EDT
*** Bug 856210 has been marked as a duplicate of this bug. ***
Comment 20 Kamil Páral 2012-09-11 09:35:48 EDT
I just tried this with F18 Alpha RC2 DVD i686 and I still see this problem (bug 856210). Firstboot finished OK, but PackageKit triggers AVC denials.
Comment 21 Kamil Páral 2012-09-11 10:12:19 EDT
$ ls -Z /etc/pam.d/system-auth-ac -rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/pam.d/system-auth-ac
Comment 22 Jaroslav Reznik 2012-09-11 10:26:34 EDT
Strange - there has to be some difference between what's happening on Live (it works) and DVD installation (does not work). But for now, there's option to use latest selinux-policy. Works with 3.11.1-16 (and it's fixed already in -14). Adding Firtsboot maintainer on CC to gather more info.
Comment 23 Kamil Páral 2012-09-11 10:38:39 EDT
I can confirm that when I install from Live, system-auth-ac has 'etc_t' instead of 'etc_runtime_t'.
Comment 24 Adam Williamson 2012-09-11 21:02:47 EDT
For the record, we didn't pull selinux-policy-3.11.1-14.fc18 into Alpha RC2 because it was believed that simply ensuring firstboot worked should fix this. I suspect that https://bugzilla.redhat.com/show_bug.cgi?id=856225 and https://bugzilla.redhat.com/show_bug.cgi?id=855784 *may possibly* be caused by this. 856322 is almost certainly the same thing.
Comment 25 Adam Williamson 2012-09-11 21:03:02 EDT
*** Bug 856322 has been marked as a duplicate of this bug. ***
Comment 26 Adam Williamson 2012-09-12 03:02:12 EDT
So we can certainly fix this by pulling a later selinux-policy. Is that the recommended fix, mgrepl? Do we need to fix the discrepancy between etc_t (live install) and etc_runtime_t (dvd install)? Which one is actually correct? Thanks!
Comment 27 Miroslav Grepl 2012-09-12 03:35:59 EDT
Yes, basically we added the policy fix to make this working with both labels. # matchpathcon /etc/pam.d/system-auth-ac /etc/pam.d/system-auth-ac system_u:object_r:etc_t:s0
Comment 28 Daniel Walsh 2012-09-12 06:52:30 EDT
Adam I think you should pull in the latest selinux-policy, probably always. Since we are reacting to changes in the system as we see them. During freeze we will not be adding any new confined domains. Latest is Build Tag Built by ---------------------------------------- -------------------- ---------------- selinux-policy-3.11.1-18.fc18 f18-updates-candidate mgrepl Fixed in selinux-policy-3.11.1-18.fc18.noarch
Comment 29 Kamil Páral 2012-09-12 07:27:33 EDT
I upgraded to selinux-policy-3.11.1-18.fc18 and I can confirm it fixes the problem with PackageKit. Daniel or Miroslav, can you please push it to Bodhi?
Comment 30 Fedora Update System 2012-09-12 08:32:24 EDT
selinux-policy-3.11.1-18.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-13554/selinux-policy-3.11.1-18.fc18
Comment 31 Fedora Update System 2012-09-12 15:12:38 EDT
Package selinux-policy-3.11.1-18.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-18.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13554/selinux-policy-3.11.1-18.fc18 then log in and leave karma (feedback).
Comment 32 Fedora Update System 2012-09-12 19:51:31 EDT
selinux-policy-3.11.1-18.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Comment 33 Adam Williamson 2012-09-14 13:28:58 EDT
Can folks just re-test and confirm this is fixed in RC3, to make sure we didn't screw up the fix somehow? Thanks.
Comment 34 Kamil Páral 2012-09-17 04:33:00 EDT
Fixed in RC3.