[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABi2SkUfKzutFJLv0q42LRU-YDjNzMBmmZ0NKXNwGhQVoJ_bfg@mail.gmail.com>
Date: Wed, 16 Oct 2024 20:56:36 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: Kees Cook <kees@...nel.org>
Cc: akpm@...ux-foundation.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, lorenzo.stoakes@...cle.com
Subject: Re: [RFC PATCH v2 1/1] exec: seal system mappings
On Wed, Oct 16, 2024 at 3:06 PM Jeff Xu <jeffxu@...omium.org> wrote:
>
> On Wed, Oct 16, 2024 at 2:26 PM Kees Cook <kees@...nel.org> wrote:
> >
> > (I don't think this needs "RFC" any more)
> >
> > On Mon, Oct 14, 2024 at 09:50:20PM +0000, 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 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@mail.gmail.com/
> > >
> > > Signed-off-by: Jeff Xu <jeffxu@...omium.org>
> > > ---
> > > .../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?
> >
> Yes. I like to leave room for future extension, in case someone ever
> needs a prctl for pre-process opt-in, e.g.
> Format:{never|prctl|always}
>
I copied the pattern from:
proc_mem.force_override= [KNL]
Format: {always | ptrace | never}
> > Otherwise, this all makes sense to me.
> >
> > --
> > Kees Cook
Powered by blists - more mailing lists