On Sat, May 6, 2023 at 3:05 AM Kaiwan N Billimoria <kaiwan@xxxxxxxxxxxxxx> wrote: > On Fri, May 5, 2023 at 8:53 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Fri, May 5, 2023 at 11:15 AM David Hildenbrand <david@xxxxxxxxxx> wrote: > > > On 05.05.23 09:46, Sam James wrote: > > > > David Hildenbrand <david@xxxxxxxxxx> 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
