Jan so this is a container creating a tmpfs file? called temp?

Stephen is there a way to automatically transition this file to container_tmpfs_t?

(In reply to Daniel Walsh from comment #3)
> Jan so this is a container creating a tmpfs file? called temp?

Not strictly tmpfs -- memfd_create(2) says

       The memfd_create() system call provides a simple alternative to
       manually mounting a tmpfs(5) filesystem and creating and opening a
       file in that filesystem.  The primary purpose of memfd_create() is to
       create files and associated file descriptors that are used with the
       file-sealing APIs provided by fcntl(2).

The file name given in that https://github.com/voanhduy1512/memfd example is "Server memfd" but it's for debugging purposes only, really.

Right, but I see this as a potential SELinux issue, since we really want these things to be labeled based on the creating process.  Currently it looks like they all get the same label, and no easy way to isolate them on creation based on a transition rule.

type transition rules should work; internally memfd_create(2) uses shmem_file_setup().

I guess if we add this rule then the tmpfs file will be container_file_t.


fs_tmpfs_filetrans(container_t, container_file_t, { dir file })

Jan could you add a test policy to see if this fixes the issue?

(In reply to Daniel Walsh from comment #8)
> I guess if we add this rule then the tmpfs file will be container_file_t.
> 
> 
> fs_tmpfs_filetrans(container_t, container_file_t, { dir file })
> 
> Jan could you add a test policy to see if this fixes the issue?

I have

container-selinux-2.21-2.gitba103ac.el7.noarch
selinux-policy-devel-3.13.1-166.el7_4.4.noarch
policycoreutils-2.5-17.1.el7.x86_64
selinux-policy-3.13.1-166.el7_4.4.noarch
checkpolicy-2.5-4.el7.x86_64
policycoreutils-python-2.5-17.1.el7.x86_64
policycoreutils-devel-2.5-17.1.el7.x86_64
selinux-policy-targeted-3.13.1-166.el7_4.4.noarch

and I've created bz1488814.te containing

policy_module(bz1488814, 1.0)
fs_tmpfs_filetrans(container_t, container_file_t, { dir file })

and I've run

ln -s /usr/share/selinux/devel/Makefile
make

and got

Compiling targeted bz1488814 module
/usr/bin/checkmodule:  loading policy configuration from tmp/bz1488814.tmp
bz1488814.te:2:ERROR 'unknown type container_file_t' at token ';' on line 3226:
	allow container_file_t tmpfs_t:filesystem associate;
#line 2
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/bz1488814.mod] Error 1

What's the best way to let the module / compile stack know about the container_file_t which I assume comes from container-selinux?

In the end, I've patched container-selinux-2.21-2.gitba103ac.el7.src.rpm with

# cat ~/rpmbuild/SOURCES/bz1488814.patch
diff -ru container-selinux-ba103acc2c20164e3b566e966c280364bc0d99f5.orig/container.te container-selinux-ba103acc2c20164e3b566e966c280364bc0d99f5/container.te
--- container-selinux-ba103acc2c20164e3b566e966c280364bc0d99f5.orig/container.te	2017-08-08 16:14:11.000000000 -0400
+++ container-selinux-ba103acc2c20164e3b566e966c280364bc0d99f5/container.te	2017-10-11 05:25:32.294362007 -0400
@@ -745,3 +745,5 @@
 	allow svirt_lxc_net_t self:capability mknod;
 #	allow svirt_lxc_net_t self:cap_userns mknod;
 ')
+
+fs_tmpfs_filetrans(svirt_lxc_net_t, svirt_sandbox_file_t, { dir file })

and recompiled and upgraded.

I confirm that after that, docker run passes.

Sorry about that. I can not wait until RHEL7.5 (Hopefully) and we can finally start calling svirt_sandbox_file_t container_file_t.

Fixed in container-selinux-2.30

Fixing the component change.

# docker run --rm memfd
success

# rpm -q container-selinux
container-selinux-2.38-1.git8b2b119.el7.noarch

Move to verified.

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-2018:0195