Bug 1488814
| Summary: | ftruncate on memfd_create'd fd fails in container, with AVC denial | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jan Pazdziora (Red Hat) <jpazdziora> |
| Component: | container-selinux | Assignee: | Lokesh Mandvekar <lsm5> |
| Status: | CLOSED ERRATA | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | dwalsh, jpazdziora, lsu, lvrabec, mgrepl, mguillemot, pmoore, sdsmall, voanhduy1512 |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-01-25 12:56:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jan Pazdziora (Red Hat)
2017-09-06 09:13:50 UTC
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 |