Tails

#2 Updated by cypherpunks 2016-09-28 02:06:11

intrigeri wrote:
> Do you have any examples of other operating systems changing the default values? E.g. what do Chrome OS or Android do?

Android is the reason it came into existance. They specifically requested this feature because of just how broken ASLR is on 32 bit userlands, causing a very nasty vulnerability in android to be exploitable (see https://lwn.net/Articles/667790/).

Both Android and Chromium OS have them set to the maximum values:

https://android-review.googlesource.com/#/c/209519/
https://chromium-review.googlesource.com/#/c/322712/

> Why isn’t it going to be an issue for Tails users? (Thanks in advance for educating me :)

Because memory fragmentation can cause a small performance hit, especially on embedded systems. Embedded systems might have so little memory that fragmentation becomes a game stopper. Tails requires around 1 GiB of memory to run, which is plenty. From https://pax.grsecurity.net/docs/aslr.txt:

> The last set of side effects of ASLR is address space fragmentation and
> entropy pool exhaustion. Since randomization shifts entire ranges of memory,
> it will also randomly change the gaps between them (which were constant
> before). This in turn will change the maximum size of memory mappings that
> will fit in there and applications expecting to be able to create them will
> fail.

Note that the entropy pool exhaustion risk is no longer an issue, as ASLR uses get_random_int() and get_random_long() instead of the entropy (count) depleting get_random_bytes() function. tl;dr in extreme cases, mmap() and friends will fail.

#4 Updated by intrigeri 2016-09-30 01:53:36

https://outflux.net/blog/archives/2016/09/28/security-things-in-linux-v4-5/ has a one-liner to “crank your entropy to the max, without regard to what architecture you’re on”.

#5 Updated by cypherpunks 2016-11-09 04:45:36

intrigeri wrote:
> https://outflux.net/blog/archives/2016/09/28/security-things-in-linux-v4-5/ has a one-liner to “crank your entropy to the max, without regard to what architecture you’re on”.

That’s very sloppy. It just increments the sysctls by one until it returns EINVAL. Is Tails ever going to be run on an architecture other than x86? If it is, there is a lot more that is going to be needed to be changed than this sysctl. It would be much more sane to put the regular x86 values in sysctl.d than it would to implement it as a startup script. And it would be very easy to set the sysctls based on the processor architecture anyway.

Also, what if the behavior of the sysctl changes? Some sysctls can be incremented infinitely, but will behave as if they were set to their maximum value. If these sysctls are changed to use that behavior, that script will not only cause the boot to lock up, but may even cause the value to overflow and wrap, potentially resulting in a lower ASLR strength if systemd decides it’s taking too long and stops it while it’s overflowed at a value lower than the default.

“Crank your entropy” is really jut sloppy, IMO. Just set it to the max value manually and let it be.

#7 Updated by intrigeri 2016-11-09 17:11:11

Hi!

>> https://outflux.net/blog/archives/2016/09/28/security-things-in-linux-v4-5/ has a one-liner to “crank your entropy to the max, without regard to what architecture you’re on”.

> That’s very sloppy. It just increments the sysctls by one until it returns EINVAL.

> Is Tails ever going to be run on an architecture other than x86?

Possibly ARM, but not in the close future.

> If it is, there is a lot more that is going to be needed to be changed than this sysctl.

Correct. However, we will think about the other things that will need to be changed, while it’ll be easy to forget changing the hard-coded values you’re suggesting.

> It would be much more sane to put the regular x86 values in sysctl.d than it would to implement it as a startup script.

My concern with the hard-coded approach is that if the maximum allowed values ever change, we won’t benefit from the new bigger possible values, until someone thinks about it (unlikely to happen). This is why I rather like the approach suggested by Kees, which is not affected by that problem.

> Also, what if the behavior of the sysctl changes? Some sysctls can be incremented infinitely, but will behave as if they were set to their maximum value. If these sysctls are changed to use that behavior, that script will not only cause the boot to lock up,

Such a problem would be spotted pretty fast, easily, and way ahead of release, thanks to our automated testing infrastructure :)

> but may even cause the value to overflow and wrap, potentially resulting in a lower ASLR strength if systemd decides it’s taking too long and stops it while it’s overflowed at a value lower than the default.

Are there any existing sysctls that overflow this way? (That’s a real question, again: I’m not an expert in this area and need input from people like you.)

In passing, to protect against such an overflow, I could adjust Kees’ script to recall what’s the biggest value that’s ever been accepted by the sysctl, and reset it back to that value if writing to the sysctl ever decreases its resulting value. Of course, that’s racy when another actor (systemd) comes into play; but I’m very confident that in practice, the “incrementally increase until overflow + reset” will simply never take enough time for systemd to be willing to kill the script.

OT: you might be interested in Feature #11886. I really appreciate your contributions.

#9 Updated by cypherpunks 2016-11-11 05:50:10

intrigeri wrote:
> My concern with the hard-coded approach is that if the maximum allowed values ever change, we won’t benefit from the new bigger possible values, until someone thinks about it (unlikely to happen). This is why I rather like the approach suggested by Kees, which is not affected by that problem.

