| Message ID | 20211115185304.198460-1-mic@digikod.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add trusted_for(2) (was O_MAYEXEC) | expand |
Hello Al, I think there is no more comment on this series, everything has been addressed. Could you please consider to merge this into your tree or push it to linux-next? Regards, Mickaël On 15/11/2021 19:53, Mickaël Salaün wrote: > Hi, > > This new patch series fix the syscall signature as suggested by > Alejandro Colomar. It applies on Linus's master branch (v5.16-rc1) and > next-20211115. > > Andrew, can you please consider to merge this into your tree? > > Overview > ======== > > The final goal of this patch series is to enable the kernel to be a > global policy manager by entrusting processes with access control at > their level. To reach this goal, two complementary parts are required: > * user space needs to be able to know if it can trust some file > descriptor content for a specific usage; > * and the kernel needs to make available some part of the policy > configured by the system administrator. > > Primary goal of trusted_for(2) > ============================== > > This new syscall enables user space to ask the kernel: is this file > descriptor's content trusted to be used for this purpose? The set of > usage currently only contains execution, but other may follow (e.g. > configuration, sensitive data). If the kernel identifies the file > descriptor as trustworthy for this usage, user space should then take > this information into account. The "execution" usage means that the > content of the file descriptor is trusted according to the system policy > to be executed by user space, which means that it interprets the content > or (try to) maps it as executable memory. > > A simple system-wide security policy can be set by the system > administrator through a sysctl configuration consistent with the mount > points or the file access rights. The documentation explains the > prerequisites. > > It is important to note that this can only enable to extend access > control managed by the kernel. Hence it enables current access control > mechanism to be extended and become a superset of what they can > currently control. Indeed, the security policy could also be delegated > to an LSM, either a MAC system or an integrity system. For instance, > this is required to close a major IMA measurement/appraisal interpreter > integrity gap by bringing the ability to check the use of scripts [1]. > Other uses are expected, such as for magic-links [2], SGX integration > [3], bpffs [4]. > > Complementary W^X protections can be brought by SELinux, IPE [5] and > trampfd [6]. > > System call description > ======================= > > trusted_for(int fd, enum trusted_for_usage usage, u32 flags); > > @fd is the file descriptor to check. > > @usage identifies the user space usage intended for @fd: only > TRUSTED_FOR_EXECUTION for now, but trusted_for_usage could be extended > to identify other usages (e.g. configuration, sensitive data). > > @flags must be 0 for now but it could be used in the future to do > complementary checks (e.g. signature or integrity requirements, origin > of the file). > > This system call returns 0 on success, or -EACCES if the kernel policy > denies the specified usage (which should be enforced by the caller). > > The first patch contains the full syscall and sysctl documentation. > > Prerequisite of its use > ======================= > > User space needs to adapt to take advantage of this new feature. For > example, the PEP 578 [7] (Runtime Audit Hooks) enables Python 3.8 to be > extended with policy enforcement points related to code interpretation, > which can be used to align with the PowerShell audit features. > Additional Python security improvements (e.g. a limited interpreter > without -c, stdin piping of code) are on their way [8]. > > Examples > ======== > > The initial idea comes from CLIP OS 4 and the original implementation > has been used for more than 13 years: > https://github.com/clipos-archive/clipos4_doc > Chrome OS has a similar approach: > https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md > > Userland patches can be found here: > https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC > Actually, there is more than the O_MAYEXEC changes (which matches this search) > e.g., to prevent Python interactive execution. There are patches for > Bash, Wine, Java (Icedtea), Busybox's ash, Perl and Python. There are > also some related patches which do not directly rely on O_MAYEXEC but > which restrict the use of browser plugins and extensions, which may be > seen as scripts too: > https://github.com/clipos-archive/clipos4_portage-overlay/tree/master/www-client > > An introduction to O_MAYEXEC was given at the Linux Security Summit > Europe 2018 - Linux Kernel Security Contributions by ANSSI: > https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s > The "write xor execute" principle was explained at Kernel Recipes 2018 - > CLIP OS: a defense-in-depth OS: > https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s > See also a first LWN article about O_MAYEXEC and a new one about > trusted_for(2) and its background: > * https://lwn.net/Articles/820000/ > * https://lwn.net/Articles/832959/ > > This can be tested with CONFIG_SYSCTL. I would really appreciate > constructive comments on this patch series. > > [1] https://lore.kernel.org/lkml/20211014130125.6991-1-zohar@linux.ibm.com/ > [2] https://lore.kernel.org/lkml/20190904201933.10736-6-cyphar@cyphar.com/ > [3] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=z2T_cNrpvMig@mail.gmail.com/ > [4] https://lore.kernel.org/lkml/CALCETrVeZ0eufFXwfhtaG_j+AdvbzEWE0M3wjXMWVEO7pj+xkw@mail.gmail.com/ > [5] https://lore.kernel.org/lkml/20200406221439.1469862-12-deven.desai@linux.microsoft.com/ > [6] https://lore.kernel.org/lkml/20200922215326.4603-1-madvenka@linux.microsoft.com/ > [7] https://www.python.org/dev/peps/pep-0578/ > [8] https://lore.kernel.org/lkml/0c70debd-e79e-d514-06c6-4cd1e021fa8b@python.org/ > > Previous versions: > v16: https://lore.kernel.org/r/20211110190626.257017-1-mic@digikod.net/ > v15: https://lore.kernel.org/r/20211012192410.2356090-1-mic@digikod.net/ > v14: https://lore.kernel.org/r/20211008104840.1733385-1-mic@digikod.net/ > v13: https://lore.kernel.org/r/20211007182321.872075-1-mic@digikod.net/ > v12: https://lore.kernel.org/r/20201203173118.379271-1-mic@digikod.net/ > v11: https://lore.kernel.org/r/20201019164932.1430614-1-mic@digikod.net/ > v10: https://lore.kernel.org/r/20200924153228.387737-1-mic@digikod.net/ > v9: https://lore.kernel.org/r/20200910164612.114215-1-mic@digikod.net/ > v8: https://lore.kernel.org/r/20200908075956.1069018-1-mic@digikod.net/ > v7: https://lore.kernel.org/r/20200723171227.446711-1-mic@digikod.net/ > v6: https://lore.kernel.org/r/20200714181638.45751-1-mic@digikod.net/ > v5: https://lore.kernel.org/r/20200505153156.925111-1-mic@digikod.net/ > v4: https://lore.kernel.org/r/20200430132320.699508-1-mic@digikod.net/ > v3: https://lore.kernel.org/r/20200428175129.634352-1-mic@digikod.net/ > v2: https://lore.kernel.org/r/20190906152455.22757-1-mic@digikod.net/ > v1: https://lore.kernel.org/r/20181212081712.32347-1-mic@digikod.net/ > > Regards, > > Mickaël Salaün (3): > fs: Add trusted_for(2) syscall implementation and related sysctl > arch: Wire up trusted_for(2) > selftest/interpreter: Add tests for trusted_for(2) policies > > Documentation/admin-guide/sysctl/fs.rst | 50 +++ > arch/alpha/kernel/syscalls/syscall.tbl | 2 + > arch/arm/tools/syscall.tbl | 1 + > arch/arm64/include/asm/unistd.h | 2 +- > arch/arm64/include/asm/unistd32.h | 2 + > arch/ia64/kernel/syscalls/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 | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > arch/xtensa/kernel/syscalls/syscall.tbl | 2 + > fs/open.c | 111 ++++++ > include/linux/fs.h | 1 + > include/linux/syscalls.h | 1 + > include/uapi/asm-generic/unistd.h | 4 +- > include/uapi/linux/trusted-for.h | 18 + > kernel/sysctl.c | 12 +- > tools/testing/selftests/Makefile | 1 + > .../testing/selftests/interpreter/.gitignore | 2 + > tools/testing/selftests/interpreter/Makefile | 21 + > tools/testing/selftests/interpreter/config | 1 + > .../selftests/interpreter/trust_policy_test.c | 362 ++++++++++++++++++ > 30 files changed, 613 insertions(+), 4 deletions(-) > create mode 100644 include/uapi/linux/trusted-for.h > create mode 100644 tools/testing/selftests/interpreter/.gitignore > create mode 100644 tools/testing/selftests/interpreter/Makefile > create mode 100644 tools/testing/selftests/interpreter/config > create mode 100644 tools/testing/selftests/interpreter/trust_policy_test.c > > > base-commit: 8ab774587903771821b59471cc723bba6d893942 >
* Mickaël Salaün: > Primary goal of trusted_for(2) > ============================== > > This new syscall enables user space to ask the kernel: is this file > descriptor's content trusted to be used for this purpose? The set of > usage currently only contains execution, but other may follow (e.g. > configuration, sensitive data). If the kernel identifies the file > descriptor as trustworthy for this usage, user space should then take > this information into account. The "execution" usage means that the > content of the file descriptor is trusted according to the system policy > to be executed by user space, which means that it interprets the content > or (try to) maps it as executable memory. I sketched my ideas about “IMA gadgets” here: IMA gadgets <https://www.openwall.com/lists/oss-security/2021/11/30/1> I still don't think the proposed trusted_for interface is sufficient. The example I gave is a Perl module that does nothing (on its own) when loaded as a Perl module (although you probably don't want to sign it anyway, given what it implements), but triggers an unwanted action when sourced (using .) as a shell script. > @usage identifies the user space usage intended for @fd: only > TRUSTED_FOR_EXECUTION for now, but trusted_for_usage could be extended > to identify other usages (e.g. configuration, sensitive data). We would need TRUSTED_FOR_EXECUTION_BY_BASH, TRUSTED_FOR_EXECUTION_BY_PERL, etc. I'm not sure that actually works. Caller process context does not work because we have this confusion internally between glibc's own use (for the dynamic linker configuration), and for loading programs/shared objects (there seems to be a corner case where you can execute arbitrary code even without executable mappings in the ELF object), and the script interpreter itself (the primary target for trusted_for). But for generating auditing events, trusted_for seems is probably quite helpful. Thanks, Florian
On 30/11/2021 21:27, Florian Weimer wrote: > * Mickaël Salaün: > >> Primary goal of trusted_for(2) >> ============================== >> >> This new syscall enables user space to ask the kernel: is this file >> descriptor's content trusted to be used for this purpose? The set of >> usage currently only contains execution, but other may follow (e.g. >> configuration, sensitive data). If the kernel identifies the file >> descriptor as trustworthy for this usage, user space should then take >> this information into account. The "execution" usage means that the >> content of the file descriptor is trusted according to the system policy >> to be executed by user space, which means that it interprets the content >> or (try to) maps it as executable memory. > > I sketched my ideas about “IMA gadgets” here: > > IMA gadgets > <https://www.openwall.com/lists/oss-security/2021/11/30/1> > > I still don't think the proposed trusted_for interface is sufficient. > The example I gave is a Perl module that does nothing (on its own) when > loaded as a Perl module (although you probably don't want to sign it > anyway, given what it implements), but triggers an unwanted action when > sourced (using .) as a shell script. The fact that IMA doesn't cover all metadata, file names nor the file hierarchies is well known and the solution can be implemented with dm-verity (which has its own drawbacks). trusted_for is a tool for interpreters to enforce a security policy centralized by the kernel. The kind of file confusion attacks you are talking about should be addressed by a system policy. If the mount point options are not enough to express such policy, then we need to rely on IMA, SELinux or IPE to reduce the scope of legitimate mapping between scripts and interpreters. > >> @usage identifies the user space usage intended for @fd: only >> TRUSTED_FOR_EXECUTION for now, but trusted_for_usage could be extended >> to identify other usages (e.g. configuration, sensitive data). > > We would need TRUSTED_FOR_EXECUTION_BY_BASH, > TRUSTED_FOR_EXECUTION_BY_PERL, etc. I'm not sure that actually works. Well, this doesn't scale and that is the reason trusted_for usage is more generic. The kernel already has all the information required to identify scripts and interpreters types. We don't need to make the user space interface more complex by listing all types. The kernel only miss the semantic of how the intrepreter wants to interpret files, and that is the purpose of trusted_for. LSMs are designed to define complex policies and trusted_for enables them to extend such policies. > > Caller process context does not work because we have this confusion > internally between glibc's own use (for the dynamic linker > configuration), and for loading programs/shared objects (there seems to > be a corner case where you can execute arbitrary code even without > executable mappings in the ELF object), and the script interpreter > itself (the primary target for trusted_for). The current use case for trusted_for is script interpreters, but we can extend the trusted_for_usage enum with new usages like TRUSTED_FOR_LINK and others. I'm not convinced glibc should be treated differently than other executable code that want to load a shared library, but it is a discussion we can have when trusted_for will be in mainline and someone will propose a new usage. ;) > > But for generating auditing events, trusted_for seems is probably quite > helpful. Indeed, it enables to add semantic to audit events.
On Wed, 2021-12-01 at 10:23 +0100, Mickaël Salaün wrote: > On 30/11/2021 21:27, Florian Weimer wrote: > > * Mickaël Salaün: > > > >> Primary goal of trusted_for(2) > >> ============================== > >> > >> This new syscall enables user space to ask the kernel: is this file > >> descriptor's content trusted to be used for this purpose? The set of > >> usage currently only contains execution, but other may follow (e.g. > >> configuration, sensitive data). If the kernel identifies the file > >> descriptor as trustworthy for this usage, user space should then take > >> this information into account. The "execution" usage means that the > >> content of the file descriptor is trusted according to the system policy > >> to be executed by user space, which means that it interprets the content > >> or (try to) maps it as executable memory. > > > > I sketched my ideas about “IMA gadgets” here: > > > > IMA gadgets > > <https://www.openwall.com/lists/oss-security/2021/11/30/1> > > > > I still don't think the proposed trusted_for interface is sufficient. > > The example I gave is a Perl module that does nothing (on its own) when > > loaded as a Perl module (although you probably don't want to sign it > > anyway, given what it implements), but triggers an unwanted action when > > sourced (using .) as a shell script. > > The fact that IMA doesn't cover all metadata, file names nor the file > hierarchies is well known and the solution can be implemented with > dm-verity (which has its own drawbacks). Thanks, Mickaël, for responding. I'll go even farther and say that IMA wasn't ever meant to protect file metadata. Another option is EVM, which addresses some, but not all of the issues. thanks, Mimi > > trusted_for is a tool for interpreters to enforce a security policy > centralized by the kernel. The kind of file confusion attacks you are > talking about should be addressed by a system policy. If the mount point > options are not enough to express such policy, then we need to rely on > IMA, SELinux or IPE to reduce the scope of legitimate mapping between > scripts and interpreters.
On Mon, Nov 15, 2021 at 07:53:01PM +0100, Mickaël Salaün wrote:
> Andrew, can you please consider to merge this into your tree?
Friendly ping to akpm. :)
Can this start living in -mm, or would a different tree be better?
Thanks!
-Kees