Bug 827109 - SELinux is preventing /usr/sbin/sshd from 'name_connect' accesses on the tcp_socket .
SELinux is preventing /usr/sbin/sshd from 'name_connect' accesses on the tcp_...
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-05-31 11:59 EDT by David
Modified: 2012-08-21 05:57 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-21 05:57:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David 2012-05-31 11:59:54 EDT
libreport version: 2.0.10
executable:     /usr/bin/python2.7
hashmarkername: setroubleshoot
kernel:         3.3.7-1.fc17.x86_64
time:           Thu 31 May 2012 08:59:06 AM PDT

:SELinux is preventing /usr/sbin/sshd from 'name_connect' accesses on the tcp_socket .
:*****  Plugin catchall (100. confidence) suggests  ***************************
:If you believe that sshd should be allowed name_connect access on the  tcp_socket by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
: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:vnc_port_t:s0
:Target Objects                 [ tcp_socket ]
:Source                        sshd
:Source Path                   /usr/sbin/sshd
:Port                          5900
:Host                          (removed)
:Source RPM Packages           openssh-server-5.9p1-22.fc17.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-125.fc17.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.3.7-1.fc17.x86_64 #1 SMP Mon May 21
:                              22:32:19 UTC 2012 x86_64 x86_64
:Alert Count                   3
:First Seen                    Thu 31 May 2012 08:56:16 AM PDT
:Last Seen                     Thu 31 May 2012 08:58:39 AM PDT
:Local ID                      9e5c5c5b-0ab4-44c5-8d72-8704a9f26374
:Raw Audit Messages
:type=AVC msg=audit(1338479919.923:180): avc:  denied  { name_connect } for  pid=2854 comm="sshd" dest=5900 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket
:type=SYSCALL msg=audit(1338479919.923:180): arch=x86_64 syscall=connect success=no exit=EACCES a0=8 a1=7fa6d6adc770 a2=10 a3=7fa6d3606cc1 items=0 ppid=847 pid=2854 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=8 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
:Hash: sshd,sshd_t,vnc_port_t,tcp_socket,name_connect
:audit2allowunable to open /sys/fs/selinux/policy:  Permission denied
:audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
Comment 1 Daniel Walsh 2012-05-31 13:28:21 EDT
How did you get this to happen?
Comment 2 David 2012-06-02 13:47:48 EDT
Hi Daniel,

I just tried logging into the machine as its got vino running.  Without running selinux in permissive you cant control the desktop.

I made a local policy and i now can connect and control desktop in enforcing.
Comment 3 Miroslav Grepl 2012-06-04 08:59:57 EDT
If you switch to permissive mode and use the vino, are you getting more AVC msgs then?

# ausearch -m avc -ts recent
Comment 4 David 2012-06-04 10:57:50 EDT
Yes I get an avc triggered when a machine connects via vino. It's after you authenticate to vino. But naturally this time on the remote machine you get the desktop showing up.

However once I made a local policy I receive no more audits and you can connect with enorcing on.
Comment 5 Daniel Walsh 2012-06-04 11:20:45 EDT
Adding openssh people. 

I would have thought this would happen under priv sep process.
Comment 6 Petr Lautrbach 2012-06-05 04:25:43 EDT
Can you provide more details how you connect to vino and also which AVCs you get when you run vino in permissive mode pleasE?

I am not able to reproduce this problem. vino-server is running for
test-vino user:

staff_u:staff_r:staff_t:s0      504       3140  3.4  0.2 614000 11332 ?        Sl   10:15   0:00 /usr/libexec/vino-server

and from remote client I run:
$ vncviewer -via test-vino@malas localhost

and I'm there. There is no sshd_t process connected to vino related socket:

malas # lsof -Z -n -i :5900
vino-serv 4512 staff_u:staff_r:staff_t:s0 test-vino   14u  IPv6 409982       TCP *:rfb (LISTEN)
vino-serv 4512 staff_u:staff_r:staff_t:s0 test-vino   15u  IPv4 409983       TCP *:rfb (LISTEN)
vino-serv 4512 staff_u:staff_r:staff_t:s0 test-vino   17u  IPv6 407846       TCP [::1]:rfb->[::1]:48846 (ESTABLISHED)
sshd      4521 staff_u:staff_r:staff_t:s0 test-vino    9u  IPv6 409351       TCP [::1]:48846->[::1]:rfb (ESTABLISHED)

malas # getenforce

malas # rpm -q openssh selinux-policy
Comment 7 David 2012-06-05 11:32:07 EDT
I am connecting to VNC externally over the Internet using a ssh tunnel, therefore it's using SSH its not pure VNC only.

It's not secure to open the vino server directly to the Internet with a weak 8 character password maximum you have to tunnel over SSH. This also encrypts the vino session as well.

It should be included in the base selinux-policy.

Yes if I purely connect LAN to LAN in a pure vino session it does not invoke SSH, but again as I mention this is not secure and I block VNC access from the WAN into the LAN only allow connection over SSH,

