-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Enable compilation of YAMA LSM #5030
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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? |
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". 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 : |
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 |
Reading the patch again... Ubuntu and Debian do different things (I was confused, let me fix that).
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 ? |
I agree with debian. If enabled in kernel, I'd want this to be opt-in not opt-out. |
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. |
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. 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. |
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. |
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. |
I'm going to decline and close this request for the reasons listed above, rather than leave it hanging indefinitely. |
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 :
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
The text was updated successfully, but these errors were encountered: