Hi Frank,

On Mon, Nov 17, 2025 at 01:17:05PM -0500, Frank Ch. Eigler wrote:
> 
> Christopher Klooz <[email protected]> writes:
> 
> > Implementing feedback from the Discourse thread [...]
> 
> Please consider just starting over.  The text as written is unreadably
> verbose and hides the small number of empirically disputable issues into
> long stream-of-consciousness paragraphs.  The core issue has been
> summarized by mjw and others.  It can be expressed in as few words as these:
> 
> "Set yama.ptrace_scope=1 sysctl by default ?"
> 
> * Applies to non-root users.
> * This disables debugging-like tools on arbitrary sibling processes
>   e.g. gdb /bin/foo $PID
> * It may have security advantages, such as a penetrated program not
>   being able to modify its siblings.
> * The kernel switched.  Other distros switched.  Debian didn't.  Fedora 
> didn't.
> 
> Option 1) status quo
> 
> Option 2) adopt kernel yama.ptrace_scope=1, forcing users to switch to
>   root to debug sibling processes, or manually turn off that sysctl
>   variable.
> 
> Option 3) adopt kernel yama.ptrace_scope=1 by default, but invite
>   debugger-like packages to Require/Suggest:/Recommend: a
>   default-yama-scope rpm that resets it to =0, restoring status quo
>   only on those machines that install these tools.
> 
> That's all this is about.

Thanks for the short summary. That makes it much easier to discuss the
proposal.

> (FWIW, I would support options 1 or 3, thinking the security benefits
> too small to worry about.)

Agreed. Especially since we are talking about a mitigation against
already compromised executables that can do everything a normal user
process can already do.

Hopefully we can just keep the status quo and concentrate on real
security mitigations for running "untrusted" processes in a more
confined way. Which I think is more productive than trying to document
the stuff that is broken out of the box.

Thanks,

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

Reply via email to