Red Hat Bugzilla – Bug 483507
Selinux prevents a freenx-client from connecting
Last modified: 2010-04-27 08:54:01 EDT
Created attachment 330565 [details] Selinux error message when freenx-client tries to connect. Description of problem:When a freenx-client tries to connect to a freenx-server Selinux blocks connection. Version-Release number of selected component (if applicable):freenx-server-0.7.3-11.fc10.i386 How reproducible:Everytime freenx-client tries to connect Steps to Reproduce: 1.just start connection process from Client 2. 3. Actual results:Selinux blocks connection Expected results:freenx-client being able to connect Additional info:
I forgot add that the only way the Client can make connection to server, is if Server box, is to put Selinux in the "permissive" mode.
Jim, can you add some more details like the parts of the denial in the logs? I think this is best done while in permissive mode to catch all violations. It is either something that could go into the policies, or a bug in the nx sources to fix, but we need to understand the issues. Thanks!
Do you know what log files you want by name and path ?
I think it's either /var/log/messages or /var/log/audit/audit.log
If you execute the following: # semanage fcontext -a -t home_ssh_t '/var/lib/nxserver/home/.ssh(/.*)?' # restorecon -R -v /var/lib/nxserver Does it fix the problem?
Created attachment 330800 [details] Attachment enclosed # semanage fcontext -a -t home_ssh_t '/var/lib/nxserver/home/.ssh(/.*)?' # restorecon -R -v /var/lib/nxserver
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 . 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)
See also Bug 379581.
Luke, are you still getting this problem with current F11 selinux-policy ?
Miroslav -- I am unfortunately away for the summer and can't test right now. Please close if in theory it is fixed! Thanks!
Just thought I'd chime in, on my setup of a fresh and up to date F11 box today, I was confounded by this problem with the latest freenx packages, all because I forgot to disable SELinux...so I believe from my experience that its still a problem...this was for F11 32bit.
Miroslav please add /var/lib/nxserver/home/.ssh(/.*)? gen_context(system_u:object_r:nx_server_home_ssh_t,s0) to nx.fc ######################################## ## <summary> ## Read nx home directory content ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`nx_read_home_files',` gen_require(` type nx_server_home_ssh_t; ') read_files_pattern($1, nx_server_home_ssh_t, nx_server_home_ssh_t) ') to nx.if and optional_policy(` nx_read_home_files(sshd_t) ') to sshd.te
Fixed in selinux-policy-3.6.12-79.fc11 selinux-policy-3.5.13-70.fc10
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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