dind VS refpolicy

> ...anything that expects to be managing docker inside docker.

Now that's an interesting problem to have!

If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well.

Alternatively, you can try to just run Docker in Docker (DinD), which is a bit more tricky and the opinions there are split about whether to do it and when to do it: https://github.com/jpetazzo/dind

Of course, someone might also jump in and suggest that Docker is architecturally problematic (i don't care much, just want my containers to run, then again; i don't deal with untrusted code or any sort of multitenancy) and you should use Podman or another set of technologies, which is interesting advice but would necessitate other approaches.

In short, like with most technologies: Docker and OCI container in general get more messy as your requirements become more advanced. For the problems that they do solve easily (app packaging), they are pretty good, though!

Yes, that cal docker in docker, for do it you need share the master's partition, please check https://github.com/jpetazzo/dind

Distributions often start with the SELinux reference policy rather than starting from scratch.

really? I don't mean understand how to apply a new label. I mean understand what the policies are and how they work, be able to create new ones that apply to you, and verify that the ones given to you by the distro are correct for your use. You're saying this is not hard to understand: https://github.com/SELinuxProject/refpolicy/blob/master/poli... ?

Otherwise you are blindly applying some black box.

selinux-refpolicy-src pulls from the original SELinux Project refpolicy repo and just install-src these, which just places all policies into appropriate directory and does nothing futher, i. e. doesn't compile them to make usable

https://github.com/SELinuxProject/refpolicy/blob/4412ad507c5880d9ff52fd376c23183cc9ae10b7/policy/support/misc_patterns.spt#L55

Of those distributions, only Fedora sets SELinux to enforcing by default. Moreover, AFAIK Fedora (+ RHEL and Android) are the only distributions that had wide testing of the reference policy [1] [2]. So, if you enable SELinux with the reference policy on the other distributions that you mention, it is likely that you will run into all kinds of issues.

[1] https://github.com/SELinuxProject/refpolicy

[2] https://github.com/fedora-selinux/selinux-policy

No default or reference policy is provided in openSUSE Leap. SELinux will not operate without a policy, so you must build and install one. The SELinux Reference Policy Project (https://github.com/SELinuxProject/refpolicy/wiki) should be helpful in providing examples and detailed information on creating your own policies, and this chapter also provides guidance on managing your SELinux policy.

Interesting. I don't have a red hat based system handy at the moment to compare since I'm on holiday. Maybe that's just how they set up shm? If you compare to Reference Policy, it appears that the getattr permission you asked about is granted there: https://github.com/SELinuxProject/refpolicy/blob/8a1bc98a31a9f2396f3c1389f43ffb10df31157f/policy/modules/system/systemd.te#L600