Bug 541809

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.