On 16/09/2025 11.26, Florian Weimer wrote:
* Christopher Klooz:
Even if the proposal would be implemented with ptrace_scope being 2,
you would **not** need to reboot to change the ptrace_scope condition
-> `sysctl kernel.yama.ptrace_scope=0` would temporarily disable it
(immediately!) without reboot.
You can also run strace and gdb as root, where the restrictions do not
apply. It's simpler than fiddling with the sysctl, I think.
I expect that the net effect of this change will be that quite a few of
us run these tools as root. From a security perspective, it doesn't
matter because our machines tend to be single-user anyway, but there's
definitely a trade-off here.
Hmm... Well, it surely is a type of trade-off once something changes for
someone in a way that is not unconditionally advantageous.
Adding a line to the 99-sysctl.conf is quick and easy. However, sure, if some
find out that root still works, it might occur that some do not even check for
documentation/background and just use it. But my experience is that if users
start to work that way, they do it in all areas, and then it is just one of
many avoidable root uses. As you say, usually single-user anyway.
I concur with the suggestions to split this into separate proposals.
I can understand that point. On one hand, I had limited time when I saw the elaborated issues, and tbh, I have seen that relevant security considerations remained neglected/dismissed. In short, I was not sure if it is worth the time to do more but rather see if something can develop from this at all, and raise some awareness. Also, I thought this is worth some more immediate consideration and see where this is going: especially about the package that is now system-wide -> if and what could be agreed about it, given it is currently effectively a change that was never approved as it was not intended the way it is, while it is unclear what (other?) adjustment could resolve the issue reliably while still being "acceptable". Depending on what happens about this, it is unclear if the related part of the proposal is even compatible. Therefore, I took the time to raise a discussion, and if it cannot be accepted that way but the outcome of FESCo's evaluation is that this (or parts of
it) could be seriously considered, I will be happy to split the proposal if necessary (I expect a feedback about the unintended system-wide deployment of the package to consider it in future proposals though). However, if I split, I might need either much time as I am not sure if I can invest much at the moment, or get a co-owner. So if anyone is +1 for the proposal(s) , they might let me know, I will open a topic about it anyway if it becomes necessary. We'll see :)
The BPF hardening may also need further discussion. As far as I can
tell, we already disable unprivileged BPF, so I don't see why further
hardening is needed, given that the code comes from root anyway.
It adds a security layer. If one breaks, the other is still there. And that one
is quite straightforward / simple and thus predictable (not sure about the
other, if there are complexities that might allow (in)directly to enable it
again without root). Anyway, IF unprivileged BPF is OFF, this change at the
given level by definition could not cause negative impacts, but would still add
a security layer.
Thanks,
Florian
--
_______________________________________________
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
