I get this anytime I run ssh -Y from the computer with staff_u enabled. I don't think that ssh -Y is something so horrible to be avoided, right? --------------------- SELinux is preventing xauth (xauth_t) "read write" staff_ssh_t. Podrobný popis: SELinux denied access requested by xauth. It is not expected that this access is required by xauth and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Povolení přístupu: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Další informace: Kontext zdroje staff_u:staff_r:xauth_t:SystemLow-SystemHigh Kontext cíle staff_u:staff_r:staff_ssh_t:SystemLow-SystemHigh Objekty cíle socket [ tcp_socket ] Zdroj xauth Cesta zdroje /usr/bin/xauth Port <Neznámé> Počítač viklef RPM balíčky zdroje xorg-x11-xauth-1.0.2-5.fc10 RPM balíčky cíle RPM politiky selinux-policy-3.5.13-30.fc10 Selinux povolen True Typ politiky targeted MLS povoleno True Vynucovací režim Enforcing Název zásuvného modulu catchall Název počítače viklef Platforma Linux viklef 2.6.27.7-134.fc10.i686 #1 SMP Mon Dec 1 22:42:50 EST 2008 i686 i686 Počet upozornění 3 Poprvé viděno St 10. prosinec 2008, 12:18:53 CET Naposledy viděno St 10. prosinec 2008, 14:34:42 CET Místní ID 3557195a-07f8-4975-8688-6767dc96c1c1 Čísla řádků Původní zprávy auditu node=viklef type=AVC msg=audit(1228916082.717:13514): avc: denied { read write } for pid=8102 comm="xauth" path="socket:[5989399]" dev=sockfs ino=5989399 scontext=staff_u:staff_r:xauth_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_ssh_t:s0-s0:c0.c1023 tclass=tcp_socket node=viklef type=AVC msg=audit(1228916082.717:13514): avc: denied { read write } for pid=8102 comm="xauth" path="socket:[5989400]" dev=sockfs ino=5989400 scontext=staff_u:staff_r:xauth_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_ssh_t:s0-s0:c0.c1023 tclass=tcp_socket node=viklef type=SYSCALL msg=audit(1228916082.717:13514): arch=40000003 syscall=11 success=yes exit=0 a0=9563888 a1=9562e40 a2=9562088 a3=0 items=0 ppid=8101 pid=8102 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="xauth" exe="/usr/bin/xauth" subj=staff_u:staff_r:xauth_t:s0-s0:c0.c1023 key=(null)
This looks like sshd is leaking the file descriptor to the tcp socket? This socket should not be availble to tools execed by ssh, I believe. fcntl(fd, F_SETFD, FD_CLOEXEC)
We already set FD_CLOEXEC on the tcp socket on client. So I am really curious what the tcp socket which is passed to xauth is. I need a 'lsof -c ssh -Z' output generated at the time when you get the AVC.
Tomáš, didn't we resolve on IRC, that it is vncviewer -via <name> localhost:3 problem?
Yep, the channel sockets have to be FD_CLOEXECed too. The current rawhide already contains the fix.