Disable and re-enable address space layout randomization only for myself
Asked Answered
P

2

24

I would like to disable address space layout randomization (ASLR) on my system (Ubuntu Gnu/Linux 2.6.32-41-server), but, if I use

sysctl -w kernel.randomize_va_space=0

the change would affect all users on the system, I presume. (Is this true?) How can I limit the effects of disabling ASLR to myself as a user only, or only to the shell session in which I invoke the command to disable?

BTW, I see that my system's current (default) setting is

kernel.randomize_va_space = 2

Why 2 and not 1 or 3? Where can I find documentation about the numerical values of /proc/sys settings, their ranges, and their meanings? Thanks!

Protasis answered 28/6, 2012 at 5:17 Comment(2)
gcc.gnu.org/wiki/Randomization says that setarch $(uname -m) -RL bash must workWoodford
unix.stackexchange.com/questions/15881/… || askubuntu.com/questions/318315/…Illlooking
M
16

The documentation for the randomize_va_space sysctl setting is in Documentation/sysctl/kernel.txt in the kernel source tree. Basically,

0 - Turn the process address space randomization off.

1 - Make the addresses of mmap base, stack and VDSO page randomized.

2 - Additionally enable heap randomization.

Morbid answered 28/6, 2012 at 5:23 Comment(2)
Thanks! That does address my second ("BTW") question above, but I still don't see a way to restrict the effect of sysctl to a single account or shell session. I guess it must be impossible. :-/Protasis
Yes, the setting is global. A quick grep shows that there is some (maybe vestigial) code in the "personality" code (handling multiple ABIs) that can do the converse. Setting ADDR_NO_RANDOMIZE flag on the personality field of a task_struct will disable the behavior even when it is globally enabled. But that's probably more kernel voodoo than you want to deal with.Morbid
M
37

The best way to disable locally the ASLR on a Linux-based system is to use processes personality flags. The command to manipulate personality flags is setarch with

-R, --addr-no-randomize

Disables randomization of the virtual address space (turns on ADDR_NO_RANDOMIZE).

Here is how to proceed:

$> setarch $(uname -m) -R /bin/bash

This command runs a shell in which the ASLR has been disabled. All descendants of this process will inherit of the personality flags of the father and thus have a disabled ASLR. The only way to break the inheritance of the flags would be to call a setuid program (it would be a security breach to support such feature).

Note that the uname -m is here to not hard-code the architecture of your platform and make this command portable.

You can check that it worked by hitting the following command several times:

#> cat /proc/self/maps

If the memory mapping stay the same, then ASLR has been disabled. If not, then you probably did something wrong.

Monarski answered 12/2, 2014 at 19:0 Comment(4)
How do I check if it worked? Any command to print out the settings?Concavoconvex
Good question, I added a way to check it worked (it is true that I always check it worked like this but I did not mentioned it).Monarski
"You can check that it worked by hitting the following command several times". Just to be clear I have to restart program -> cat /proc/self/maps multiple times right?Concavoconvex
In fact, you do not need to restart the program. The command cat /proc/self/maps is just displaying the memory mapping of the cat program itself (it is a self reference to it and cat is sending it to stdout). If the memory mapping is changing between two runs, then the ASLR is still enabled. If it stays static, then it is disabled.Monarski
M
16

The documentation for the randomize_va_space sysctl setting is in Documentation/sysctl/kernel.txt in the kernel source tree. Basically,

0 - Turn the process address space randomization off.

1 - Make the addresses of mmap base, stack and VDSO page randomized.

2 - Additionally enable heap randomization.

Morbid answered 28/6, 2012 at 5:23 Comment(2)
Thanks! That does address my second ("BTW") question above, but I still don't see a way to restrict the effect of sysctl to a single account or shell session. I guess it must be impossible. :-/Protasis
Yes, the setting is global. A quick grep shows that there is some (maybe vestigial) code in the "personality" code (handling multiple ABIs) that can do the converse. Setting ADDR_NO_RANDOMIZE flag on the personality field of a task_struct will disable the behavior even when it is globally enabled. But that's probably more kernel voodoo than you want to deal with.Morbid

© 2022 - 2024 — McMap. All rights reserved.