Description of problem: I've installed FreeNX server (package freenx.x86_64 version 0.7.0-2.fc8) and tried to connect to my machine from a windows box. SELinux says: SELinux denied access requested by /usr/sbin/sshd. It is not expected that this access is required by /usr/sbin/sshd 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. Additional Information Source Context: system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context: system_u:object_r:var_lib_t:s0 Target Objects: None [ lnk_file ] Affected RPM Packages: openssh-server-4.7p1-2.fc8 [application] Policy RPM: selinux-policy-3.0.8-53.fc8 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: plugins.catchall_file Host Name: localhost.localdomain Platform: Linux localhost.localdomain 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 22:14:09 EST 2007 x86_64 x86_64 Alert Count: 6 First Seen: Tue 13 Nov 2007 09:21:57 PM NZDT Last Seen: Tue 13 Nov 2007 10:06:30 PM NZDT Local ID: 93badc79-f75f-4226-aea2-545f2a4593bd Line Numbers: Raw Audit Messages : avc: denied { read } for comm=sshd dev=dm-5 egid=487 euid=493 exe=/usr/sbin/sshd exit=-13 fsgid=487 fsuid=493 gid=0 items=0 name=authorized_keys pid=3261 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 suid=0 tclass=lnk_file tcontext=system_u:object_r:var_lib_t:s0 tty=(none) uid=0 Version-Release number of selected component (if applicable): Should be clear from SELinux complain How reproducible: Easily Steps to Reproduce: 1. yum install freenx 2. install Windows NX client from http://www.nomachine.com/download-package.php?Prod_Id=65 3. follow the instructions (how to connect) from http://fedoranews.org/contributors/rick_stout/freenx/ Actual results: Expected results: Additional info:
Were you able to ssh in? IE did everything work fine, you just saw this avc?
I can confirm the problem. ssh (both as a mere mortal and as root) works fine. Trying to access via a FreeNX F7 client (x86_64) to an F8 FreeNX server (x86_64) fails and the server spits out the same avc error.
Ssh works fine. However, NX. As far as I understand, NX client connects to ssh, then starts the NX server and/or creates a tunnel to it. This is probably the root of the problem - somewhere during these steps avc fires which prevents NX server/client from functioning normally (NX client says that there is no server).
Could you put the machine in permissive mode to collect all of the avc messages.
I could, if you explain how to do that.
# setenforce 0 # grep avc /var/log/audit/audit.log or # grep avc /var/log/messages # setenforce 1
I truncated audit.log and messages, rebooted the box and did the following: [root@localhost ~]# date Thu Nov 15 21:11:10 NZDT 2007 [root@localhost ~]# setenforce 0 [root@localhost ~]# grep avc /var/log/audit/audit.log type=USER_AVC msg=audit(1195114276.942:22): user pid=2493 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: received setenforce notice (enforcing=0) : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' type=AVC msg=audit(1195114294.061:23): avc: denied { read } for pid=3476 comm="sshd" name="authorized_keys" dev=dm-5 ino=786528 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file type=AVC msg=audit(1195114294.098:24): avc: denied { getattr } for pid=3476 comm="sshd" path="/var/lib/nxserver/home/.ssh/authorized_keys" dev=dm-5 ino=786528 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file type=AVC msg=audit(1195114294.335:30): avc: denied { execute } for pid=3480 comm="sshd" name="nxserver" dev=dm-3 ino=26149723 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file type=AVC msg=audit(1195114294.335:30): avc: denied { read } for pid=3480 comm="sshd" name="nxserver" dev=dm-3 ino=26149723 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file [root@localhost ~]# grep avc /var/log/messages Nov 15 21:11:16 localhost dbus: avc: received setenforce notice (enforcing=0) [root@localhost ~]# setenforce 1 [root@localhost ~]# grep avc /var/log/messages Nov 15 21:11:16 localhost dbus: avc: received setenforce notice (enforcing=0) Nov 15 21:12:18 localhost dbus: avc: received setenforce notice (enforcing=1) [root@localhost ~]# Meanwhile, NX client says: nfo: Display running with pid '5168' and handler '0x100124'. NXPROXY - Version 3.0.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Proxy running in client mode with pid '3352'. Session: Starting session at 'Thu Nov 15 21:11:41 2007'. Warning: Connected to remote version 2.1.0 with local version 3.0.0. Info: Connection with remote proxy completed. Info: Using LAN link parameters 1536/24/1/0. Info: Using image streaming parameters 50/128/1024KB/6144/768. Info: Using image cache parameters 1/1/65536KB. Info: Using pack method '16m-rle-9' with session 'unix-gnome'. Info: Not using NX delta compression. Info: Not using ZLIB data compression. Info: Not using ZLIB stream compression. Info: Not using a persistent cache. Info: Forwarding X11 connections to display ':0'. Session: Session started at 'Thu Nov 15 21:11:42 2007'. Info: Established X server connection. Info: Using shared memory parameters 0/0K. Session: Terminating session at 'Thu Nov 15 21:11:43 2007'. Session: Session terminated at 'Thu Nov 15 21:11:43 2007'.
I found this problem too. The avc log entries are: avc: denied { execute } for comm=sshd dev=sda7 egid=489 euid=495 exe=/usr/sbin/sshd exit=-13 fsgid=489 fsuid=495 gid=489 items=0 name=nxserver pid=7098 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 sgid=489 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 suid=495 tclass=file tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=495 avc: denied { read } for comm=sshd dev=sda7 egid=489 euid=495 exe=/usr/sbin/sshd exit=-13 fsgid=489 fsuid=495 gid=489 items=0 name=nxserver pid=7405 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 sgid=489 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 suid=495 tclass=file tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=495 After feeding this to audit2allow and loading the new policy module NX starts to work
*Sigh* , Dan forgot to merge my patch for freenx ... I'll ask him to do it. Please use my packages until he really merge it. http://people.redhat.com/jkubin/selinux/F8/ # rpm -U --replacepkgs selinux-policy-* or # grep '\(pam_timestamp_c\|nxserver\)' /var/log/audit/audit.log | audit2allow -M fix4nx # semodule -i fix4nx.pp
Fixed in selinux-policy-3.0.8-89.fc8
It looks like the bug is back in selinux-policy-3.3.1-87.fc9.noarch.rpm : SELinux is preventing sshd (sshd_t) "read" to authorized_keys (var_lib_t). For complete SELinux messages. run sealert -l 3b8da906-b389-42fb-82f4-791d15c6f936 --- Summary: SELinux is preventing sshd (sshd_t) "read" to authorized_keys (var_lib_t). Detailed Description: SELinux denied access requested by sshd. It is not expected that this access is required by sshd 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. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for authorized_keys, restorecon -v 'authorized_keys' If this does not work, there is currently no automatic way to allow this access. Instead, 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. Additional Information: Source Context unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects authorized_keys [ lnk_file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host myhost Source RPM Packages openssh-server-5.1p1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-87.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name myhost Platform Linux myhost 2.6.26.3-29.fc9.x86_64 #1 SMP Wed Sep 3 03:16:37 EDT 2008 x86_64 x86_64 Alert Count 8 First Seen Fri Sep 19 15:36:58 2008 Last Seen Fri Sep 19 16:28:02 2008 Local ID 3b8da906-b389-42fb-82f4-791d15c6f936 Line Numbers Raw Audit Messages host=myhost type=AVC msg=audit(1221838082.239:1138): avc: denied { read } for pid=20565 comm="sshd" name="authorized_keys" dev=sda4 ino=784488 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file host=myhost type=SYSCALL msg=audit(1221838082.239:1138): arch=c000003e syscall=2 success=no exit=-13 a0=7f0a690e85e0 a1=800 a2=1 a3=7f0a678a57a0 items=0 ppid=19178 pid=20565 auid=500 uid=0 gid=0 euid=494 suid=0 fsuid=494 egid=488 sgid=0 fsgid=488 tty=(none) ses=21 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
User jkubin's account has been closed
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.
The bug given in comment #11 is present in 3.3.1-111.fc9: Summary: SELinux is preventing sshd (sshd_t) "read" to authorized_keys (var_lib_t). Detailed Description: SELinux denied access requested by sshd. It is not expected that this access is required by sshd 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. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for authorized_keys, restorecon -v 'authorized_keys' If this does not work, there is currently no automatic way to allow this access. Instead, 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. Additional Information: Source Context system_u:system_r:sshd_t:SystemLow-SystemHigh Target Context system_u:object_r:var_lib_t Target Objects authorized_keys [ lnk_file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host ignacio.ignacio.lan Source RPM Packages openssh-server-5.1p1-3.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-111.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name ignacio.ignacio.lan Platform Linux ignacio.ignacio.lan 2.6.27.5-41.fc9.i686 #1 SMP Thu Nov 13 20:52:14 EST 2008 i686 athlon Alert Count 8 First Seen Fri 14 Nov 2008 08:15:44 AM EST Last Seen Sat 13 Dec 2008 06:02:33 PM EST Local ID a14b5f0d-f46e-4945-9625-37e98f0e14e0 Line Numbers Raw Audit Messages node=ignacio.ignacio.lan type=AVC msg=audit(1229209353.173:14980): avc: denied { read } for pid=24335 comm="sshd" name="authorized_keys" dev=dm-0 ino=1311434 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file node=ignacio.ignacio.lan type=SYSCALL msg=audit(1229209353.173:14980): arch=40000003 syscall=5 success=no exit=-13 a0=b7fef480 a1=8800 a2=0 a3=8800 items=0 ppid=2637 pid=24335 auid=4294967295 uid=0 gid=0 euid=498 suid=0 fsuid=498 egid=496 sgid=0 fsgid=496 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
Fixed in selinux-policy-3.3.1-119.fc9
Is there also a fixed selinux-policy package for Fedora 10 (it's also affected by this bug)? I can't find any info regarding this in latest build in koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=79544
Dawid, also fixed in selinux-policy-3.5.13-40.fc10.noarch
mgrepl, I've just updated and works great (typing this from remote FreeNX session and SELinux in enforcing mode). Thank you!
The problem surfaced again in current rawhide (04/22/2009): sealert -l 89d0a773-94c6-4620-876d-a1f00c7d02c2 Summary: SELinux is preventing sshd (sshd_t) "read" var_lib_t. Detailed Description: SELinux denied access requested by sshd. It is not expected that this access is required by sshd 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. Allowing Access: 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. Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects authorized_keys [ lnk_file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host localhost.localdomain Source RPM Packages openssh-server-5.2p1-2.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-9.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.29.1-102.fc11.x86_64 #1 SMP Mon Apr 20 15:33:38 EDT 2009 x86_64 x86_64 Alert Count 10 First Seen Mon Apr 20 09:34:14 2009 Last Seen Wed Apr 22 09:36:35 2009 Local ID 89d0a773-94c6-4620-876d-a1f00c7d02c2 Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1240407395.48:38580): avc: denied { read } for pid=15524 comm="sshd" name="authorized_keys" dev=dm-3 ino=74682 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file node=localhost.localdomain type=SYSCALL msg=audit(1240407395.48:38580): arch=c000003e syscall=2 success=no exit=-13 a0=7fa54ad7ab20 a1=800 a2=1 a3=7fa54900c7b0 items=0 ppid=1901 pid=15524 auid=4294967295 uid=0 gid=0 euid=494 suid=0 fsuid=494 egid=490 sgid=0 fsgid=490 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
I have the same problem with Fedora 11 beta. The problem is that freenx-server cannot access the file /var/lib/nxserver/home/.ssh/authorized_keys2 (not authorized_keys, in my case). See also Bug 483507. Is this the right place to request getting an SELinux rule added? From /var/log/messages: ----------------------- Jun 5 02:07:02 localhost setroubleshoot: SELinux is preventing sshd (sshd_t) "getattr" var_lib_t. For complete SELinux messages. run sealert -l [...] From sealert: ------------- Summary: SELinux is preventing sshd (sshd_t) "read" var_lib_t. Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by sshd. It is not expected that this access is required by sshd 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. Allowing Access: 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. Additional Information: Source Context unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:var_lib_t:s0 Target Objects authorized_keys2 [ file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host [...] Source RPM Packages openssh-server-5.2p1-2.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-34.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name [...] Platform Linux [...] 2.6.29.2-126.fc11.x86_64 #1 SMP Mon May 4 04:46:15 EDT 2009 x86_64 x86_64 Alert Count 16 First Seen Fri Jun 5 01:27:01 2009 Last Seen Fri Jun 5 02:07:44 2009 Local ID b27cc33d-408b-4161-aeaa-cf78e895e73d Line Numbers Raw Audit Messages node=transcendence.csail.mit.edu type=AVC msg=audit(1244182064.97:29652): avc: denied { read } for pid=15342 comm="sshd" name="authorized_keys2" dev=dm-0 ino=239269 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file node=transcendence.csail.mit.edu type=AVC msg=audit(1244182064.97:29652): avc: denied { open } for pid=15342 comm="sshd" name="authorized_keys2" dev=dm-0 ino=239269 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file node=transcendence.csail.mit.edu type=SYSCALL msg=audit(1244182064.97:29652): arch=c000003e syscall=2 success=no exit=390127576 a0=7f551f58f2c0 a1=800 a2=1 a3=7f551e7f47b0 items=0 ppid=18196 pid=15342 auid=500 uid=0 gid=0 euid=501 suid=0 fsuid=501 egid=501 sgid=0 fsgid=501 tty=(none) ses=1 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
Just FYI, it works ok for me in updated F11-Preview - I did a clean re-install two days ago and I kept SELinux in enforcing mode and freenx-server works just fine with no errors.
Luke make sure your directrories are labeled correctly. restorecon -R -v /var/lib With latest Fedora 11 polcy this should work
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I am closing this bug. There is another bug for F11 policy.