Summary: SELinux is preventing /usr/libexec/gdm-session-worker "read write" access on .pam-systemd-lock. Detailed Description: SELinux denied access requested by gdm-session-wor. It is not expected that this access is required by gdm-session-wor and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:crond_var_run_t:s0 Target Objects .pam-systemd-lock [ file ] Source gdm-session-wor Source Path /usr/libexec/gdm-session-worker Port <Unknown> Host (removed) Source RPM Packages gdm-2.31.90-1.fc14 Target RPM Packages Policy RPM selinux-policy-3.8.8-14.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.35.2-9.fc14.i686.PAE #1 SMP Tue Aug 17 22:36:11 UTC 2010 i686 i686 Alert Count 1 First Seen Thu 26 Aug 2010 04:03:33 AM CEST Last Seen Thu 26 Aug 2010 04:03:33 AM CEST Local ID 99d7dc56-1ca4-4116-8ea9-eb7bea8b9853 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1282788213.989:153): avc: denied { read write } for pid=1727 comm="gdm-session-wor" name=".pam-systemd-lock" dev=sda8 ino=390524 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:crond_var_run_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1282788213.989:153): arch=40000003 syscall=5 success=no exit=-13 a0=ce97f8 a1=a0142 a2=180 a3=87ed550 items=0 ppid=1249 pid=1727 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=3 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash String generated from catchall,gdm-session-wor,xdm_t,crond_var_run_t,file,read,write audit2allow suggests: #============= xdm_t ============== allow xdm_t crond_var_run_t:file { read write };
This looks like a leaked file descriptor. Not sure if the bug is in systemd, pam cron or xdm. Who creates .pam-systemd-lock?
I suppose pam_systemd does.
/var/run/user should be owned by the systemd package and then we can add a label to allow pam auth executables to create content within that directory.
Hmm, note that /var/run will sooner or later be mounted from tmpfs. I can add a ghosted ownership dir, but I am not sure this is all you need, Dan?
The problem is multiple programs are going to be able to create/read/write the content of the directory. But each one controls their own /var/run content. So I don't want to have to allow every app that user pam_systemd to have full access to every other apps /var/run content. If the directory is going to be transient, we will need the directory created and labeled at boot time. mkdir /var/run/user restorecon /var/run/user
Ghosting does no good since rpm will not put down the original label. In the case of this bug. cron was the first app to run pam_systemd so it created the directory and files with its labels.
OK, so what about this: 1) I'll now add /var/run/user as %ghost dir to the systemd package, this should make things work properly for now 2) I'll also add mkdir /var/run/user and restorecon /var/run/user to our var-run.service which is supposed to be run after the /var/run dir is mounted from tmpdir. We currently don't enable this service on F14, but then it is clear how this will work eventually, and other distros who might already want to use this service will get things right.
I am labeling it var_auth_t which all of the login domains should be able to write to. Fixed in selinux-policy-3.9.0-1.fc14
Urks, didn't see your comment on %ghost. I have now prepped a package without %ghost.
systemd-8-3.fc14,initscripts-9.17-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-8-3.fc14,initscripts-9.17-2.fc14
initscripts-9.17-2.fc14, systemd-8-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.