Red Hat Bugzilla – Bug 827109
SELinux is preventing /usr/sbin/sshd from 'name_connect' accesses on the tcp_socket .
Last modified: 2012-08-21 05:57:27 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 description: :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. :Do :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 : :
How did you get this to happen?
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.
If you switch to permissive mode and use the vino, are you getting more AVC msgs then? # ausearch -m avc -ts recent
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.
Adding openssh people. I would have thought this would happen under priv sep process.
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 COMMAND PID SECURITY-CONTEXT USER FD TYPE DEVICE SIZE NODE NAME 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 Enforcing malas # rpm -q openssh selinux-policy openssh-5.9p1-22.fc17.x86_64 selinux-policy-3.10.0-128.fc17.noarch
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, Cheers, David
(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
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. Cheers, David
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. Solution: *) 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?
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
Do you use a ssh root account to create ssh port forwarding? Can you paste an output of $ ps axfZ | grep sshd
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 AVC: 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
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!!
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.
openssh-5.9p1-26.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/openssh-5.9p1-26.fc17
The update resolves the issue. I removed the local policy I made and vino accepts connections over SSH. Thankyou for the update :)
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: https://admin.fedoraproject.org/updates/FEDORA-2012-11609/openssh-5.9p1-26.fc17 then log in and leave karma (feedback).
Yeah, works for me too, thanks!!!
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.