Description of problem: After updating to the latest versions of freenx and nx I can't connect to my FC6 box anymore with NX. The log files and SETroubleshoot show that the reason is a SELinux error: SELinux is preventing /usr/bin/xauth from loading /usr/lib/nx/libXcomp.so.2 which requires text relocation. Version-Release number of selected component (if applicable): nx-2.1.0-22.fc6 How reproducible: always Steps to Reproduce: 1. Try to connect to the FC6 machine from a NX client on a Windows workstation. Actual results: The session setup fails after authenticating the connection. Expected results: NX connection to the Fedora desktop is started. Additional info: avc: denied { execmod } for comm="xauth" dev=dm-2 egid=500 euid=500 exe="/usr/bin/xauth" exit=-13 fsgid=500 fsuid=500 gid=500 items=0 name="libXcomp.so.2" path="/usr/lib/nx/libXcomp.so.2" pid=28410 scontext=user_u:system_r:unconfined_t:s0 sgid=500 subj=user_u:system_r:unconfined_t:s0 suid=500 tclass=file tcontext=system_u:object_r:lib_t:s0 tty=(none) uid=500
Does this mean that the previous version did work with selinux? In that case there will be some entries for nx in selinux policies. I've added dwalsh to the Cc, who is the selinux master: Dan, should I ship some selinux bits in the nx package, or could you adjust any selinux policies for nx? Thanks!
Yes, the previous version worked. Instead of changing policies you should fix the text relocations in the libraries as described in http://people.redhat.com/drepper/textrelocs.html
In current policy we have a file context of /usr/NX/lib/libXcomp\.so.* -- system_u:object_r:textrel_shlib_t:s0 Which would allow the execmod for the library. Since the library has been moved or is different it does not get this context. chcon -t textrel_shlib_t /usr/lib/nx/libXcomp.so.2 Would fix the problem and you can make this survive a relabel by executing semanage fcontext -a -t textrel_shlib_t /usr/lib/nx/libXcomp.so.2 But a better case as suggested by Markku would be to fix the text relocations.
Sounds like it just needs -fPIC then? I used the default Fedora %optflags, if this makes such a difference should this be fixed in redhat-rpm-config instead of each package by itself?
(In reply to comment #2) > Yes, the previous version worked. Instead of changing policies you should fix > the text relocations in the libraries as described in > http://people.redhat.com/drepper/textrelocs.html BTW I would gladly accept patches. I'm not a selinux user myself, so I cannot really properly test any such fixes.
(In reply to comment #3) > In current policy we have a file context of > /usr/NX/lib/libXcomp\.so.* -- system_u:object_r:textrel_shlib_t:s0 > > Which would allow the execmod for the library. Since the library has been moved > or is different it does not get this context. Could you adjust this in the policy? The old paths were not FHS conform.
THe path has been Fixed in selinux-policy-2.4.6-75 But this should definitely be fixed in the package. Bring the change to redhat-rpm-config to the fedora-maintainers list. I am not sure if that is the right place.
(In reply to comment #7) > THe path has been Fixed in selinux-policy-2.4.6-75 Thanks! > But this should definitely be fixed in the package. Bring the change to > redhat-rpm-config to the fedora-maintainers list. I am not sure if that is the > right place. Well, I'm not sure whether this change would be globally valid. Comment #4 was just a question on whether it would make sense. Someone understanding all intricacies of a global -fPIC should try to persuade Jeremy and co on making it the default. Since that would had saved quite a lot of effort some time back when x86_64 builds where failing due to missing -fPIC and the packages were being fixed one by one one assumes that someone must have had a good reason not to make -fPIC global years ago. BTW there is new nx release (but not yet packaged), maybe this is fixed in there.
Problem still exists in FC7. [silver]:[/var/lib/nxserver/db] # sealert -l a7c45cfc-ecb3-481c-aafb-22a6b76b7f4a Summary SELinux is preventing /usr/libexec/nx/nxagent from loading /usr/lib/nx/libXcomp.so.2 which requires text relocation. Detailed Description The /usr/libexec/nx/nxagent application attempted to load /usr/lib/nx/libXcomp.so.2 which requires text relocation. This is a potential security problem. Most libraries do not need this permission. Libraries are sometimes coded incorrectly and request this permission. The http://people.redhat.com/drepper/selinux-mem.html web page explains how to remove this requirement. You can configure SELinux temporarily to allow /usr/lib/nx/libXcomp.so.2 to use relocation as a workaround, until the library is fixed. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Allowing Access If you trust /usr/lib/nx/libXcomp.so.2 to run correctly, you can change the file context to textrel_shlib_t. "chcon -t textrel_shlib_t /usr/lib/nx/libXcomp.so.2" The following command will allow this access: chcon -t textrel_shlib_t /usr/lib/nx/libXcomp.so.2 Additional Information Source Context user_u:system_r:unconfined_t Target Context system_u:object_r:lib_t Target Objects /usr/lib/nx/libXcomp.so.2 [ file ] Affected RPM Packages nx-2.1.0-22.fc7 [application]nx-2.1.0-22.fc7 [target] Policy RPM selinux-policy-2.6.4-14.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.allow_execmod Host Name silver.x42.us Platform Linux silver.x42.us 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 athlon Alert Count 14 First Seen Mon Jun 25 14:24:02 2007 Last Seen Mon Jun 25 15:13:51 2007 Local ID a7c45cfc-ecb3-481c-aafb-22a6b76b7f4a Line Numbers Raw Audit Messages avc: denied { execmod } for comm="nxagent" dev=dm-0 egid=1000 euid=1000 exe="/usr/libexec/nx/nxagent" exit=-13 fsgid=1000 fsuid=1000 gid=1000 items=0 name="libXcomp.so.2" path="/usr/lib/nx/libXcomp.so.2" pid=5593 scontext=user_u:system_r:unconfined_t:s0 sgid=1000 subj=user_u:system_r:unconfined_t:s0 suid=1000 tclass=file tcontext=system_u:object_r:lib_t:s0 tty=(none) uid=1000 ~~~~~~~~~~~~ [silver]:[/home] $ rpm -qa | grep -i selinux selinux-policy-targeted-2.6.4-14.fc7 libselinux-2.0.13-1.fc7 selinux-policy-2.6.4-14.fc7 libselinux-python-2.0.13-1.fc7 ###### The work-around suggested in the "Allowing Access Section" does work.
So you executed chcon and you are still getting this AVC message?
G. Panula, (In reply to comment #10) > So you executed chcon and you are still getting this AVC message? had you done the above?
After executing the suggested chcon command selinux does allow access(if I'm remembering correctly). Just wanted to update the bug report that the problem hadn't been fixed in FC7.
(In reply to comment #12) > After executing the suggested chcon command selinux does allow access(if I'm > remembering correctly). Just wanted to update the bug report that the problem > hadn't been fixed in FC7. OK, I moved the bug to F7, but according to comment #8 this is fixed since selinux-policy-2.4.6-75 and F7 is currently at selinux-policy-2.6.4-63.fc7. So in theory this should had already been fixed since some releases of selinux-policy. Have you updated F7 and seen this again?
The box has been updated a couple of times but I haven't tried NX since the initial install. The box is my mom's machine and I don't currently have remote access to it. I might be there this upcoming weekend. I can check then and report back my results.
I tried nx with the current F8 packages, the result was the following SELinux AVC denial: Summary SELinux is preventing nxserver (sshd_t) "execute" to <Unknown> (bin_t). Detailed Description SELinux denied access requested by nxserver. It is not expected that this access is required by nxserver 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 <Unknown>, restorecon -v <Unknown> 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 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 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:bin_t Target Objects None [ file ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-72.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall_file Host Name nightshade Platform Linux nightshade 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 Alert Count 2 First Seen Wed Jan 2 14:25:05 2008 Last Seen Wed Jan 2 14:45:26 2008 Local ID aa3b893b-c530-4620-9752-a22c7ca734cc Line Numbers Raw Audit Messages avc: denied { execute } for comm=nxserver dev=dm-3 egid=496 euid=497 exe=/bin/bash exit=0 fsgid=496 fsuid=497 gid=496 items=0 name=nxserver pid=3443 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 sgid=496 subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 suid=497 tclass=file tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=497
*** Bug 427227 has been marked as a duplicate of this bug. ***
fixed, latest packages solving your problem are available here: http://people.redhat.com/jkubin/selinux/
After update on latest selinux-policy nx works for me. selinux-policy-2.6.4-70.fc7 selinux-policy-targeted-2.6.4-70.fc7 nx-2.1.0-22.fc7 freenx-0.7.1-3.fc7 $ /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: permissive Policy version: 21 Policy from config file: targeted