BTW, this is no AVC messages in logs.

Maybe there are dontaudit rules involved. Please run "semodule -DB" and then repeat your scenario. Do you see any AVCs now?

Yes.

----
time->Thu Apr  6 09:32:26 2017
type=SYSCALL msg=audit(1491485546.339:1973): arch=c000003e syscall=166 success=no exit=-13 a0=555e7f186a00 a1=0 a2=1 a3=7ffd0e7ee8c0 items=0 ppid=30429 pid=30469 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=4294967295 comm="umount" exe="/usr/bin/umount" subj=system_u:system_r:svirt_lxc_net_t:s0:c350,c905 key=(null)
type=AVC msg=audit(1491485546.339:1973): avc:  denied  { unmount } for  pid=30469 comm="umount" scontext=system_u:system_r:svirt_lxc_net_t:s0:c350,c905 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c350,c905 tclass=filesystem

I don't know why the mount worked.  Since container_t is not allowed to mount container_file_t?  That should have broken.  Being able to mount and umount of container_file_t, is a questionable allow.  If all it would allow is the bind mount then we would be pretty safe, but I am not sure.

Eric, Paul and Stephen, how dangerous would it be to add

allow container_t container_file_t:filesystem { mount umount} and then rely on seccomp and SYS_ADMIN capability to control this access?

(In reply to Daniel Walsh from comment #5)
> I don't know why the mount worked.  Since container_t is not allowed to
> mount container_file_t?  That should have broken.  Being able to mount and
> umount of container_file_t, is a questionable allow.  If all it would allow
> is the bind mount then we would be pretty safe, but I am not sure.

1) Looks like the domain is svirt_lxc_net_t, not container_t, per the AVC message for unmount.

2) You allow that domain mounton permission, which is all that is required (in addition to sys_admin capability) in order to perform a bind mount.
sesearch -A -s svirt_lxc_net_t -p mounton
Found 1 semantic av rules:
 allow svirt_sandbox_domain svirt_sandbox_file_t : dir { ioctl read write create getattr setattr lock unlink link rename mounton add_name remove_name reparent search rmdir open };

You also allow this between container_t and container_file_t in Fedora, via two different rules.

(In reply to Daniel Walsh from comment #6)
> Eric, Paul and Stephen, how dangerous would it be to add
> 
> allow container_t container_file_t:filesystem { mount umount} and then rely
> on seccomp and SYS_ADMIN capability to control this access?

At that point you are no longer using SELinux to restrict the container, right, at least wrt mounting.  Obviously that is no longer a MAC solution.

sys_admin is required in policy in order to mount.  With the cap_userns patches (not in RHEL7 AFAIK, it is commit 8e4ff6f228e4722cac74db716e308d1da33d744f upstream), you can allow self:cap_userns sys_admin; to permit it within a container without allowing it in the init/global namespace; however, you do not appear to be leveraging this even in Fedora yet (i.e. you are still allowing container_t self:capability ...; allow container_t self:capability2 ...; even though it should only require allow container_t self:cap_userns ...; allow container_t self:cap2_userns ...;).  That would be a MAC solution; you would then know that a container could never exercise those capabilities on the init/global namespace.

We are not running containers by default with user namespace yet.  No file system support is blocking this.  Currently we don't do much control over capabilities from an SELinux point of view, we pretty much allow all caps, since it is difficult to work with --cap-add and --cap-drop with SELinux types as we can with caps and seccomp rules.

Handling mount is something we currently partially control.  But I am not sure it is worth it from a container perspective.  I could add a boolean to allow containers to mount/remount/umount container_file_t file systems.

Fixed in container-selinux-2.28

This bug has been verified in container-selinux-2.28-1.git85ce147.el7.noarch.

[ajia@localhost ~]$ rpm -qa|grep selinux
libselinux-python-2.5-11.el7.x86_64
selinux-policy-3.13.1-166.el7.noarch
selinux-policy-targeted-3.13.1-166.el7.noarch
libselinux-2.5-11.el7.x86_64
container-selinux-2.28-1.git85ce147.el7.noarch
libselinux-utils-2.5-11.el7.x86_64

[ajia@localhost ~]$ sudo getenforce
Enforcing

[ajia@localhost ~]$ sudo docker run -it --rm --cap-add SYS_ADMIN rhel7 bash
[root@48c52b60baa1 /]# mount -o bind /mnt/ /mnt/
[root@48c52b60baa1 /]# umount /mnt/
[root@48c52b60baa1 /]# df
Filesystem            1K-blocks    Used Available Use% Mounted on
overlay                52403200 6595468  45807732  13% /
tmpfs                   3976040       0   3976040   0% /dev
tmpfs                   3976040       0   3976040   0% /sys/fs/cgroup
/dev/mapper/rhel-root  52403200 6595468  45807732  13% /etc/hosts
shm                       65536       0     65536   0% /dev/shm
tmpfs                   3976040       0   3976040   0% /sys/firmware

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2969