Open Stack

Hello all!

While working on podman integration, especially the SELinux part of it,
I was wondering why we kept using the host's /run (or its replicated
/var/run) location inside containers. And I'm still wondering, 2 years
later ;).

Reasons:
- from time to time, there are patches adding a ":z" flag to the run
bind-mount. This breaks the system, since the host systemd can't
write/access container_file_t SELinux context. Doing a relabeling might
therefore prevent a service restart.

- in order to keep things in a clean, understandable tree, getting a
dedicated shared directory for the container's sockets makes sense, as
it might make things easier to check (for instance, "is this or that
service running in a container?")

- if an operator runs a restorecon during runtime, it will break
container services

- mounting /run directly in the containers might expose unwanted
sockets, such as DBus (this creates SELinux denials, and we're
monkey-patching things and doing really ugly changes to prevent it).
It's more than probable other unwanted shared sockets end in the
containers, and it might expose the host at some point. Here again, from
time to time we see new SELinux policies being added in order to solve
the denials, and it creates big holes in the host security

AFAIK, no *host* service is accessed by any container services, right?
If so, could we imagine moving the shared /run to some other location on
the host, such as /run/containers, or /container-run, or any other
*dedicated* location we can manage as we want on a SELinux context?

I would therefore get some feedback about this proposed change.

For the containers, nothing should change:
- they will get their /run populated with other containers sockets
- they will NOT be able to access the host services at all.

Thank you for your feedback, ideas and thoughts!

Cheers,

C.

-- 
Cédric Jeanneret (He/Him/His)
Sr. Software Engineer - OpenStack Platform
Deployment Framework TC
Red Hat EMEA
https://www.redhat.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200618/f73a0742/attachment.sig>