[PATCH v5 0/3] lsm: introduce lsm_config_self_policy() and lsm_config_system_policy() syscalls
Maxime Bélair
maxime.belair at canonical.com
Fri Oct 10 13:34:15 UTC 2025
On 7/9/25 18:48, Casey Schaufler wrote:
> On 7/9/2025 1:00 AM, Maxime Bélair wrote:
>> This patchset introduces two new syscalls: lsm_config_self_policy(),
>> lsm_config_system_policy() and the associated Linux Security Module hooks
>> security_lsm_config_*_policy(), providing a unified interface for loading
>> and managing LSM policies. These syscalls complement the existing per‑LSM
>> pseudo‑filesystem mechanism and work even when those filesystems are not
>> mounted or available.
>>
>> With these new syscalls, users and administrators may lock down access to
>> the pseudo‑filesystem yet still manage LSM policies. Two tightly-scoped
>> entry points then replace the many file operations exposed by those
>> filesystems, significantly reducing the attack surface. This is
>> particularly useful in containers or processes already confined by
>> Landlock, where these pseudo‑filesystems are typically unavailable.
>>
>> Because they provide a logical and unified interface, these syscalls are
>> simpler to use than several heterogeneous pseudo‑filesystems and avoid
>> edge cases such as partially loaded policies. They also eliminates VFS
>> overhead, yielding performance gains notably when many policies are
>> loaded, for instance at boot time.
>>
>> This initial implementation is intentionally minimal to limit the scope
>> of changes. Currently, only policy loading is supported, and only
>> AppArmor registers this LSM hook. However, any LSM can adopt this
>> interface, and future patches could extend this syscall to support more
>> operations, such as replacing, removing, or querying loaded policies.
>
> It would help me be more confident in the interface if you also included
> hooks for SELinux and Smack. The API needs to be general enough to support
> SELinux's atomic policy load, Smack's atomic and incremental load options,
> and Smack's self rule loads. I really don't want to have to implement
> lsm_config_self_policy2() when I decide to us it for Smack.
>
I provided a minimal initial implementation for SELinux and Smack in v6.
For SELinux, I implemented only lsm_config_system_policy, which
currently allows to load policies with this syscall.
For Smack, I supported both hooks, allowing modification of both global
and subject rules. However since modifying even the subject rules is a
privileged operation, both operation are limited to CAP_MAC_ADMIN.
If we could ensure that the new rules only further restrict capabilities,
we could allow to load subject rules with fewer privileges.
>>
>> Landlock already provides three Landlock‑specific syscalls (e.g.
>> landlock_add_rule()) to restrict ambient rights for sets of processes
>> without touching any pseudo-filesystem. lsm_config_*_policy() generalizes
>> that approach to the entire LSM layer, so any module can choose to
>> support either or both of these syscalls, and expose its policy
>> operations through a uniform interface and reap the advantages outlined
>> above.
>>
>> This patchset is available at [1], a minimal user space example
>> showing how to use lsm_config_system_policy with AppArmor is at [2] and a
>> performance benchmark of both syscalls is available at [3].
>>
>> [1] https://github.com/emixam16/linux/tree/lsm_syscall
>> [2] https://gitlab.com/emixam16/apparmor/tree/lsm_syscall
>> [3] https://gitlab.com/-/snippets/4864908
>>
>> ---
>> Changes in v5
>> - Improve syscall input verification
>> - Do not export security_lsm_config_*_policy symbols
>>
>> Changes in v4
>> - Make the syscall's maximum buffer size defined per module
>> - Fix a memory leak
>>
>> Changes in v3
>> - Fix typos
>>
>> Changes in v2
>> - Split lsm_manage_policy() into two distinct syscalls:
>> lsm_config_self_policy() and lsm_config_system_policy()
>> - The LSM hook now calls only the appropriate LSM (and not all LSMs)
>> - Add a configuration variable to limit the buffer size of these
>> syscalls
>> - AppArmor now allows stacking policies through lsm_config_self_policy()
>> and loading policies in any namespace through
>> lsm_config_system_policy()
>> ---
>>
>> Maxime Bélair (3):
>> Wire up lsm_config_self_policy and lsm_config_system_policy syscalls
>> lsm: introduce security_lsm_config_*_policy hooks
>> AppArmor: add support for lsm_config_self_policy and
>> lsm_config_system_policy
>>
>> arch/alpha/kernel/syscalls/syscall.tbl | 2 +
>> arch/arm/tools/syscall.tbl | 2 +
>> arch/m68k/kernel/syscalls/syscall.tbl | 2 +
>> arch/microblaze/kernel/syscalls/syscall.tbl | 2 +
>> arch/mips/kernel/syscalls/syscall_n32.tbl | 2 +
>> arch/mips/kernel/syscalls/syscall_n64.tbl | 2 +
>> arch/mips/kernel/syscalls/syscall_o32.tbl | 2 +
>> arch/parisc/kernel/syscalls/syscall.tbl | 2 +
>> arch/powerpc/kernel/syscalls/syscall.tbl | 2 +
>> arch/s390/kernel/syscalls/syscall.tbl | 2 +
>> arch/sh/kernel/syscalls/syscall.tbl | 2 +
>> arch/sparc/kernel/syscalls/syscall.tbl | 2 +
>> arch/x86/entry/syscalls/syscall_32.tbl | 2 +
>> arch/x86/entry/syscalls/syscall_64.tbl | 2 +
>> arch/xtensa/kernel/syscalls/syscall.tbl | 2 +
>> include/linux/lsm_hook_defs.h | 4 +
>> include/linux/security.h | 20 +++++
>> include/linux/syscalls.h | 5 ++
>> include/uapi/asm-generic/unistd.h | 6 +-
>> include/uapi/linux/lsm.h | 8 ++
>> kernel/sys_ni.c | 2 +
>> security/apparmor/apparmorfs.c | 31 +++++++
>> security/apparmor/include/apparmor.h | 4 +
>> security/apparmor/include/apparmorfs.h | 3 +
>> security/apparmor/lsm.c | 84 +++++++++++++++++++
>> security/lsm_syscalls.c | 25 ++++++
>> security/security.c | 60 +++++++++++++
>> tools/include/uapi/asm-generic/unistd.h | 6 +-
>> .../arch/x86/entry/syscalls/syscall_64.tbl | 2 +
>> 29 files changed, 288 insertions(+), 2 deletions(-)
>>
>>
>> base-commit: 9c32cda43eb78f78c73aee4aa344b777714e259b
More information about the Linux-security-module-archive
mailing list