Red Hat Bugzilla – Bug 506326
selinux targeted policy puts vncserver in the wrong context
Last modified: 2018-04-11 07:01:43 EDT
Description of problem:
selinux targeted has the file context of /usr/bin/vncserver as system_u:object_r:unconfined_notrans_exec_t:s0. This causes Xvnc to run in unconfined_notrans_t, which means that if you restart a service (eg sshd) from an xterm inside of Xvnc, it doesn't get the right context and cannot do its job.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run vncserver, make sure it starts an xterm
2. Connect to the child Xvnc process
3. Note that your shell process (in the xterm) is in unconfined_notrans_t instead of unconfined_t
4. Make sure you have a shell somewhere else in unconfined_t to ensure you don't lock yourself out of the machine (without a reboot)
5. sudo service sshd restart
6. Note that sshd was not able to switch to sshd_t, and is instead running in unconfined_notrans_t
7. Try to ssh in to the machine - sshd cannot spawn a user shell
Because sshd is running unconfined_notrans_t, it cannot spawn a user shell
sshd should be running in sshd_t, and should be able to spawn a user shell
*** Bug 453716 has been marked as a duplicate of this bug. ***
Miroslav can you play around with this and see if you can get it running in unconfined_t.
It seems like it works with unconfined_t.
could you try execute
# chcon -t unconfined_exec_t /usr/bin/vncserver
And see if it works fine also for you.
*** Bug 551102 has been marked as a duplicate of this bug. ***
I was also having problems with vnc on a headless system and
chcon -t unconfined_exec_t /usr/bin/vncserver
seems to have made them go away.
The fix was added to the F12 selinux-policy.