| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20250129203932.22165-1-wufan@kernel.org> Date: Wed, 29 Jan 2025 20:39:30 +0000 From: wufan@...nel.org To: corbet@....net, jmorris@...ei.org, paul@...l-moore.com, serge@...lyn.com, akpm@...ux-foundation.org Cc: linux-doc@...r.kernel.org, linux-security-module@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Fan Wu <wufan@...nel.org> Subject: [RFC PATCH v2 0/2] ipe support for anonymous memory and memfd From: Fan Wu <wufan@...nel.org> This patchset adds support for anonymous memory and memfd to the IPE LSM. Currently, the IPE policy language can only allow or deny a physical file from an integrity-verified source. However, for events triggered by anonymous memory, either created via mmap() with MAP_ANONYMOUS or via memfd_create(), IPE provides no mechanism to explicitly allow or deny these events. Execution from anonymous memory is a common use case in modern applications. For example, JIT compilers store generated code in such regions. This patchset introduces a new IPE property, anonymous_memory, to let administrators explicitly allow or deny events triggered by anonymous memory. For example, the following policy: policy_name=example_policy policy_version=0.0.0 DEFAULT action=DENY op=EXECUTE dmverity_signature=TRUE action=ALLOW op=EXECUTE anonymous_memory=TRUE action=ALLOW will allow execution of files from a signed dm-verity volume and also execution from anonymous memory. In the current design, the anonymous_memory property covers both memory regions created by mmap() with MAP_ANONYMOUS and those allocated by memfd_create(), as both share the same semantics [1]. However, because regular files on tmpfs, shmemfs, or hugetlbfs are also backed by anonymous memory, the policy language might not be entirely clear to users. An alternative approach would be to define two separate properties, one covering MAP_ANONYMOUS and another covering memfd_create(). Nonetheless, allowing execution from anonymous memory does increase the attack surface. Future work will add additional properties to the IPE policy language to provide more fine-grained control. For instance, one possibility is to permit only processes with certain security attributes, such as specific SELinux labels, to execute code from anonymous memory. The ipe test suite has been updated to include anonymous memory tests: https://github.com/microsoft/ipe/tree/test-suite [1] https://man7.org/linux/man-pages/man2/memfd_create.2.html Previous Postings ----------------- v1: https://lore.kernel.org/all/66922c42-c3a2-4634-a8f0-4c8c2b4c051a@kernel.org/T/ Changelog --------- V2: * Update test suite to include anonymous memory tests * Fix property implementation and add memfd support Fan Wu (2): memfd,lsm: add a security hook to memfd_create() ipe: add 'anonymous_memory' property for policy decisions Documentation/admin-guide/LSM/ipe.rst | 12 ++++++++++ Documentation/security/ipe.rst | 9 +++---- include/linux/lsm_hook_defs.h | 3 +++ include/linux/security.h | 8 +++++++ mm/memfd.c | 2 ++ security/ipe/Kconfig | 10 ++++++++ security/ipe/audit.c | 2 ++ security/ipe/eval.c | 34 +++++++++++++++++++++++---- security/ipe/eval.h | 13 ++++++---- security/ipe/hooks.c | 12 ++++++++++ security/ipe/hooks.h | 4 ++++ security/ipe/ipe.c | 7 ++++-- security/ipe/policy.h | 2 ++ security/ipe/policy_parser.c | 4 ++++ security/security.c | 11 +++++++++ 15 files changed, 119 insertions(+), 14 deletions(-) -- 2.47.1
Powered by blists - more mailing lists