Created attachment 890971 [details] audit.log from overcloud controller Description of problem: swift services denied name_connect neutron denied write for sock_file neutron denied connecting by unix_stream_socket Version-Release number of selected component (if applicable): selinux-policy-3.12.1-158.fc20.noarch selinux-policy-targeted-3.12.1-158.fc20.noarch openstack-neutron-2014.1-11.fc21.noarch openstack-neutron-ml2-2014.1-11.fc21.noarch openstack-neutron-openvswitch-2014.1-11.fc21.noarch python-neutron-2014.1-11.fc21.noarch python-neutronclient-2.3.4-1.fc21.noarch How reproducible: always Steps to Reproduce: 1. Install instack-undercloud using source and selinux branch https://github.com/agroup/instack-undercloud 2. Run instack-test-overcloud which will then cause the avcs to be logged Actual results: neutron and swift avcs instack-test-overcloud fails Expected results: no avcs and instack-test-overcloud should run sucessfully Additional info:
Created attachment 890972 [details] mypol8.pp custom policy
Created attachment 890973 [details] mypol8.te custom policy
Could you attach AVC msg for allow neutron_t init_t:unix_stream_socket connectto; What does # ps -efZ |grep init_t
AVC msg is already attached. Here is what it looks like: type=AVC msg=audit(1398804652.001:891): avc: denied { connectto } for pid=6128 comm="neutron-ns-meta" path="/run/neutron/metadata_proxy" scontext=system_u:system_r:neutron_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket --- [root@overcloud-notcompute0-s4mr26drmxnc audit]# ps -efZ |grep init_t system_u:system_r:init_t:s0 root 1 0 0 01:22 ? 00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 24 system_u:system_r:init_t:s0 root 738 1 0 01:22 ? 00:00:02 /usr/bin/python /usr/bin/os-collect-config system_u:system_r:init_t:s0 cinder 4235 1 1 01:25 ? 00:00:16 /usr/bin/python /usr/bin/cinder-api --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log system_u:system_r:init_t:s0 cinder 4240 1 0 01:25 ? 00:00:02 /usr/bin/python /usr/bin/cinder-scheduler --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/scheduler.log system_u:system_r:init_t:s0 cinder 4301 4235 0 01:25 ? 00:00:00 /usr/bin/python /usr/bin/cinder-api --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log system_u:system_r:init_t:s0 cinder 4316 1 1 01:25 ? 00:00:15 /usr/bin/python /usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/volume.log system_u:system_r:init_t:s0 swift 4339 1 0 01:25 ? 00:00:00 /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf system_u:system_r:init_t:s0 cinder 4395 4316 0 01:25 ? 00:00:01 /usr/bin/python /usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/volume.log system_u:system_r:init_t:s0 swift 4421 4339 0 01:25 ? 00:00:04 /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf system_u:system_r:init_t:s0 heat 4764 1 0 01:26 ? 00:00:00 /usr/bin/python /usr/bin/heat-api --logfile /var/log/heat/api.log system_u:system_r:init_t:s0 heat 4769 1 0 01:26 ? 00:00:00 /usr/bin/python /usr/bin/heat-api-cfn --logfile /var/log/heat/api-cfn.log system_u:system_r:init_t:s0 heat 4774 1 0 01:26 ? 00:00:00 /usr/bin/python /usr/bin/heat-api-cloudwatch --logfile /var/log/heat/api-cloudwatch.log system_u:system_r:init_t:s0 heat 4820 1 0 01:26 ? 00:00:01 /usr/bin/python /usr/bin/heat-engine --logfile /var/log/heat/engine.log system_u:system_r:init_t:s0 neutron 4902 1 0 01:26 ? 00:00:01 /usr/bin/python /usr/bin/neutron-metadata-agent --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/metadata_agent.ini --log-file /var/log/neutron/metadata-agent.log system_u:system_r:init_t:s0 nova 5186 1 1 01:27 ? 00:00:14 /usr/bin/python /usr/bin/nova-conductor system_u:system_r:init_t:s0 nova 5268 5186 0 01:27 ? 00:00:11 /usr/bin/python /usr/bin/nova-conductor system_u:system_r:init_t:s0 heat-ad+ 5382 1 0 01:27 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 heat-ad+ 5391 5382 0 01:27 ? 00:00:00 (sd-pam) system_u:system_r:init_t:s0 root 5876 1 0 01:30 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 heat 5878 1 0 01:30 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 root 5882 5876 0 01:30 ? 00:00:00 (sd-pam) system_u:system_r:init_t:s0 heat 5883 5878 0 01:30 ? 00:00:00 (sd-pam) unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 25277 10477 0 01:48 pts/0 00:00:00 grep --color=auto init_t
Ok we are missing lot of labels. Could you tell us about which binaries we should care from the list above?
Just curious, what kind of labels are we missing? For this BZ, we care about neutron and swift. For neutron, it is this one: /usr/bin/python /usr/bin/neutron-metadata-agent --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/metadata_agent.ini --log-file /var/log/neutron/metadata-agent.log For swift, it is not the swift-proxy services listed above. It is the regular account, container, and object server services also mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=1084310 The binaries for those are [root@overcloud-notcompute0-n7beldwwm2tl ~]# ls -l /usr/bin/swift*server | grep -v proxy -rwxr-xr-x. 1 root root 881 Apr 19 21:14 /usr/bin/swift-account-server -rwxr-xr-x. 1 root root 883 Apr 19 21:14 /usr/bin/swift-container-server -rwxr-xr-x. 1 root root 982 Apr 19 21:14 /usr/bin/swift-object-server
Hi Miroslav, I've moved the swift issue to bug 1095503. Any thoughts on the neutron errors?
init_t means a service runs without SELinux protection. It means binaries are labeled as bin_t. For example system_u:system_r:init_t:s0 swift 4339 1 0 01:25 ? 00:00:00 /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf and you want to look for /usr/bin/swift-proxy-server label using # ls -Z /usr/bin/swift-proxy-server # matchpathcon /usr/bin/swift-proxy-server if labels are different then we need to fix labeling using "restorecon" tool.
Where does cinder-* and heat-* come from? Is this something new?
The labels are the same. [root@overcloud-notcompute0-mvnf4crr7mlp ~]# ls -Z /usr/bin/swift-proxy-server -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/bin/swift-proxy-server [root@overcloud-notcompute0-mvnf4crr7mlp ~]# matchpathcon /usr/bin/swift-proxy-server /usr/bin/swift-proxy-server system_u:object_r:bin_t:s0 [root@overcloud-notcompute0-mvnf4crr7mlp ~]# rpm -qf /usr/bin/swift-proxy-server openstack-swift-proxy-1.13.1-1.fc21.noarch cinder and heat also run on the notcompute node. They are not new, and haven't exhibited any problems so far.
Do the above labels look ok? What about these lines in the custom policy I created? Can we incorporate them into the default policy? allow neutron_t init_t:unix_stream_socket connectto; allow neutron_t neutron_var_lib_t:sock_file write;
5ffd96566fe7e4855154fcfb47b0345b5d6c59e2 allows neutron to create sock files. I would think that swift-proxy-server should probably be labeled as a swift_exec_t?
Yes, I added this labeling.
Dan, Will 5ffd96566fe7e4855154fcfb47b0345b5d6c59e2 make it into the next selinux policy update? I don't see it in selinux-policy-3.12.1-166.fc20.
Yes, it will.
selinux-policy-3.12.1-167.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-167.fc20
Package selinux-policy-3.12.1-167.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-167.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7240/selinux-policy-3.12.1-167.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-171.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-171.fc20
Package selinux-policy-3.12.1-171.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-171.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7499/selinux-policy-3.12.1-171.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-171.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.