<div dir="ltr"><div dir="ltr">Hello!<div><br></div><div><div>One of the most important tasks for this release cycle is to provide full SELinux support in the installed overcloud. Some work in this direction has already been done and in many respects, due to the recent changes, support is almost ready.</div><div><br></div><div>However, I would like to ask a few questions about what else can be improved.</div><div>In short, to provide SELinux support the main challenge for us is to ensure that docker can write to the directories protected by SELinux. To allow writing there we change the directory type to container_file_t or its alias svirt_sandbox_file_t.</div><div><br></div><div>There are two ways to do this:</div><div>1. Explicitly - specify the type when creating a directory.</div><div># semanage fcontext -at container_file_t "/my_folder(/.*)?"</div><div># restorecon -R /my_folder</div><div># docker run -v /my_folder:/tmp/my_folder ...</div><div>2. Implicitly - use the suffix :z when mounting the partition when creating a container.</div><div># docker run -v /my_folder:/tmp/my_folder:z ...</div><div><br></div><div>Both methods change selinux type of /my_folder to container_file_t and allow to write to the section inside the container.</div><div>You can read more about this feature in the article <a href="https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/">https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/</a></div><div>To see how it works, I wrote a small playbook that creates two directories on the host system and modifies their selinux types in two ways: <a href="http://paste.openstack.org/show/737234/">http://paste.openstack.org/show/737234/</a></div><div><br></div><div>Currently there is no consensus in TripleO which of the ways to use. For example, in many cases both methods are used, which adds unnecessary redundancy:</div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L193-L194">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L193-L194</a></div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L218-L219">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L218-L219</a></div><div><br></div><div>In some cases there is only :z</div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/liquidio-compute-config.yaml#L97">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/liquidio-compute-config.yaml#L97</a></div><div><br></div><div>In some, only explicit setting of svirt_sandbox_file_t on the directory</div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L219">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L219</a></div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L248">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L248</a></div><div><br></div><div>Some services still do not have SELinux support:</div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/etcd.yaml">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/etcd.yaml</a></div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/zaqar.yaml">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/zaqar.yaml</a></div><div><a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/tacker.yaml">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/tacker.yaml</a></div><div><br></div><div>Such inconsistency leads to hard to find bugs and makes it difficult to understand the code. </div><div>An example of such a bug could be this:</div><div>Here we set selinux type to svirt_sandbox_file_t for /var/log/swift <a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L249">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L249</a></div><div>And rewrite it back later: <a href="https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-storage.yaml#L462">https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-storage.yaml#L462</a></div><div>For this reason, I want to come to an agreement on how we will implement SELinux support.</div><div><br></div><div>In my understanding, the best solution would be to use the suffix :z only. Its advantage is that docker (and podman) checks the directory's selinux type before launching the container and changes it accordingly. In other words, if the type was accidentally changed during the execution of the container, then when it is restarted ":z" will return the type back. In the case of explicit type setting, we get an error.</div><div><br></div><div>Therefore, I propose to remove the explicit setting svirt_sandbox_file_t and add the suffix ":z" where it is still missing.</div></div><div><br></div><div>What do you think?</div><div><br></div><div>Best regards,</div><div>Mikhail Fedosin</div></div></div>