Description of problem: VNC sessions have a different context than normal X sessions do. This is a regression since Fedora 8. Version-Release number of selected component (if applicable): selinux-policy-3.3.1-72.fc9.noarch How reproducible: 100% Steps to Reproduce: 1.Start a VNC session by configuring it in /etc/sysconfig/vncservers 2.View VNC session, start terminal 3.id -Z Actual results: unconfined_u:system_r:unconfined_notrans_t:s0 Expected results: unconfined_u:system_r:unconfined_t:s0 Additional info: This causes various types of bad behaviour, but the one that motivated me to file a bug report today was that this sequence: su - service cups restart causes cupsd to run in the unconfined_notrans_t context (which is incorrect), whereas it used to be fine to do that from within VNC.
Tim if you chcon -t bin_t vncserver Does everything work correctly? I think there is some side effect that, caused me to change it to notrans.
After 'chcon -t bin_t /usr/bin/vncserver' and restarting the vncserver service, 'id -Z' from within the VNC session shows: unconfined_u:system_r:initrc_t:s0 and although 'service cups restart' starts cupsd in the expected security context, other things such as 'su -' break. Really we need to end up with 'id -Z' inside a VNC session showing the same context type as for a normal login session, unconfined_t.
Another reason unconfined_notrans_t is no good is that f-spot won't start from within a VNC session: host=cyberelk.elk type=AVC msg=audit(1217669846.26:85): avc: denied { execheap } for pid=5116 comm="f-spot" scontext=unconfined_u:system_r:unconfined_notrans_t:s0 tcontext=unconfined_u:system_r:unconfined_notrans_t:s0 tclass=process host=cyberelk.elk type=SYSCALL msg=audit(1217669846.26:85): arch=c000003e syscall=10 success=no exit=-13 a0=2af4000 a1=1000 a2=7 a3=3450d67a70 items=0 ppid=1 pid=5116 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=3 comm="f-spot" exe="/usr/bin/mono" subj=unconfined_u:system_r:unconfined_notrans_t:s0 key=(null) It works fine from a console login session on the same machine.
I'm seeing the exact same problem in Fedora 10 while trying to install Fedora Directory Server from a VNC session. setup-ds-admin.pl works right up until it tries to start dirsrv-admin. Starting dirsrv-admin from a console login works fine. The warning from SELinux is below: Summary: SELinux is preventing runcon (unconfined_notrans_t) "transition" unconfined_t. Detailed Description: SELinux denied access requested by runcon. It is not expected that this access is required by runcon 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:unconfined_notrans_t:s0 Target Context system_u:system_r:unconfined_t:s0 Target Objects /usr/sbin/httpd.worker [ process ] Source runcon Source Path /usr/bin/runcon Port <Unknown> Host myhost.mydomain.net Source RPM Packages coreutils-6.12-18.fc10 Target RPM Packages httpd-2.2.10-2 Policy RPM selinux-policy-3.5.13-41.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name myhost.mydomain.net Platform Linux myhost.mydomain.net 2.6.27.12-170.2.5.fc10.x86_64 #1 SMP Wed Jan 21 01:33:24 EST 2009 x86_64 x86_64 Alert Count 3 First Seen Tue 10 Feb 2009 11:57:32 AM EST Last Seen Tue 10 Feb 2009 12:35:31 PM EST Local ID e75557ce-cacf-4370-a2b2-dfdedf749ca6 Line Numbers Raw Audit Messages node=myhost.mydomain.net type=AVC msg=audit(1234287331.404:53): avc: denied {transition } for pid=4364 comm="runcon" path="/usr/sbin/httpd.worker" dev=dm-0 ino=54362 scontext=system_u:system_r:unconfined_notrans_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=process node=myhost.mydomain.net type=SYSCALL msg=audit(1234287331.404:53): arch=c000003e syscall=59 success=no exit=-13 a0=7fff484b5ece a1=7fff484b41b8 a2=7fff484b41e8 a3=3e50f6da70 items=0 ppid=4355 pid=4364 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=4294967295 comm="runcon" exe="/usr/bin/runcon" subj=system_u:system_r:unconfined_notrans_t:s0 key=(null)
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
*** This bug has been marked as a duplicate of bug 506326 ***