kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
* [PATCH] sysctl: add config to make randomize_va_space RO
@ 2023-05-04 21:30 Michael McCracken
  2023-05-05  7:35 ` David Hildenbrand
  2023-05-16 20:17 ` Kees Cook
  0 siblings, 2 replies; 10+ messages in thread
From: Michael McCracken @ 2023-05-04 21:30 UTC (permalink / raw)
  To: linux-kernel
  Cc: kernel-hardening, serge, tycho, Michael McCracken,
	Luis Chamberlain, Kees Cook, Iurii Zaikin, Andrew Morton,
	linux-fsdevel, linux-mm

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.

Signed-off-by: Michael McCracken <michael.mccracken@gmail.com>
---
 kernel/sysctl.c | 4 ++++
 mm/Kconfig      | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index bfe53e835524..c5aafb734abe 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1913,7 +1913,11 @@ static struct ctl_table kern_table[] = {
 		.procname	= "randomize_va_space",
 		.data		= &randomize_va_space,
 		.maxlen		= sizeof(int),
+#if defined(CONFIG_RO_RANDMAP_SYSCTL)
+		.mode		= 0444,
+#else
 		.mode		= 0644,
+#endif
 		.proc_handler	= proc_dointvec,
 	},
 #endif
diff --git a/mm/Kconfig b/mm/Kconfig
index 7672a22647b4..91a4a86d70e0 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1206,6 +1206,13 @@ config PER_VMA_LOCK
 	  This feature allows locking each virtual memory area separately when
 	  handling page faults instead of taking mmap_lock.
 
+config RO_RANDMAP_SYSCTL
+    bool "Make randomize_va_space sysctl 0444"
+    depends on MMU
+    default n
+    help
+      Set file mode of /proc/sys/kernel/randomize_va_space to 0444 to disallow runtime changes in ASLR.
+
 source "mm/damon/Kconfig"
 
 endmenu
-- 
2.37.1 (Apple Git-137.1)


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-04 21:30 [PATCH] sysctl: add config to make randomize_va_space RO Michael McCracken
@ 2023-05-05  7:35 ` David Hildenbrand
  2023-05-05  7:46   ` Sam James
  2023-05-15 21:43   ` Serge Hallyn
  2023-05-16 20:17 ` Kees Cook
  1 sibling, 2 replies; 10+ messages in thread
From: David Hildenbrand @ 2023-05-05  7:35 UTC (permalink / raw)
  To: Michael McCracken, linux-kernel
  Cc: kernel-hardening, serge, tycho, Luis Chamberlain, Kees Cook,
	Iurii Zaikin, Andrew Morton, linux-fsdevel, linux-mm

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.

Can you elaborate why we care about "accidental changing of this value 
by a root service"?

We cannot really stop root from doing a lot of stupid things (e.g., 
erase the root fs), so why do we particularly care here?

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-05  7:35 ` David Hildenbrand
@ 2023-05-05  7:46   ` Sam James
  2023-05-05 15:15     ` David Hildenbrand
  2023-05-15 21:43   ` Serge Hallyn
  1 sibling, 1 reply; 10+ messages in thread
From: Sam James @ 2023-05-05  7:46 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael McCracken, linux-kernel, serge, tycho, Luis Chamberlain,
	Kees Cook, Iurii Zaikin, Andrew Morton, linux-fsdevel, linux-mm,
	kernel-hardening

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]


David Hildenbrand <david@redhat.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.
>
> Can you elaborate why we care about "accidental changing of this value
> by a root service"?
>
> We cannot really stop root from doing a lot of stupid things (e.g.,
> erase the root fs), so why do we particularly care here?

