On 17/11/2025 17.02, Mark Wielaard wrote:
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.
As mentioned in my second email (about 3 hours after the first one) that considers the feedback
of Discourse, the URL will be adjusted to the updated title before submitting ->
"Change kernel.yama.ptrace_scope to match kernel defaults (mitigates some attack
vectors)" -> so at least this issue is solved before submission :)
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:
Actually, my perception is that an opinion was added, as things that are facts were
changed to be claims. It can be discussed and questioned if the mitigation of
ptrace_scope makes a big difference and when, or if and how realistic it is that such an
attack takes place compared to its disadvantages, but it is not a "claim". The
changes also became a little confusing (at least to me), as they were inconsistent to
other contents, and some things I cannot reproduce to be really important in the very
context, which is why I had to remove it. Also, I was asked to massively reduce the
summary, which I did.
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:
I really wish I could add all opinions, and everything you mentioned - all your
points are worth mentioning. But at some point, we have to leave it to the
debate: if I elaborate all types of opinions and all perspectives, this is no
longer just an essay but a book. I try to contain the summary of the opposite
opinion. I am happy to adjust it, but it should remain a paragraph in the
feedback section.
* 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".
Thanks for the compliment :)
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.
I think this leads back to the the perspectives of the best compromise. My opinion is that the overall environment becomes more dangerous with ptrace_scope being disabled, as I have seen also many developers who hardly understand the underlying operating system, and thus act accordingly (up to put to install every package they read to solve some problem without questioning the source etc.). So for all audiences, ptrace_scope can add security that balances some bad practices/decisions. If a developer is so "unmindful" that they directly start working in root rather than checking out what is going on or how to do it again without root, especially if documentation is there, well, then they do so likely in all situations, and I don't think this makes a difference. With ptrace_scope, we at least leave them the choice to make it themselves, and rationalize that this is something without perfect compromise. Anyway, I understand and respect your thoughts. In the end, the proposal is
to find out which compromise is the best one for the majority.
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
