Foreman » SELinux

If you're seeing the error in the web UI then it's more likely to be Foreman unable to talk to the compute resource as for the console, websockify runs in a separate process. If it was unable to bind then you'd not see the error in Foreman.

Can you try again to retrieve the AVC from the audit log? The line pasted is just a syscall and doesn't show precisely what's happening.

If you're using OpenStack then you're probably hitting #10443.

IT works when I turn off selinux:
setenforce 0

Then stops working again when selinux is enabled:
setenforce 1

Which makes me think its all selinux related.
Besides that, it all worked when I was on 1.8.x and only started acting up after the upgrade to 1.9.
I'm using the foreman installer, so there should be no abnormalities. Two systems with the same results:
One is OEL 7.1 and the other is CentOS 7.1

How can I better retrieve the audit log? I tail it and get that line only added when I click the console button.
I'm not using Openstack. I'm using VMware vsphere.

I also never see the websockify process spawned with ps...
This makes me think Foreman is denied to spawn it on the random port.

It could be a "dontaudit" rule if you're not getting an actual AVC message in the audit log (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Possible_Causes_of_Silent_Denials.html shows how to re-enable auditing).

I have the same issue :
type=AVC msg=audit(1442430096.649:4670): avc: denied { name_bind } for pid=11869 comm="ruby" src=5919 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket

Adding this custom SELinux module solve the issue :

yum install -y selinux-policy-devel

cd /tmp/
cat <<EOF > foreman_addition.te
module foreman_addition 1.0;

require {
type passenger_t;
type vnc_port_t;
class tcp_socket { name_bind };
}

#============= passenger_t ==============
allow passenger_t vnc_port_t:tcp_socket name_bind;
EOF

make -f /usr/share/selinux/devel/Makefile foreman_addition.pp
semodule -i foreman_addition.pp

Thanks, that's useful data. Could you check the context of the websockify process? It's meant to be in a separate domain, websockify_t, which should have this rule already: https://github.com/theforeman/foreman-selinux/blob/develop/foreman.te#L352

[root@foreman ~]# ll -Z /usr/share/foreman/extras/noVNC/websockify.py
-rwxr-xr-x. root root system_u:object_r:websockify_exec_t:s0 /usr/share/foreman/extras/noVNC/websockify.py

That file should be websockify_exec_t. Run restorecon against it if not.

Next, when you load the console, the process should also be websockify_t. Run ps -efZ | grep websockify to check that.

[root@foreman ~]# ll -Z /usr/share/foreman/extras/noVNC/websockify.py
-rwxr-xr-x. root root system_u:object_r:websockify_exec_t:s0 /usr/share/foreman/extras/noVNC/websockify.py

[root@foreman ~]# ps -efZ | grep webso
system_u:system_r:websockify_t:s0 foreman 5600 1 0 10:20 ? 00:00:00 /usr/bin/python /usr/share/foreman/extras/noVNC/websockify.py --daem on --idle-timeout=120 --timeout=120 5917 vmware-host:5925 --cert /var/lib/puppet/ssl/certs/foreman.xx.pem --key /var/lib