(I'm really not defending the utility of this, fwiw).

In the past, I've seen fuzzing tools and other debuggers try to set
it, and it might be that an admin doesn't realise that. But they could
easily set other dangerous settings unsuitable for production, so...


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-05  7:46   ` Sam James
@ 2023-05-05 15:15     ` David Hildenbrand
  2023-05-05 15:16       ` David Hildenbrand
  2023-05-05 15:23       ` Paul Moore
  0 siblings, 2 replies; 10+ messages in thread
From: David Hildenbrand @ 2023-05-05 15:15 UTC (permalink / raw)
  To: Sam James
  Cc: Michael McCracken, linux-kernel, serge, tycho, Luis Chamberlain,
	Kees Cook, Iurii Zaikin, Andrew Morton, linux-fsdevel, linux-mm,
	kernel-hardening

On 05.05.23 09:46, Sam James wrote:
> 
> David Hildenbrand <david@redhat.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.
>>
>> Can you elaborate why we care about "accidental changing of this value
>> by a root service"?
>>
>> We cannot really stop root from doing a lot of stupid things (e.g.,
>> erase the root fs), so why do we particularly care here?
> 
> (I'm really not defending the utility of this, fwiw).
> 
> In the past, I've seen fuzzing tools and other debuggers try to set
> it, and it might be that an admin doesn't realise that. But they could
> easily set other dangerous settings unsuitable for production, so...

At least fuzzing tools randomly toggling it could actually find real 
problems. Debugging tools ... makes sense that they might be using it.

What I understand is, that it's more of a problem that the system 
continues running and the disabled randomization isn't revealed to an 
admin easily.

If we really care, not sure what's better: maybe we want to disallow 
disabling it only in a security lockdown kernel? Or at least warn the 
user when disabling it? (WARN_TAINT?)

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-05 15:15     ` David Hildenbrand
@ 2023-05-05 15:16       ` David Hildenbrand
  2023-05-05 15:23       ` Paul Moore
  1 sibling, 0 replies; 10+ messages in thread
From: David Hildenbrand @ 2023-05-05 15:16 UTC (permalink / raw)
  To: Sam James
  Cc: Michael McCracken, linux-kernel, serge, tycho, Luis Chamberlain,
	Kees Cook, Iurii Zaikin, Andrew Morton, linux-fsdevel, linux-mm,
	kernel-hardening

On 05.05.23 17:15, David Hildenbrand wrote:
> On 05.05.23 09:46, Sam James wrote:
>>
>> David Hildenbrand <david@redhat.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.
>>>
>>> Can you elaborate why we care about "accidental changing of this value
>>> by a root service"?
>>>
>>> We cannot really stop root from doing a lot of stupid things (e.g.,
>>> erase the root fs), so why do we particularly care here?
>>
>> (I'm really not defending the utility of this, fwiw).
>>
>> In the past, I've seen fuzzing tools and other debuggers try to set
>> it, and it might be that an admin doesn't realise that. But they could
>> easily set other dangerous settings unsuitable for production, so...
> 
> At least fuzzing tools randomly toggling it could actually find real
> problems. Debugging tools ... makes sense that they might be using it.
> 
> What I understand is, that it's more of a problem that the system
> continues running and the disabled randomization isn't revealed to an
> admin easily.
> 
> If we really care, not sure what's better: maybe we want to disallow
> disabling it only in a security lockdown kernel? Or at least warn the
> user when disabling it? (WARN_TAINT?)

Sorry, not WARN_TAINT. pr_warn() maybe. Tainting the kernel is probably 
a bit too much as well.

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-05 15:15     ` David Hildenbrand
  2023-05-05 15:16       ` David Hildenbrand
@ 2023-05-05 15:23       ` Paul Moore
  2023-05-06  7:04         ` Kaiwan N Billimoria
  1 sibling, 1 reply; 10+ messages in thread
From: Paul Moore @ 2023-05-05 15:23 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Sam James, Michael McCracken, linux-kernel, serge, tycho,
	Luis Chamberlain, Kees Cook, Iurii Zaikin, Andrew Morton,
	linux-fsdevel, linux-mm, kernel-hardening

On Fri, May 5, 2023 at 11:15 AM David Hildenbrand <david@redhat.com> wrote:
> On 05.05.23 09:46, Sam James wrote:
> > David Hildenbrand <david@redhat.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.

(On my Rawhide system with SELinux enabled)
% ls -Z /proc/sys/kernel/randomize_va_space
system_u:object_r:proc_security_t:s0 /proc/sys/kernel/randomize_va_space

-- 
paul-moore.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-05 15:23       ` Paul Moore
@ 2023-05-06  7:04         ` Kaiwan N Billimoria
  2023-05-07 19:53           ` Paul Moore
  0 siblings, 1 reply; 10+ messages in thread
From: Kaiwan N Billimoria @ 2023-05-06  7:04 UTC (permalink / raw)
  To: Paul Moore
  Cc: David Hildenbrand, Sam James, Michael McCracken, linux-kernel,
	serge, tycho, Luis Chamberlain, Kees Cook, Iurii Zaikin,
	Andrew Morton, linux-fsdevel, linux-mm, kernel-hardening

On Fri, May 5, 2023 at 8:53 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, May 5, 2023 at 11:15 AM David Hildenbrand <david@redhat.com> wrote:
> > On 05.05.23 09:46, Sam James wrote:
> > > David Hildenbrand <david@redhat.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 are legitimate scenarios
(typically debugging) where root needs to disable/enable ASLR.
I think the key thing is the file ownership; being root-writable takes
care of security concerns... (as David says, if root screws around we
can't do much)..
If one argues for changing the mode from 0644 to 0444, what prevents
all the other dozens of sysctls - owned by root mind you - from not
wanting the same treatment?
Where does one draw the line?
- Kaiwan.
>
> (On my Rawhide system with SELinux enabled)
> % ls -Z /proc/sys/kernel/randomize_va_space
> system_u:object_r:proc_security_t:s0 /proc/sys/kernel/randomize_va_space
>
> --
> paul-moore.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-06  7:04         ` Kaiwan N Billimoria
@ 2023-05-07 19:53           ` Paul Moore
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2023-05-07 19:53 UTC (permalink / raw)
  To: Kaiwan N Billimoria
  Cc: David Hildenbrand, Sam James, Michael McCracken, linux-kernel,
	serge, tycho, Luis Chamberlain, Kees Cook, Iurii Zaikin,
	Andrew Morton, linux-fsdevel, linux-mm, kernel-hardening

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-05  7:35 ` David Hildenbrand
  2023-05-05  7:46   ` Sam James
@ 2023-05-15 21:43   ` Serge Hallyn
  1 sibling, 0 replies; 10+ messages in thread
From: Serge Hallyn @ 2023-05-15 21:43 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael McCracken, linux-kernel, kernel-hardening, tycho,
	Luis Chamberlain, Kees Cook, Iurii Zaikin, Andrew Morton,
	linux-fsdevel, linux-mm

On Fri, May 05, 2023 at 09:35:59AM +0200, David Hildenbrand wrote:
> 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.
> 
> Can you elaborate why we care about "accidental changing of this value by a
> root service"?

Accidental... malicious...  Note that when people run programs as root with
reduced or no capabilities they can still write this file.

> We cannot really stop root from doing a lot of stupid things (e.g., erase
> the root fs), so why do we particularly care here?

Regardless of the "real value" of it, I know for a fact there are lots
of teams out there adding kernel patches to just change the mode of that
file.  Why?  Possibly to satisfy a scanner, because another team says
it's important.

The problem with lockdown is it's all or nothing.  The problem with LSM
for this purpose is that everyone will have to configure their policy
differently.

So I do think it was worth testing the waters with this patch, to reduce
the number of duplicate patches people run with.

-serge

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] sysctl: add config to make randomize_va_space RO
  2023-05-04 21:30 [PATCH] sysctl: add config to make randomize_va_space RO Michael McCracken
  2023-05-05  7:35 ` David Hildenbrand
@ 2023-05-16 20:17 ` Kees Cook
  1 sibling, 0 replies; 10+ messages in thread
From: Kees Cook @ 2023-05-16 20:17 UTC (permalink / raw)
  To: Michael McCracken
  Cc: linux-kernel, kernel-hardening, serge, tycho, Luis Chamberlain,
	Iurii Zaikin, Andrew Morton, linux-fsdevel, linux-mm

On Thu, May 04, 2023 at 02:30:02PM -0700, 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.
> 
> Signed-off-by: Michael McCracken <michael.mccracken@gmail.com>
> ---
>  kernel/sysctl.c | 4 ++++
>  mm/Kconfig      | 7 +++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index bfe53e835524..c5aafb734abe 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1913,7 +1913,11 @@ static struct ctl_table kern_table[] = {
>  		.procname	= "randomize_va_space",
>  		.data		= &randomize_va_space,
>  		.maxlen		= sizeof(int),
> +#if defined(CONFIG_RO_RANDMAP_SYSCTL)
> +		.mode		= 0444,
> +#else
>  		.mode		= 0644,
> +#endif

The way we've dealt with this in the past for similarly sensitive
sysctl variables to was set a "locked" position. (e.g. 0==off, 1==on,
2==cannot be turned off). In this case, we could make it, 0, 1, 2,
3==forced on full.

I note that there is actually no min/max (extra1/extra2) for this sysctl,
which is itself a bug, IMO. And there is just a magic "> 1" test that
should be a define or enum:

fs/binfmt_elf.c:        if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {

I think much of this should be improved.

Regardless, take a look at yama_dointvec_minmax(), which could, perhaps,
be generalized and used here.

Then we have a run-time way to manage this bit, without needing full
kernel rebuilds, etc, etc.

-Kees

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-05-16 20:17 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-04 21:30 [PATCH] sysctl: add config to make randomize_va_space RO Michael McCracken
2023-05-05  7:35 ` David Hildenbrand
2023-05-05  7:46   ` Sam James
2023-05-05 15:15     ` David Hildenbrand
2023-05-05 15:16       ` David Hildenbrand
2023-05-05 15:23       ` Paul Moore
2023-05-06  7:04         ` Kaiwan N Billimoria
2023-05-07 19:53           ` Paul Moore
2023-05-15 21:43   ` Serge Hallyn
2023-05-16 20:17 ` Kees Cook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).