Description of problem:
When running a rootful container in podman or any container engine, it is quite possible to mount the host's /proc into the container, but not anything that is inside of /proc/net as it exists as a symlink to /proc/self/net and is made with unconfined_t as it's default.

As an example:

# podman run --privileged --rm -ti -v /proc/self/net:/mnt/rootfs/proc/net nginx bash -c "ls /mnt/rootfs/proc/net &>/dev/null && echo Works"
Error: set propagation for `mnt/rootfs/proc/net`: Permission denied: OCI runtime permission denied error

The audit log shows a mounton denial:

time->Wed Sep 30 09:40:07 2020 type=AVC msg=audit(1601473207.260:1108): avc:  denied  { mounton } for  pid=124478 comm="3" path="/var/lib/containers/storage/overlay/6a99a39e08844c64719eb6b409f2c3c1c45f7cc5934f563cf3adf6e043fee2ba/merged/mnt/rootfs/proc/net" dev="proc" ino=801978 scontext=unconfined_u:system_r:container_runtime_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=dir permissive=0

Which is expected as the /proc/net directory is a symlink to /proc/self/net to account for the current process's network namespace:

# ls -lZd /proc
dr-xr-xr-x. 413 root root system_u:object_r:proc_t:s0 0 Sep 24 18:53 /proc

# ls -lZd /proc/net
lrwxrwxrwx. 1 root root system_u:object_r:proc_t:s0 8 Sep 24 18:53 /proc/net -> self/net

# ls -lZd /proc/self/net
dr-xr-xr-x. 65 root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 Sep 30 10:04 /proc/self/net

This commit (https://github.com/containers/container-selinux/commit/028ab0049681265664a3bbae7501bc5bddcd6cc0) in container-selinux allows for the addition of containers to mount /proc and no longer get mounton denials, but obviously as the /proc/net and /proc/self/net are made on-demand by the process of spawning a new process, they are assigned a default unconfined_t and therefore appear rejected.

I understand the reason for this is that, since /proc/net is just a reflection of the host's init_net network namespace in /proc/self/net, it is made with unconfined_t at the time the new process spawns; because of this, however, we are forced to mount all of /proc and mounting in /proc/net or /proc/self/net isn't possible.

Is it expected that in order to have access to /proc/net on the host, you will have to mount in all of /proc, or is there a way to allow /proc/self/net to have type proc_t and therefore get around having to provide access to the entirety of the host?  Or is this risky to do/no way to do this on SELinux enabled systems?

Also note this isn't denied outside of a container, just within it; doing `mount --bind` on /proc/net/self will work (but not in a container context).

Version-Release number of selected component (if applicable):
Any OpenShift version, any podman/crio build
Tested with container-selinux-2.145.0-1.fc32.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Run podman command to mount /proc/net and observe error:

# podman run --privileged --rm -ti -v /proc/self/net:/mnt/rootfs/proc/net nginx bash -c "ls /mnt/rootfs/proc/net &>/dev/null && echo Works"
Error: set propagation for `mnt/rootfs/proc/net`: Permission denied: OCI runtime permission denied error

2. Use ausearch to find denial audit log:

time->Wed Sep 30 09:40:07 2020 type=AVC msg=audit(1601473207.260:1108): avc:  denied  { mounton } for  pid=124478 comm="3" path="/var/lib/containers/storage/overlay/6a99a39e08844c64719eb6b409f2c3c1c45f7cc5934f563cf3adf6e043fee2ba/merged/mnt/rootfs/proc/net" dev="proc" ino=801978 scontext=unconfined_u:system_r:container_runtime_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=dir permissive=0

Actual results:
Mounting is denied with `mounton` as /proc/net/self is unconfined_t and container-selinux only accounts for proc_t within /proc.

Expected results:
Mounting (should?) allow /proc/net to be mounted into a contianer

Additional info:
For anyone experiencing this, current workaround is just to mount all of /proc into the container, that will work fine assuming SElinux is enforcing, the container is privileged, and if in OpenShift your SCC is properly configured.