Bug 616838

Summary: SELinux is preventing /usr/bin/ssh access to a leaked /dev/ptmx file descriptor.
Product: Red Hat Enterprise Linux 6 Reporter: Matěj Cepl <mcepl>
Component: gvfsAssignee: Tomáš Bžatek <tbzatek>
Status: CLOSED ERRATA QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: dwalsh, mgrepl, mishu, tbzatek, tpelka, tsmetana, vbenes
Target Milestone: rcKeywords: RHELNAK, SELinux
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: gvfs-1.4.3-10.el6 Doc Type: Bug Fix
Doc Text:
Cause: A filedescriptor which was unused was not closed after fork Consequence: A SELinux alert has been generated Fix: Leaked filedescriptor is now closed after fork Result: No SELinux alert is generated
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 13:02:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to close /dev/ptmx after fork none

Description Matěj Cepl 2010-07-21 14:09:26 UTC
Absolutely no idea, what happened.
-----------------------------
SELinux is preventing /usr/bin/ssh access to a leaked /dev/ptmx file descriptor.

Podrobný popis:

[ssh je v toleratním režimu (ssh_t). Přístup byl povolen.]

SELinux denied access requested by the ssh command. It looks like this is either
a leaked descriptor or ssh 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 /dev/ptmx.
You should generate a bugzilla on selinux-policy, and it will get routed to the
appropriate package. You can safely ignore this avc.

Povolení přístupu:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385)

Další informace:

Kontext zdroje                staff_u:staff_r:ssh_t:s0-s0:c0.c1023
Kontext cíle                 system_u:object_r:ptmx_t:s0
Objekty cíle                 /dev/ptmx [ chr_file ]
Zdroj                         ssh
Cesta zdroje                  /usr/bin/ssh
Port                          <Neznámé>
Počítač                    johanka.ceplovi.cz
RPM balíčky zdroje          openssh-clients-5.3p1-19.el6
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.7.19-32.el6
Selinux povolen               True
Typ politiky                  targeted
Vynucovací režim            Enforcing
Název zásuvného modulu     leaks
Název počítače            johanka.ceplovi.cz
Platforma                     Linux johanka.ceplovi.cz 2.6.32-44.1.el6.x86_64 #1
                              SMP Wed Jul 14 18:51:29 EDT 2010 x86_64 x86_64
Počet upozornění           1
Poprvé viděno               St 21. červenec 2010, 15:09:32 CEST
Naposledy viděno             St 21. červenec 2010, 15:09:32 CEST
Místní ID                   9a5801b0-2bac-4bf6-b5a3-e1c6cfff9510
Čísla řádků              

Původní zprávy auditu      

node=johanka.ceplovi.cz type=AVC msg=audit(1279717772.300:4270): avc:  denied  { read write } for  pid=5455 comm="ssh" path="/dev/ptmx" dev=devtmpfs ino=5004 scontext=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file

node=johanka.ceplovi.cz type=SYSCALL msg=audit(1279717772.300:4270): arch=c000003e syscall=59 success=yes exit=0 a0=7fff1e4e0b86 a1=7fff1e4e0c40 a2=15e6440 a3=7f9bc508b9d0 items=0 ppid=5412 pid=5455 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts17 ses=1 comm="ssh" exe="/usr/bin/ssh" subj=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 key=(null)

Comment 2 RHEL Program Management 2010-07-21 14:37:42 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Jan F. Chadima 2010-09-16 12:25:57 UTC
There is no occurence of string "ptmx" in the ssh binary. There is only one occurence of string "ptmx" in the dynamic libraries loaded by ssh.... in libc.so.6
rerouting to glibc

Comment 4 Daniel Walsh 2010-09-16 12:29:04 UTC
This is not a problem with ssh but with the tool that launched ssh.  Matej what app were you running that launched ssh?

Comment 5 Daniel Walsh 2010-09-16 12:30:00 UTC
Or it could be the Konsole?  Or terminal you were running this in?

Comment 7 Tomáš Bžatek 2010-09-17 08:21:55 UTC
Created attachment 447934 [details]
patch to close /dev/ptmx after fork

Oh yes, that could be gvfsd-sftp, we do open /dev/ptmx indeed and don't close it for child process after fork. Can you please test the attached patch?

Comment 8 Tomáš Bžatek 2010-11-12 16:14:37 UTC
Patch has been pushed to gvfs git master: http://git.gnome.org/browse/gvfs/commit/?id=070b4c4968591b612f3db1aafd9bba07a4ee0004

Comment 10 Tomáš Bžatek 2011-01-31 10:47:54 UTC
Forgot to tell that in order to reproduce this issue, user must be in a staff_u context. See http://danwalsh.livejournal.com/18312.html

(In reply to comment #0)
> Kontext zdroje                staff_u:staff_r:ssh_t:s0-s0:c0.c1023

Comment 13 Daniel Walsh 2011-02-04 14:18:59 UTC
Sorry no, but are you testing with the fix applied?

Comment 14 Tomas Pelka 2011-02-04 14:25:11 UTC
Yes and no AVCs in both cases.

Comment 15 Daniel Walsh 2011-02-04 14:53:19 UTC
I would mark this as closed, since we found a potential cause.  If it happens again we can reopen it.

Comment 17 Tomáš Bžatek 2011-04-11 15:37:12 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: A filedescriptor which was unused was not closed after fork

Consequence: A SELinux alert has been generated

Fix: Leaked filedescriptor is now closed after fork

Result: No SELinux alert is generated

Comment 18 errata-xmlrpc 2011-05-19 13:02:54 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0536.html