Description of problem: SELinux is preventing /usr/lib/polkit-1/polkit-agent-helper-1 from 'append' accesses on the file /home/pdestefa/.xsession-errors. ***** Plugin restorecon (93.9 confidence) suggests ************************* If you want to fix the label. /home/pdestefa/.xsession-errors default label should be xdm_home_t. Then you can run restorecon. Do # /sbin/restorecon -v /home/pdestefa/.xsession-errors ***** Plugin leaks (6.10 confidence) suggests ****************************** If you want to ignore polkit-agent-helper-1 trying to append access the .xsession-errors file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/lib/polkit-1/polkit-agent-helper-1 /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (1.43 confidence) suggests *************************** If you believe that polkit-agent-helper-1 should be allowed append access on the .xsession-errors 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 polkit-agent-he /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:system_r:policykit_auth_t:s0-s0:c0.c1 023 Target Context system_u:object_r:ecryptfs_t:s0 Target Objects /home/pdestefa/.xsession-errors [ file ] Source polkit-agent-he Source Path /usr/lib/polkit-1/polkit-agent-helper-1 Port <Unknown> Host (removed) Source RPM Packages polkit-0.107-4.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-76.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.7.6-201.fc18.x86_64 #1 SMP Mon Feb 4 15:54:08 UTC 2013 x86_64 x86_64 Alert Count 3 First Seen 2013-02-14 13:10:13 PST Last Seen 2013-02-14 14:50:10 PST Local ID f88d2340-3e97-4d79-a0c3-dca5f40cfc02 Raw Audit Messages type=AVC msg=audit(1360882210.58:411): avc: denied { append } for pid=2849 comm="polkit-agent-he" path="/home/pdestefa/.xsession-errors" dev="ecryptfs" ino=655402 scontext=unconfined_u:system_r:policykit_auth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ecryptfs_t:s0 tclass=file type=SYSCALL msg=audit(1360882210.58:411): arch=x86_64 syscall=execve success=yes exit=0 a0=3945a07388 a1=7fff866fa780 a2=7fff866fa9f8 a3=11 items=0 ppid=1862 pid=2849 auid=1002 uid=1002 gid=1002 euid=0 suid=0 fsuid=0 egid=1002 sgid=1002 fsgid=1002 ses=1 tty=(none) comm=polkit-agent-he exe=/usr/lib/polkit-1/polkit-agent-helper-1 subj=unconfined_u:system_r:policykit_auth_t:s0-s0:c0.c1023 key=(null) Hash: polkit-agent-he,policykit_auth_t,ecryptfs_t,file,append audit2allow #============= policykit_auth_t ============== allow policykit_auth_t ecryptfs_t:file append; audit2allow -R #============= policykit_auth_t ============== allow policykit_auth_t ecryptfs_t:file append; Additional info: hashmarkername: setroubleshoot kernel: 3.7.6-201.fc18.x86_64 type: libreport
Is your entire homedir labeled ecryptfs_t? ls -lZ ~/
Yes, it appears so. I'm not sure if it's always been that way or not; I assume not, but I don't remember. Recently, after an update, and a couple weeks after upgrading to F18, I checked for .rpmnew files in /etc/ and found many. I when through them all and must have made a mistake with the PAM files because eCryptFS wouldn't mount my home directory at login. I tried to reconstruct the correct configuration from on-line hints and my memory, but it didn't work. Eventually, I had to use AC with the --enableecryptfs option. This installed a very different eCryptFS configuration than I had previously--all the eCryptfs PAM modules are in postlogin--but I can login, now. Thanks for your help.
Paul, if you run restorecon -R -v /home Does it fix the labels?
No, but it made a small change on some of the encrypted files: restorecon reset /home/.ecryptfs context unconfined_u:object_r:home_root_t:s0->system_u:object_r:home_root_t:s0 restorecon reset /home/.ecryptfs/pdestefa/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWZz6oeMHOUt3-QD3MnV56gYUQa4sdvFL-sD3-aJvyA1TzVLnMVlSPQDbE-- context system_u:object_r:ecryptfs_t:s0->unconfined_u:object_r:ecryptfs_t:s0 restorecon reset /home/.ecryptfs/pdestefa/.Private/ECRYPTFS_FNEK_ENCRYPTED.FXZz6oeMHOUt3-QD3MnV56gYUQa4sdvFL-sDPgEWPrO-7T5OqObUWcELyRY3ZEtVMyqsxXm9XX-gIfc- context system_u:object_r:ecryptfs_t:s0->unconfined_u:object_r:ecryptfs_t:s0 restorecon reset /home/.ecryptfs/pdestefa/.Private/ECRYPTFS_FNEK_ENCRYPTED.FXZz6oeMHOUt3-QD3MnV56gYUQa4sdvFL-sDa.HWISCgLYxdLIJ06BxJEHVNEhepUf2NbF-St.28lnc- context system_u:object_r:ecryptfs_t:s0->unconfined_u:object_r:ecryptfs_t:s0
How about if you execute semanage fcontext -a -e /home /home/.ecryptfs Then run restorecon.
semanage says that's already configured: semanage fcontext -a -e /home /home/.ecryptfs /sbin/semanage: Equivalence class for /home/.ecryptfs already exists When I run restorecon, again, it does nothing. Also, I had to use -F to get restorecon to do anything at all in the earlier post. Do I need to remount my private directory after this earlier change? I haven't done that yet.
Logging out and logging in didn't help.
Yes, all needed changes should be a part of ecryptfs-mount setup script. This is a correct labeling and I believe we should dontaudit it. I guess everything works correctly, right?
I'm not sure you are asking me, but if you are, here is my answer. This is a change from F17, so I have to assume this is incorrect behavior. I doubt this is the correct labeling, so perhaps this is really another issue, but I can't be sure. What eCryptFS-mount setup script are you talking about? This bug need to be reassigned to component eCryptFS to find out. Is someone from that group already CC-ed on this bug? If they say this is the correct labeling and I assume polkit-agent-helper is intentionally writing to .xession-errors--obviously, it is--then for sure this is the wrong behavior. Either it needs SELinux access or it needs to never open that file for writing. If they say this is not the correct label for my home directory, then we can try polkit-agent-helper again after I get the labels fixed.
I did dontaudit it.
Sorry Miroslav, I don't know what that means. What did you do?
It means I added a fix to the policy.
selinux-policy-3.11.1-82.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-82.fc18
Package selinux-policy-3.11.1-82.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-82.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-3309/selinux-policy-3.11.1-82.fc18 then log in and leave karma (feedback).
selinux-policy-3.11.1-82.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.