Summary: SELinux is preventing /sbin/setfiles access to a leaked tcp_socket file descriptor. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by the restorecon command. It looks like this is either a leaked descriptor or restorecon output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the tcp_socket. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:setfiles_t:s0-s0:c0.c1023 Target Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Objects tcp_socket [ tcp_socket ] Source restorecon Source Path /sbin/setfiles Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.0.74-17.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-49.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name leaks Host Name (removed) Platform Linux (removed) 2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST 2009 i686 i686 Alert Count 7 First Seen Mon 23 Nov 2009 09:29:48 AM CST Last Seen Thu 26 Nov 2009 11:15:51 PM CST Local ID 78eca36e-a438-402f-b982-1b479a482522 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1259298951.440:34): avc: denied { read write } for pid=6676 comm="restorecon" path="socket:[68624]" dev=sockfs ino=68624 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket node=(removed) type=SYSCALL msg=audit(1259298951.440:34): arch=40000003 syscall=11 success=yes exit=0 a0=961e0b8 a1=961de68 a2=961e140 a3=961de68 items=0 ppid=6675 pid=6676 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-49.fc12,leaks,restorecon,setfiles_t,sshd_t,tcp_socket,read,write audit2allow suggests: #============= setfiles_t ============== allow setfiles_t sshd_t:tcp_socket { read write };
This AVC gets generated after I reboot or login (not sure which). Appears to happen every boot up.
Are you using ldap for user database? There was a known problem with nss_ldap leaking file descriptors in previous versions of Fedora, and I wonder if it is back.
I have 389-ds installed and running, but not in used for login auth. nss_ldap-264-8.fc12.i686 is installed if that is sufficient to trigger it.
Tomas do you have any ideas?
Unfortunately I don't. The sshd should not spawn restorecon at all - at least I do not see any such call in the openssh sources in the F12 package. But I have no other idea how restorecon could get an sshd_t labeled tcp socket even from nss_ldap as sshd is started by default and it would occupy it. And as the reporter is not using the ldap for user info it would not call nss_ldap anyway. d.j., could you please just after reboot try too look up the process with the pid from the AVC ppid number? In the AVC above it would be pid 6675.
It happened again, recently - but I cannot find what the PID wss: Nov 30 16:23:24 embla setroubleshoot: SELinux is preventing /sbin/setfiles access to a leaked tcp_socket file descriptor. For complete SELinux messages. run sealert -l 78eca36e-a438-402f-b982-1b479a482522 # sealert -l 78eca36e-a438-402f-b982-1b479a482522 Summary: SELinux is preventing /sbin/setfiles access to a leaked tcp_socket file descriptor. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by the restorecon command. It looks like this is either a leaked descriptor or restorecon output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the tcp_socket. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:setfiles_t:s0-s0:c0.c1023 Target Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Objects tcp_socket [ tcp_socket ] Source restorecon Source Path /sbin/setfiles Port <Unknown> Host embla.ether.net Source RPM Packages policycoreutils-2.0.74-17.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-49.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name leaks Host Name embla.ether.net Platform Linux embla.ether.net 2.6.31.6-145.fc12.i686.PAE #1 SMP Sat Nov 21 16:12:37 EST 2009 i686 i686 Alert Count 10 First Seen Mon Nov 23 09:29:48 2009 Last Seen Mon Nov 30 16:23:22 2009 Local ID 78eca36e-a438-402f-b982-1b479a482522 Line Numbers Raw Audit Messages node=embla.ether.net type=AVC msg=audit(1259619802.358:67384): avc: denied { read write } for pid=19824 comm="restorecon" path="socket:[185887]" dev=sockfs ino=185887 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket node=embla.ether.net type=SYSCALL msg=audit(1259619802.358:67384): arch=40000003 syscall=11 success=yes exit=0 a0=8d4b0b8 a1=8d4ae68 a2=8d4b140 a3=8d4ae68 items=0 ppid=19823 pid=19824 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=325 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null)
The pid of the parent of the setfiles process is shown in the SYSCALL audit message in the ppid value. In the recent case it was 19823. Please try to get the AVC again and try to find the process.
--- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can reproduce the message at will, easily. I have not been able to find the pid mentioned in the avc. Adding a policy with this makes no more avc's show: allow setfiles_t sshd_t:tcp_socket { read write }; For me to reproduce the avc, i remove the local-policy, and boot. Instant avc. By the time I have a prompt, the pid mentioned is long gone.
What version of the selinux-policy are you using now ?
Just now removed my local-hack, rebooted, and logged in. # ausearch -m avc -ts today ---- time->Sun Jan 17 00:57:06 2010 type=SYSCALL msg=audit(1263711426.549:26): arch=40000003 syscall=11 success=yes exit=0 a0=8e27980 a1=8e27730 a2=8e27a08 a3=8e27730 items=0 ppid=3920 pid=3921 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1263711426.549:26): avc: denied { read write } for pid=3921 comm="restorecon" path="socket:[20532]" dev=sockfs ino=20532 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket pid=3921 is long gone. selinux-policy-3.6.32-66.fc12.noarch
What about the pid 3920 - the pid of the parent process?
Can you describe how to reproduce the bug.
pid 3920 is also long gone. Jan- Reproduce is simple. Happens on every boot/login without the policy login mentioned above. Nothing special required.
The only place I can think of that would spawn such restorecon process is some PAM module. What PAM modules do you have in /etc/pam.d/sshd and /etc/pam.d/system-auth?
% cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_access.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so % cat /etc/pam.d/sshd #%PAM-1.0 auth required pam_sepermit.so #auth required pam_tally2.so deny=4 even_deny_root unlock_time=1200 auth required pam_tally2.so deny=5 onerr=fail unlock_time=1200 auth required pam_cap.so debug auth include password-auth account required pam_nologin.so account required pam_tally2.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke session required pam_namespace.so session include password-auth
What about password-auth?
% cat /etc/pam.d/password-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_access.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
I see there is pam_namespace module in the sshd session stack. So this is probably the source of the restorecon call as it calls restorecon on initialization of a new directory instance. As this happens when a pam_open_session() is called, sshd should be fixed to set FD_CLOEXEC on the socket fd obtained from accept() in server_accept_loop() function.
openssh-5.3p1-15.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openssh-5.3p1-15.fc12
can you test the openssh-5.3p1-15.fc12 and report if it works.
WAS: openssh-5.2p1-31.fc12.i686 # ausearch -m avc -ts yesterday ---- time->Tue Jan 19 23:59:36 2010 type=SYSCALL msg=audit(1263967176.801:55086): arch=40000003 syscall=11 success=yes exit=0 a0=9298990 a1=9298740 a2=9298a18 a3=9298740 items=0 ppid=2809 pid=2810 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1263967176.801:55086): avc: denied { read write } for pid=2810 comm="restorecon" path="socket:[14943]" dev=sockfs ino=14943 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket ---- time->Tue Jan 19 23:59:36 2010 type=SYSCALL msg=audit(1263967176.907:55087): arch=40000003 syscall=11 success=yes exit=0 a0=9f359a8 a1=9f35580 a2=9f35a18 a3=9f35580 items=0 ppid=2815 pid=2816 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1263967176.907:55087): avc: denied { read write } for pid=2816 comm="restorecon" path="socket:[14943]" dev=sockfs ino=14943 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket PIDs 2810 and 2816 are long gone before I have a prompt. apply new openssh, reboot. new avcs: # rpm -q openssh openssh-5.3p1-15.fc12.i686 # ausearch -m avc -ts today ---- time->Wed Jan 20 00:05:52 2010 type=SYSCALL msg=audit(1263967552.097:58496): arch=40000003 syscall=11 success=yes exit=0 a0=9cc3990 a1=9cc3740 a2=9cc3a18 a3=9cc3740 items=0 ppid=3541 pid=3542 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1263967552.097:58496): avc: denied { read write } for pid=3542 comm="restorecon" path="socket:[16577]" dev=sockfs ino=16577 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket ---- time->Wed Jan 20 00:05:52 2010 type=SYSCALL msg=audit(1263967552.202:58497): arch=40000003 syscall=11 success=yes exit=0 a0=84099a8 a1=8409580 a2=8409a18 a3=8409580 items=0 ppid=3547 pid=3548 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1263967552.202:58497): avc: denied { read write } for pid=3548 comm="restorecon" path="socket:[16577]" dev=sockfs ino=16577 scontext=system_u:system_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket PIDs 3542 and 3548 are gone before I have a prompt. % pstree -p |grep ssh |-ssh-agent(3592) |-sshd(1885)---sshd(3538)---sshd(3553)---zsh(3554)-+-grep(4503) Audit2allow still wants: #============= setfiles_t ============== allow setfiles_t sshd_t:tcp_socket { read write };
Unfortunately with the cloexec set on the listen socket I am out of the ideas how the sshd_t socket could leak. Note that the listening socket is explicitely closed in the child process that is handling the incomming connection.
What about the accept socket.
Dan, I made a typo above the sentence should be "Unfortunately with the cloexec set on the accept socket...."
openssh-5.3p1-15.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openssh'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0857
To be clear, that is the version I tested in #22 - and it still reports AVCs and leaks.
If you comment out pam_namespace in /etc/pam.d/sshd, does it still happen?
Updated to openssh 5.3p1-16.fc12 -- Did not resolve. Commented out pam_namespace -- Did stop the AVCs. What tipped you off that it might be the culprit?
please can you test openssh 5.3p1-20.fc13 from rawhide?
No AVC with 5.3p1-20. Was this an upstream patch?
not yet, I'll make update tp F-12 and send it upstream ASAP, thanks for the help.
openssh-5.3p1-18.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openssh-5.3p1-18.fc12
openssh-5.3p1-18.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openssh'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1222
*** Bug 562453 has been marked as a duplicate of this bug. ***
openssh-5.3p1-15.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.