Bug 541809 - SELinux is preventing /sbin/setfiles access to a leaked tcp_socket file descriptor.
SELinux is preventing /sbin/setfiles access to a leaked tcp_socket file descr...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
12
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Jan F. Chadima
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:f44ee62283e...
:
: 562453 (view as bug list)
Depends On:
Blocks: 559542 642935
  Show dependency treegraph
 
Reported: 2009-11-27 00:26 EST by d. johnson
Modified: 2010-10-14 04:40 EDT (History)
7 users (show)

See Also:
Fixed In Version: openssh-5.3p1-15.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 559542 (view as bug list)
Environment:
Last Closed: 2010-03-08 22:33:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description d. johnson 2009-11-27 00:26:08 EST
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 };
Comment 1 d. johnson 2009-11-27 00:33:00 EST
This AVC gets generated after I reboot or login (not sure which).  Appears to happen every boot up.
Comment 2 Daniel Walsh 2009-11-30 09:56:36 EST
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.
Comment 3 d. johnson 2009-11-30 11:37:54 EST
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.
Comment 4 Daniel Walsh 2009-11-30 14:28:53 EST
Tomas do you have any ideas?
Comment 5 Tomas Mraz 2009-11-30 15:23:59 EST
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.
Comment 6 d. johnson 2009-11-30 19:44:08 EST
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)
Comment 7 Tomas Mraz 2009-12-01 02:42:31 EST
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.
Comment 8 Carl G. 2010-01-16 22:18:49 EST
---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 d. johnson 2010-01-17 01:09:12 EST
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.
Comment 10 Carl G. 2010-01-17 01:27:35 EST
What version of the selinux-policy are you using now ?
Comment 11 d. johnson 2010-01-17 01:59:37 EST
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
Comment 12 Tomas Mraz 2010-01-18 03:35:35 EST
What about the pid 3920 - the pid of the parent process?
Comment 13 Jan F. Chadima 2010-01-18 04:07:47 EST
Can you describe how to reproduce the bug.
Comment 14 d. johnson 2010-01-18 10:16:10 EST
pid 3920 is also long gone.

Jan- Reproduce is simple.  Happens on every boot/login without the policy login mentioned above.  Nothing special required.
Comment 15 Tomas Mraz 2010-01-18 10:20:33 EST
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?
Comment 16 d. johnson 2010-01-18 11:50:23 EST
% 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
Comment 17 Daniel Walsh 2010-01-18 12:16:47 EST
What about password-auth?
Comment 18 d. johnson 2010-01-18 13:26:38 EST
% 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
Comment 19 Tomas Mraz 2010-01-18 13:56:15 EST
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.
Comment 20 Fedora Update System 2010-01-19 12:37:30 EST
openssh-5.3p1-15.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openssh-5.3p1-15.fc12
Comment 21 Jan F. Chadima 2010-01-19 12:39:49 EST
can you test the openssh-5.3p1-15.fc12 and report if it works.
Comment 22 d. johnson 2010-01-20 01:16:33 EST
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 };
Comment 23 Tomas Mraz 2010-01-20 02:40:51 EST
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.
Comment 24 Daniel Walsh 2010-01-20 15:25:23 EST
What about the accept socket.
Comment 25 Tomas Mraz 2010-01-20 16:46:12 EST
Dan, I made a typo above the sentence should be "Unfortunately with the cloexec set on the accept socket...."
Comment 26 Fedora Update System 2010-01-20 19:12:04 EST
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
Comment 27 d. johnson 2010-01-21 23:36:40 EST
To be clear, that is the version I tested in #22 - and it still reports AVCs and leaks.
Comment 28 Tomas Mraz 2010-01-22 02:51:41 EST
If you comment out pam_namespace in /etc/pam.d/sshd, does it still happen?
Comment 29 d. johnson 2010-01-22 22:08:12 EST
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?
Comment 30 Jan F. Chadima 2010-01-25 14:15:39 EST
please can you test openssh 5.3p1-20.fc13 from rawhide?
Comment 31 d. johnson 2010-01-27 08:14:03 EST
No AVC with 5.3p1-20.

Was this an upstream patch?
Comment 32 Jan F. Chadima 2010-01-28 04:10:50 EST
not yet, I'll make update tp F-12 and send it upstream ASAP, thanks for the help.
Comment 33 Fedora Update System 2010-01-28 07:12:16 EST
openssh-5.3p1-18.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openssh-5.3p1-18.fc12
Comment 34 Fedora Update System 2010-01-28 22:34:04 EST
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
Comment 35 Daniel Walsh 2010-02-08 14:43:48 EST
*** Bug 562453 has been marked as a duplicate of this bug. ***
Comment 36 Fedora Update System 2010-03-08 22:33:48 EST
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.

Note You need to log in before you can comment on or make changes to this bug.