Hide Forgot
SELinux is preventing /usr/sbin/sshd from read, write access on the file .pam-systemd-lock. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that sshd should be allowed read write access on the .pam-systemd-lock 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 sshd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:crond_var_run_t:s0 Target Objects .pam-systemd-lock [ file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host (removed) Source RPM Packages openssh-server-5.6p1-31.fc15.1 Target RPM Packages Policy RPM selinux-policy-3.9.16-30.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.8-32.fc15.i686.PAE #1 SMP Mon Jun 13 19:55:27 UTC 2011 i686 i686 Alert Count 10 First Seen Tue 28 Jun 2011 01:26:01 PM EDT Last Seen Thu 30 Jun 2011 01:37:07 PM EDT Local ID 886e56a4-abeb-475e-911f-fbc67155a1d7 Raw Audit Messages type=AVC msg=audit(1309455427.119:36794): avc: denied { read write } for pid=27705 comm="sshd" name=".pam-systemd-lock" dev=tmpfs ino=22223 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:crond_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1309455427.119:36794): arch=i386 syscall=open success=no exit=EACCES a0=72bea4 a1=a8142 a2=180 a3=21c9e648 items=0 ppid=1631 pid=27705 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=100 fsgid=0 tty=(none) ses=5114 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) Hash: sshd,sshd_t,crond_var_run_t,file,read,write audit2allow #============= sshd_t ============== allow sshd_t crond_var_run_t:file { read write }; audit2allow -R #============= sshd_t ============== allow sshd_t crond_var_run_t:file { read write };
systemd guys what is the .pam-systemd-lock file?
John where is this file located?
Dan, It is in /run/user/ /run/user/.pam-systemd-lock
John you had a similar bug with lots of mislabeled files, did relabeling your system fix the problems?
When I found this problem, I ran restorecon -Rvn /run as a matter of inquisitiveness and found many badly labeled files, so I filed Bug 718631. Relabeling did not fix the bad labels. Since /run is a tmpfs file system, /run is recreated at boot. That would indicate to me that there are a lot of packages creating with the wrong contexts or the policy expects the wrong contexts.
(In reply to comment #1) > systemd guys what is the .pam-systemd-lock file? It's a lock file /run/user/.pam-systemd-lock we use in pam_systemd to serialize access to the cgroup, so that we can safely decide when a user's cgroup can be killed. All programs that provide a PAM service and thus end up loading pam_systemd will have to access this file.
We have found john's problem being an empty /etc/selinux/targeted/files/file_contexts.subs file. We have not figured out how this got cleared. I am suspecting some semanage command executed in the post install of an rpm is causing this. John can you see if someone is playing with equivalence in post install. # rpm -qa --scripts > /tmp/scripts # grep -- semanage.*-e /tmp/scripts
# rpm -qa --scripts > /tmp/scripts # grep -- semanage.*-e /tmp/scripts yields nothing.
Strange, Did you install from a live image?
No. Installed from DVD image. I got it from the torrent.
I have no clue what is going on then. You are the only one I have heard about this from. But you have seen it on multiple machines.
Well the labels were right, only restorecon thought they were wrong, so I guess everything (almost) was working correctly so who would notice? The AVC for the sshd did not prevent ssh from working. I just got tired of seeing it in sealert, so I reported the bug. I was surprised that I was the first. I only noticed the problem with /run when out of curiosity, I ran restorecon -Rvn against it. Otherwise, I would have never known about this either. I guess what I am saying is it may be prevalent with many (most) systems but is going un-noticed.
Let's clean up this issue. Is your /etc/selinux/targeted/files/file_contexts.subs file still empty?
After deleting file and reinstalling the policy the correct file_contexts.subs was installed. I have no idea how the empty file got installed. It happened on two FC15 servers both with fresh installs from the DVD iso gotten from the torrent.