[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhSfrAUJaP-MbTXFyLgAz5P3McjD0eouj+-7QwOrrYt8MQ@mail.gmail.com>
Date: Sun, 7 May 2023 15:53:05 -0400
From: Paul Moore <paul@...l-moore.com>
To: Kaiwan N Billimoria <kaiwan@...wantech.com>
Cc: David Hildenbrand <david@...hat.com>, Sam James <sam@...too.org>,
Michael McCracken <michael.mccracken@...il.com>,
linux-kernel@...r.kernel.org, serge@...lyn.com, tycho@...ho.pizza,
Luis Chamberlain <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Iurii Zaikin <yzaikin@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] sysctl: add config to make randomize_va_space RO
On Sat, May 6, 2023 at 3:05 AM Kaiwan N Billimoria
<kaiwan@...wantech.com> wrote:
> On Fri, May 5, 2023 at 8:53 PM Paul Moore <paul@...l-moore.com> wrote:
> >
> > On Fri, May 5, 2023 at 11:15 AM David Hildenbrand <david@...hat.com> wrote:
> > > On 05.05.23 09:46, Sam James wrote:
> > > > David Hildenbrand <david@...hat.com> writes:
> > > >> On 04.05.23 23:30, Michael McCracken wrote:
> > > >>> Add config RO_RANDMAP_SYSCTL to set the mode of the randomize_va_space
> > > >>> sysctl to 0444 to disallow all runtime changes. This will prevent
> > > >>> accidental changing of this value by a root service.
> > > >>> The config is disabled by default to avoid surprises.
> >
> > ...
> >
> > > If we really care, not sure what's better: maybe we want to disallow
> > > disabling it only in a security lockdown kernel?
> >
> > If we're bringing up the idea of Lockdown, controlling access to
> > randomize_va_space is possible with the use of LSMs. One could easily
> > remove write access to randomize_va_space, even for tasks running as
> > root.
>
> IMO, don't _move_ the sysctl to LSM(s).
There is nothing to move, the ability to restrict access to
randomize_va_space exists today, it is simply a matter of if the
security policy author or admin wants to enable it.
If you are like Michael and you want to block write access, even when
running as root, you can do so with an LSM. You can also allow write
access. With SELinux you can allow/disallow the privilege on a
task-by-task basis to meet individual usability and security
requirements.
--
paul-moore.com
Powered by blists - more mailing lists