Hi Chris, On Sun, 2025-11-16 at 11:35 +0000, Christopher Klooz wrote: > I was asked to put this proposal once to discussion in the community before > officially submitting it: > https://fedoraproject.org/wiki/Changes/Enable_%22kernel.yama.ptrace_scope%22_by_default_to_adopt_upstream_kernel_default_(or_a_more_restrictive_setting_if_unforeseen_impact_is_unrealistic)_to_mitigate_attacks/impacts_due_to_malicious,_vulnerable_or_unmaintained/unupdated_packages/processes
Like the previous proposal I do think it is a little too chatty. Even the URL is multiple lines long. These walls of text makes it really hard to discuss, because it keeps repeating and mixing facts and your opinion. I tried to make it a bit clearer by adding a better and less opinionated description of the Yama LSM and default-yama-scope (virtual) package dependency. But it looks like you just reverted that. So let me just repost that here to make more clear what exactly you are proposing to remove: The linux kernel has an optional Linux Security Module, Yama. Yama allows a system builder to disable various user space interfaces that are deamed inappropriate for non-developers and non-admins to create a user-only appliance. When a kernel is build with CONFIG_SECURITY_YAMA turning on these user space restrictions are controlled by the sysctl kernel.yama.ptrace_scope. To make sure that such admin and developer tools keep working even when the Yama LSM is compiled into the kernel the virtual default-yama-scope package dependency was introduced. Packages that need the traditional kernel observability interfaces depend on it, to make sure that when they are installed the kernel.yama.ptrace_scope config is setup to enable the default attach security permission. The package elfutils-default-yama-scope package purpose is to provide this default-yama-scope. Packages indicate they need full observability user space syscalls and /proc access by depending on default-yama- scope. And elfutils-default-yama-scope makes sure that when such program or library is installed the kernel.yama.ptrace_scope sysctl is set to 0 by default. > I think the two types of reasoning/opinions on this case can be summed up > that way (see also the feedback section of the proposal draft for a 1:1 > summary of the opinion A): > A) Tools/Applications should work by default for all, to motivate users to > dive deeper into Fedora, and thus become more likely effective contributors: > kernel.yama.ptrace_scope=1/2 is not a useful/balanced means because of its > inappropriate security/constraints balance (enabling is always global impact) > that breaks applications that are widely used by at least one of the > audiences of Fedora (I hope I rationally summed this up -> mjw might > elaborate this position) > B) Security by default, to protect average users who are not always familiar > with all parts of their operating system and the impact of what they > customize/modify while they will not have issues with this change, and if > this affects users who are more familiar with Linux etc., it might be useful > to allow them to experience that there is an issue without a perfect > solution, and allow them to make their own decision about which compromise is > best for them. It's our job to ensure the information is available in a way > they can find it rather than making decisions for them. I don't think it is that black-or-white. It is just that if you want to satisfy multiple such goals then using Yama is a somewhat broken approach, since it impacts user space globally. Using other security approaches or other LSMs would provide mechanisms that don't have such binary choices. But Yama only provides one global on/of like switch. In the feedback section you have smashed all feedback into one big paragraph, as if the separate suggestions are just one and the same thing. But they aren't. Some are indeed just facts that make things not work with your suggested approach. But there are also suggestions to look at this in a different way. In particular I would suggest you at least look into the following points that were brought up: * Why not look for a solution where user space keeps working by default, but some system calls/proc file system usage might be disabled if the system doesn't install certain admin and developer tools (e.g. some yama-scope package depenencies are fixed or moved from Required to Suggested)? * Maybe adjust yama to have a more flexible policy and/or look into an selinux based policy? * Please look for other security mitigations you believe are necessary. The yama documentation already points out how this can (and has) been done. Programs can be run in different user contexts (run them as a diffent user or inside a flatpak/bubblewrap for example). Programs can set PR_SET_DUMPABLE 0 like ssh has done. > Further, it has to be clear that I don't consider myself a software engineer But you probably are! :) Seriously, even people who call themselves "full stack engineers" most likely don't really have knowledge of all levels of the software stack they claim to be using. But I do think we should encourage everybody to think of themselves as software engineers and to make it easy to explore all levels of the "full stack". That is also why I think your proposal is not great. You are essentially proposing to make exploring, observing, debugging, profiling, tracing your own processes, at a level you are not directly interested in, and to become a developer harder and more dangerous. So I hope you find some better way to add perceived security mitigations. Cheers, Mark -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
