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.
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".
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?
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.
Are you able to re-create it? I allowed this rule to make this working until we have a fix.
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.
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).
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.
*** Bug 849990 has been marked as a duplicate of this bug. ***
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?
The file is created by authconfig during the anaconda kickstart processing AFAIK.
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.
If authconfig was run by firstboot or init it could create a file with this label.
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!
It can be also run by firstboot.
(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.
(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?
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.
This is fixed on pretc7-1 netinstall.
*** Bug 856210 has been marked as a duplicate of this bug. ***
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.
$ 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
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.
I can confirm that when I install from Live, system-auth-ac has 'etc_t' instead of 'etc_runtime_t'.
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.
*** Bug 856322 has been marked as a duplicate of this bug. ***
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!
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
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
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?
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
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).
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.
Can folks just re-test and confirm this is fixed in RC3, to make sure we didn't screw up the fix somehow? Thanks.
Fixed in RC3.