Enable compilation of YAMA LSM

[uski]

Describe the bug

Hi,

I have installed a fresh Raspbian Lite on a Raspberry Pi Zero W.
I notice that the default kernel config does not have the YAMA security module enabled :

modprobe configs
zcat /proc/config.gz > /tmp/.config
cat /tmp/.config | grep YAMA
# CONFIG_SECURITY_YAMA is not set

This is a security issue. While there is no security issue in itself with this config, YAMA has extremely useful features to disable ptrace, which is a dangerous feature. It is dangerous to leave ptrace enabled by default.

Ubuntu and Debian both disable ptrace by default using the YAMA security module : https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection

They have been doing this for a long time now.

Even the NSA recommends disabling ptrace : https://media.defense.gov/2019/Jul/16/2002158062/-1/-1/0/CSI-LIMITING-PTRACE-ON-PRODUCTION-LINUX-SYSTEMS.PDF

Raspberry Pi is growing in popularity. There have been recent changes to not have SSH enabled by default, and also have users change their default password.

I believe the Kernel should also be configured to have ptrace disabled by default just like other distributions.
Or at the very least, the YAMA security module should be compiled in (CONFIG_SECURITY_YAMA=y) to let users disable ptrace without having to recompile their own kernel.

Thank you

Steps to reproduce the behaviour

Install the default Raspberry Pi kernel

Device (s)

Raspberry Pi Zero, Raspberry Pi Zero W / WH, Raspberry Pi Zero 2 W, Raspberry Pi 1 Mod. A, Raspberry Pi 1 Mod. A+, Raspberry Pi 1 Mod. B, Raspberry Pi 1 Mod. B+, Raspberry Pi 2 Mod. B, Raspberry Pi 2 Mod. B v1.2, Raspberry Pi 3 Mod. A+, Raspberry Pi 3 Mod. B, Raspberry Pi 3 Mod. B+, Raspberry Pi 4 Mod. B, Raspberry Pi 400, Raspberry Pi CM1, Raspberry Pi CM3, Raspberry Pi CM3 Lite, Raspberry Pi CM3+, Raspberry Pi CM3+ Lite, Raspberry Pi CM4, Raspberry Pi CM4 Lite

System

$ cat /etc/rpi-issue
Raspberry Pi reference 2021-05-07
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, dcfd74d7d1fa293065ac6d565711e9ff891fe2b8, stage2

$ vcgencmd version
Dec 1 2021 15:07:06
Copyright (c) 2012 Broadcom
version 71bd3109023a0c8575585ba87cbb374d2eeb038f (clean) (release) (start)

$ uname -a
Linux raspberrypi 5.10.103+ #1529 Tue Mar 8 12:19:18 GMT 2022 armv6l GNU/Linux

Logs

No response

Additional context

No response

[pelwell]

It's curious that even in the 5.18 kernel there are no (zero) defconfigs that enable SECURITY_YAMA. It has to built-in, which counts against it, but the code increase is minimal, so why isn't it more popular?

[uski]

I see that Ubuntu and Debian account for roughly 50% of the Linux "marketshare" - which would mean that having a default ptrace_scope > 0 is pretty popular in terms of userbase.

I would guess that, like may security features, they get overlooked because people focus on what work and what is "essential".
I checked on my daily driver and sure enough, ptrace_scope > 1 and I never noticed any problem (I regularly use it for development).

That tells me it should be pretty safe to have ptrace_scope set to at least 1.

We have a chance to make it even more popular... and also protect the Raspberry Pi users a little bit more, too !

I am not 100% certain that merely enabling CONFIG_SECURITY_YAMA is going to set ptrace_scope to > 0. I believe it will just enable ptrace_scope. To set it > 0 by default, an extra patch might be required like Debian is doing :
https://sources.debian.org/patches/linux/5.17.6-1/debian/yama-disable-by-default.patch/

[uski]

To be clear, my request here is to set CONFIG_SECURITY_YAMA=y at least, so users can enable it. That's my primary request. I want to at least be able to protect myself.

Then, we should also consider setting ptrace_scope to 1 by default, like Debian and Ubuntu are doing

These are two separate things. I think we should do both, but please let's do at least the first one.

