Re: [RFC PATCH v2 1/1] exec: seal system mappings
From: Kees Cook
Date: Wed Oct 16 2024 - 17:26:24 EST
(I don't think this needs "RFC" any more)
On Mon, Oct 14, 2024 at 09:50:20PM +0000, jeffxu@xxxxxxxxxxxx wrote:
> From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing during the life time of the process. For
> complete descriptions of memory sealing, please see mseal.rst [1].
>
> System mappings such as vdso, vvar, and sigpage (for arm) are
> generated by the kernel during program initialization. These mappings
> are designated as non-writable, and sealing them will prevent them
> from ever becoming writeable.
>
> Unlike the aforementioned mappings, the uprobe mapping is not
> established during program startup. However, its lifetime is the same
> as the process's lifetime [2], thus sealable.
>
> The vdso, vvar, sigpage, and uprobe mappings all invoke the
> _install_special_mapping() function. As no other mappings utilize this
> function, it is logical to incorporate sealing logic within
> _install_special_mapping(). This approach avoids the necessity of
> modifying code across various architecture-specific implementations.
>
> The vsyscall mapping, which has its own initialization function, is
> sealed in the XONLY case, it seems to be the most common and secure
> case of using vsyscall.
>
> It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may
> alter the mapping of vdso, vvar, and sigpage during restore
> operations. Consequently, this feature cannot be universally enabled
> across all systems. To address this, a kernel configuration option has
> been introduced to enable or disable this functionality. Note, uprobe
> is always sealed and not controlled by this kernel configuration.
>
> [1] Documentation/userspace-api/mseal.rst
> [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@xxxxxxxxxxxxxx/
>
> Signed-off-by: Jeff Xu <jeffxu@xxxxxxxxxxxx>
> ---
> .../admin-guide/kernel-parameters.txt | 10 ++++
> arch/x86/entry/vsyscall/vsyscall_64.c | 9 +++-
> fs/exec.c | 53 +++++++++++++++++++
> include/linux/fs.h | 1 +
> kernel/events/uprobes.c | 2 +-
> mm/mmap.c | 1 +
> security/Kconfig | 26 +++++++++
> 7 files changed, 99 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index e7bfe1bde49e..02e5eb23d76f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1538,6 +1538,16 @@
> Permit 'security.evm' to be updated regardless of
> current integrity status.
>
> + exec.seal_system_mappings = [KNL]
> + Format: { never | always }
> + Seal system mappings: vdso, vvar, sigpage, uprobes,
> + vsyscall.
> + This overwrites KCONFIG CONFIG_SEAL_SYSTEM_MAPPINGS_*
> + - 'never': never seal system mappings.
> + - 'always': always seal system mappings.
> + If not specified or invalid, default is the KCONFIG value.
> + This option has no effect if CONFIG_64BIT=n
> +
Any reason for "always"/"never" instead of the more traditional y/n
enabled/disabled, etc?
Otherwise, this all makes sense to me.
--
Kees Cook