I don’t believe the maximum values even can change due to the fundamental limitations of the x86 architecture. Such a change would require very massive modifications to how ASLR works inside the kernel. With grsecurity (which does involve massive changes to ASLR of that type), vm.mmap_rnd_bits has a maximum value of 27, rather than 32, even on x86_64. I imagine this is because grsecurity provides additional ASLR features which conflict with some of the vanilla ASLR space and limits the size. Just something to keep in mind when/if Tails includes grsecurity.

> Are there any existing sysctls that overflow this way? (That’s a real question, again: I’m not an expert in this area and need input from people like you.)

Some do:

# n=1; while true; do sysctl -w kernel.perf_event_paranoid=$((n++)); done
kernel.perf_event_paranoid = 1
kernel.perf_event_paranoid = 2
kernel.perf_event_paranoid = 3
...
kernel.perf_event_paranoid = 490812
kernel.perf_event_paranoid = 490813
kernel.perf_event_paranoid = 490814
^C
# sysctl -a -r paranoid
kernel.perf_event_paranoid = 490814

Some don’t:

# n=1; while true; do sysctl -w kernel.kptr_restrict=$((n++)); done
kernel.kptr_restrict = 1
kernel.kptr_restrict = 2
sysctl: setting key "kernel.kptr_restrict": Invalid argument
kernel.kptr_restrict = 3
...
sysctl: setting key "kernel.kptr_restrict": Invalid argument
kernel.kptr_restrict = 155141
sysctl: setting key "kernel.kptr_restrict": Invalid argument
kernel.kptr_restrict = 155142
sysctl: setting key "kernel.kptr_restrict": Invalid argument
kernel.kptr_restrict = 155143
^C
# sysctl -a -r kptr
kernel.kptr_restrict = 2

It seems however I was wrong about it overflowing and wrapping to 0. The former returns EINVAL when it exceeds INT32_MAX (2^31-1, or 2147483647). It will, however increment for long, long time. Oddly enough, on my Gentoo system, kernel.perf_event_paranoid acts more like kernel.kptr_restrict, refusing above the maximum sane value (3 on this system). The sysctl interface does not seem very consistent among different systems and kernel versions. The entirety of the sysfs (and procfs) virtual filesystems are in general a mess.

These were tested on Tails 2.6 under QEMU with KVM.

> In passing, to protect against such an overflow, I could adjust Kees’ script to recall what’s the biggest value that’s ever been accepted by the sysctl, and reset it back to that value if writing to the sysctl ever decreases its resulting value. Of course, that’s racy when another actor (systemd) comes into play; but I’m very confident that in practice, the “incrementally increase until overflow + reset” will simply never take enough time for systemd to be willing to kill the script.

Why not also use such a script for kernel.perf_event_paranoid, and kernel.kptr_restrict, in case those ever have increased maximum values in the future? A previous ticket was closed because kernel.perf_event_paranoid’s default value would be set to 3 in a future Debian version, so there would be no reason to increment it automatically, as we already know that the default will be 3 for the foreseeable future.

IMO, the script still seems useless to me. It seems to be intended entirely for architecture-agnostic systems, not systems which we know will always have a maximum of 32 bits for 64 bit userspace, and 16 for 16 bit userspace, on all deployed systems.

> OT: you might be interested in Feature #11886. I really appreciate your contributions.

Thanks. The newer 4.8 kernels have a lot of great security features, thanks to the KSPP, like SLUB sanitizing (like poisoning, but initializing with zeros for security), and page freeing, like PAX_SANITIZE. I forget how it’s enabled, but I’m pretty sure it’s just an additional flag to slub_debug=P to turn the poisoning into zeroizing. Anyway I’ll look into it. It would really be better to focus on trying to get grsecurity into Tails (whether by getting AppArmor compatible with overlayfs, or getting Corsac to be willing to put the PAX compatibility patch into his linux-grsec Debian package).

#12 Updated by cypherpunks 2017-01-06 04:04:48

If Feature #7649 goes through and PAX_UDEREF is enabled, vm.mmap_rnd_bits will have a maximum value of 27, not 32. No change to vm.mmap_rnd_compat_bits will be needed, and its maximum value can still be increased to 16.

#13 Updated by intrigeri 2017-01-06 08:53:51

> If Feature #7649 goes through and PAX_UDEREF is enabled, vm.mmap_rnd_bits will have a maximum value of 27, not 32. No change to vm.mmap_rnd_compat_bits will be needed, and its maximum value can still be increased to 16.

FYI Feature #7649 is long term, while I’d like to address this ticket soonish.

#14 Updated by cypherpunks 2017-01-07 08:54:00

intrigeri wrote:
> > If Feature #7649 goes through and PAX_UDEREF is enabled, vm.mmap_rnd_bits will have a maximum value of 27, not 32. No change to vm.mmap_rnd_compat_bits will be needed, and its maximum value can still be increased to 16.
>
> FYI Feature #7649 is long term, while I’d like to address this ticket soonish.
Sure, I’m just mentioning it here so it won’t come as a surprise if the tests fail in the future.