Comment 8 Petr Lautrbach 2012-06-05 11:50:17 EDT
(In reply to comment #7)
> I am connecting to VNC externally over the Internet using a ssh tunnel,
> therefore it's using SSH its not pure VNC only.

By default, "vncviewer -via <gateway" invokes ssh local port forwarding
and creates tcp tunnel, see vncviewer(1). So I use ssh tunnel too 
but without any problem and I need namely commands you use to 
reproduce your problem. All AVCs generated in permissive mode
would be helpful as well
Comment 9 David 2012-06-05 15:01:05 EDT
No problem. Its actually tunnelling SSH into my main WAN/LAN server, then over the LAN to the PC.

type=AVC msg=audit(1338479656.760:134): avc:  denied  { name_connect } for  pid=2788 comm="sshd" dest=5900 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket

I am also using my ipad with an app called iSSH

This did not happen with FC16. I know there are new alerts with FC17 to do with gnome / desktop. But this blocked access to the desktop. Its right at the last authentication where you pass the passphase to vino and it just opens up to return the desktop and it stops at a black screen.

We do run our own DNS server on the LAN / WAN gateway server.

Comment 10 Harald H. 2012-08-02 09:43:37 EDT
Hi I had exactly the same problem, my setup:
*) headless server
*) sometimes I need an xwindow
*) So I ssh to the computer, start vncserver (so no 24/7) and use ssh-port-forwarding.
*) I don't want to open firewall ports as I use vncserver only occasionally, so ssh would be the way to go for me.

*) Created own policy as proposed in the report.
*) A tip regarding fedora 16 (setsebool -P sshd_forward_ports 1) didn't work. sshd_forward_ports doesn't seem to be a se-parameter any more ... .

Could you reactivate sshd_forward_ports or provide a more natural way than creating a own policy?
Comment 11 Harald H. 2012-08-02 09:55:23 EDT
Sorry not reading that it's about vino-server, I'm using tigervnc-server and most time I'm using putty with port-forwarding from a windows-machine.

But the selinux-report here is exactly the same, so I assume it shouldn't be a new bug, should it?

my avc-denial (should be the same, but for the sake of completeness)

type=AVC msg=audit(1343913072.596:110): avc:  denied  { name_connect } for  pid=1399 comm="sshd" dest=5901 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket
Comment 12 Petr Lautrbach 2012-08-02 10:18:35 EDT
Do you use a ssh root account to create ssh port forwarding? Can you paste an  output of

$ ps axfZ | grep sshd
Comment 13 Petr Lautrbach 2012-08-02 11:10:32 EDT
I'm finally able to reproduce this issue but only with a root account. The thing is that the privilege separation is not applied to the root account hence a sshd process related to the root session, which establishes port-forwarding, is run as a sshd_t context:

 $ ssh -L 2222:localhost:12345 root@f17-openssh
root@f17-openssh's password: 

system_u:system_r:sshd_t:s0-s0:c0.c1023 12639 ? Ss    0:00 /usr/sbin/sshd -D
system_u:system_r:sshd_t:s0-s0:c0.c1023 12839 ? Ss    0:00  \_ sshd: root@pts/0    
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 12843 pts/0 Ss   0:00      \_ -bash

another shell:
$ nc localhost 2222


type=AVC msg=audit(1343919816.414:6408): avc:  denied  { name_connect } for  pid=12839 comm="sshd" dest=12345 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket

Please try this [1] scratch build if it solves your problem

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4351028
Comment 14 Harald H. 2012-08-03 03:47:45 EDT
You are completely right! As I need to start vncserver occasionally I logged in with my root account, started vnc, did some ajustments/tests on the grafical interface, stopped it and exited.

I know this is bad behaviour (using root directly), I didn't see that this is the reason for this behaviour.

So I think I have two options:
*) login with root, start the server, logout
   login with a "normal" user with port-forwarding
   enjoy :-)
*) give sudo rights to my user, start the server
   enjoy :-)

Both tested and it works, perhaps the reporter has the same problem and this shouldn't be a bug. 

Thanks for pointing pointing out!!
Comment 15 Petr Lautrbach 2012-08-03 04:56:30 EDT
This is a bug and I believe that build from #c13 fixes this issue, 
at least it fixed it for me in my testing environment. I'll push regular update soon.

Thanks for the report and testing.
Comment 16 Fedora Update System 2012-08-06 14:47:35 EDT
openssh-5.9p1-26.fc17 has been submitted as an update for Fedora 17.
Comment 17 David 2012-08-06 22:21:46 EDT
The update resolves the issue. I removed the local policy I made and vino accepts connections over SSH.

Thankyou for the update :)
Comment 18 Fedora Update System 2012-08-09 19:11:01 EDT
Package openssh-5.9p1-26.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-5.9p1-26.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 19 Harald H. 2012-08-10 02:52:48 EDT
Yeah, works for me too, thanks!!!
Comment 20 Fedora Update System 2012-08-21 05:57:27 EDT
openssh-5.9p1-26.fc17 has been pushed to the Fedora 17 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.