Thanks

[uski]

Reading the patch again... Ubuntu and Debian do different things (I was confused, let me fix that).

• Ubuntu enabled ptrace_scope to 1 by default, setting CONFIG_SECURITY_YAMA=y is enough to do it. Their rationale for doing it is in https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection and I wholeheartly agree with their approach. It is a free protection, and it is only problematic for relatively advanced use cases. Since they account for ~35% of the Linux "marketshare΅, I would say this is common enough to not be an issue.
• Debian sets CONFIG_SECURITY_YAMA=y to give their users the option to enable this protection, but patch the module so that it is disabled by default. I see a discussion about it in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740 but frankly their argument seems bogus to me ("there are other protections, so let's not enable this one", what about defense in depth ?) and this decision does not seem very well discussed

Maybe I should move this discussion to Raspbian, and have them do like Debian is doing.

That said, I think that from the Kernel side, we should encourage people to have a secure configuration by default, and only disable that security if they have a valid reason to do so. Which would be the Ubuntu-style approach, not the Debian-style approach, and that is actionable from the Raspi kernel side by providing a suitable defconfig.

Thoughts ?

[popcornmix]

I agree with debian. If enabled in kernel, I'd want this to be opt-in not opt-out.
Losing the ability to attach with gdb or ptrace (with no clear message why) would be annoying to many.

[pelwell]

I agree - our kernel builds are aimed at hobbyists (amongst others), and tinkering is to be encouraged. Fortunately, other distributions are available.

I'm going to leave this issue open in case anyone else wants to chime in, but given that yours is the first mention of YAMA in 10 years (the other hit is in a commit mention shown in an issue about LSM in general), the demand isn't high.

[uski]

That ability is not "lost" (it would only be with ptrace_scope set to 3). ptrace_scope can be reverted from 1 to 0 simply by writing 0 to it.

Since Ubuntu has been doing this for 10+ years, there is extensive documentation on Internet.
A search for "strace attach operation not permitted", for example, gives immediate mention of ptrace_scope and what people need to do.

Most users do not attach to running processes either, and ptrace_scope of 1 does not prevent running an application from gdb.

As many things security related, demand might not be the best indicator - especially from hobbyists who often have no idea what ptrace is. Ubuntu is also aimed at the same target population (it's an easy distribution - that I am using, too !), and the fact that they have been able to enable this protection without pushback shows that it really isn't an issue.

[hailfinger]

Most users do not attach to running processes either, and ptrace_scope of 1 does not prevent running an application from gdb.

Running buggy applications under gdb or strace from the beginning is going to change timings and may cause the very issue you're trying to debug to disappear. I usually attach to processes after they exhibit a bug, not before. I'm happy that this is possible on Raspberry Pi OS without jumping through hoops.

AFAICS ptrace_scope offers very limited protection based on the following assumptions: An attacker can already execute code on your machine and that's OK as long as the attacker can't modify already-running processes of the same user.

I agree with pelwell that tinkering is to be encouraged.

[uski]

I usually attach to processes after they exhibit a bug, not before.

I am quite surprised by these replies frankly. As I mentioned, the default on Ubuntu is ptrace_scope = 1. Users are not complaining everywhere that it is too hard to debug on these platforms. Making the platform unsecure by default for the benefit of not having to change a sysctl for the minority of users who use GDB seems like a bias (yes, us, right here, talking on github, are those the most likely to use GDB, and it is important to not project the way we use the platform on everyone else).

But okay. Let's assume changing a sysctl is too damn hard. Can we at least have the option compiled-in for those who want to enable this feature ? Like in Debian.

If there is one thing we can agree on, it is probably that having to recompile the kernel and maintain a custom kernel is a few order or magnitudes more effort than disabling a sysctl - which you will not have to do if we leave ptrace_scope at zero by default.

The Raspberry Pi platform is not just for tinkers and people like you who use GDB every hour of the day. The Compute Modules are used by companies, too. There are also users using Raspberry Pis for usages like ADS-B receivers where they seldom tinker with the Raspberry Pi and can benefit from a more secure configuration.

[pelwell]

I'm going to decline and close this request for the reasons listed above, rather than leave it hanging indefinitely.