linux-kernel - Re: [PATCH v4 1/1] exec: seal system mappings

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANaxB-wvHERPBu+17b5GP3pVv7pC8J0dkK9MUG1tSir4PQx=ZQ@mail.gmail.com>
Date: Mon, 9 Dec 2024 20:12:33 -0800
From: Andrei Vagin <avagin@...il.com>
To: jeffxu@...omium.org
Cc: akpm@...ux-foundation.org, keescook@...omium.org, jannh@...gle.com, 
	torvalds@...ux-foundation.org, adhemerval.zanella@...aro.org, oleg@...hat.com, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, 
	linux-mm@...ck.org, jorgelo@...omium.org, sroettger@...gle.com, 
	ojeda@...nel.org, adobriyan@...il.com, anna-maria@...utronix.de, 
	mark.rutland@....com, linus.walleij@...aro.org, Jason@...c4.com, 
	deller@....de, rdunlap@...radead.org, davem@...emloft.net, hch@....de, 
	peterx@...hat.com, hca@...ux.ibm.com, f.fainelli@...il.com, gerg@...nel.org, 
	dave.hansen@...ux.intel.com, mingo@...nel.org, ardb@...nel.org, 
	Liam.Howlett@...cle.com, mhocko@...e.com, 42.hyeyoo@...il.com, 
	peterz@...radead.org, ardb@...gle.com, enh@...gle.com, rientjes@...gle.com, 
	groeck@...omium.org, mpe@...erman.id.au, 
	Dmitry Safonov <0x7f454c46@...il.com>, Mike Rapoport <mike.rapoport@...il.com>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>, Andrei Vagin <avagin@...gle.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On Mon, Nov 25, 2024 at 12:49 PM <jeffxu@...omium.org> wrote:
>
> From: Jeff Xu <jeffxu@...omium.org>
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped 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, and are
> sealed after creation.
>
> 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]. It is sealed from creation.
>
> 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.
>
...
>
> +config SEAL_SYSTEM_MAPPINGS
> +       bool "seal system mappings"
> +       default n
> +       depends on 64BIT
> +       depends on ARCH_HAS_SEAL_SYSTEM_MAPPINGS
> +       depends on !CHECKPOINT_RESTORE

Hi Jeff,

I like the idea of this patchset, but I don’t like the idea of
forcing users to choose between this security feature and
checkpoint/restore functionality. We need to explore ways to make this
feature work with checkpoint/restore. Relying on CAP_CHECKPOINT_RESTORE
is the obvious approach.

CRIU just needs to move these mappings, and it doesn't need to change
their properties or modify their contents. With that in mind, here are
two options:
* Allow moving sealed mappings for processes with CAP_CHECKPOINT_RESTORE.
* Allow temporarily "unsealing" mappings for processes with
  CAP_CHECKPOINT_RESTORE. CRIU could unseal mappings, move them, and
  then seal them back.

Another approach might be to make this feature configurable on a
per-process basis (e.g., via prctl). Once enabled for a process, it
would be inherited by all its children. It can't be disabled unless a
process has CAP_CHECKPOINT_RESTORE.

I've added Mike, Dima, and Alex to the thread. They might have
other ideas.

Thanks,
Andrei