container_t versus svirt_lxc_net_t
For some reason recently I have been asked via email and twitter about what the difference is between the container_t type and the svirt_lxc_net_t type. Or similarly between container_file_t and svirt_sandbox_file_t. Bottom line, NOTHING. They are aliases of each other.
In SELinux policy language they have a typealias command.
typealias container_t alias svirt_lxc_net_t;
typealias container_file_t alias svirt_sandbox_file_t;
When I first started working on containers and SELinux prior to Docker, we were writing a tool called virt-sandbox that used libvirt to launch containers, specifically it used libvirt-lxc. We had labeled all of the VMs launched by libvirt, svirt_t. This stood for secure virt. When I decided to write policy for the libvirt_lxc containers, I created a type called svirt_lxc_t. This type was not allowed to do network access, so I added another type called svirt_lxc_net_t that had full network access. The type for content that he svirt_lxc types could manage as svirt_sandbox_file_t. (svirt_file_t was already used for virtual machine images.) Why I did not call it svirt_lxc_file_t, I don't know.
When Docker exploded on the scene we quickly adapted the SELinux policy we had written for virt-sandbot to work with Docker and that is how these types got associated with containers. After a few years of using this and constantly telling people that svirt_lxc_net_t was the type of a container process, I figured it was time to change the type name. I created container_t and container_file_t and then just aliased the old names to the new.
One problem was that RHEL policy updated much slower and we were not able to get these changes in untile RHEL7.5 (Or maybe RHEL7.4, I don't remember). But for now on we will use the new type names.
One issue you have with technology is the old howto's and information out on the internet never goes away. If someone googles how to label a volume so that it works with a container and SELinux, they are likely to get told to label the content svirt_sandbox_file_t.
This is not an issue with the type aliases. If you have scripts or customer policy modules that use the old names you are fine. Since the old names will still work.
But I would prefer that everyone just use the newer easily understandable types.