linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: wufan@kernel.org
To: corbet@lwn.net, jmorris@namei.org, paul@paul-moore.com,
	serge@hallyn.com, akpm@linux-foundation.org
Cc: linux-doc@vger.kernel.org, linux-security-module@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Fan Wu <wufan@kernel.org>
Subject: [RFC PATCH v2 0/2] ipe support for anonymous memory and memfd
Date: Wed, 29 Jan 2025 20:39:30 +0000	[thread overview]
Message-ID: <20250129203932.22165-1-wufan@kernel.org> (raw)

From: Fan Wu <wufan@kernel.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



             reply	other threads:[~2025-01-29 20:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29 20:39 wufan [this message]
2025-01-29 20:39 ` [RFC PATCH v2 1/2] memfd,lsm: add a security hook to memfd_create() wufan
2025-01-29 20:39 ` [RFC PATCH v2 2/2] ipe: add 'anonymous_memory' property for policy decisions wufan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250129203932.22165-1-wufan@kernel.org \
    --to=wufan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=jmorris@namei.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox