F45 Change Proposal: Restrict ptrace by default [SystemWide]

Project Discussion Change Proposals
, ,
1

Restrict ptrace by default

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

By default, disable some debugging permissions for unprivileged users using a system-wide kernel setting, so malware cannot inspect other preexisting processes of an unprivileged user. When debugging tools are installed, re-enable full normal functionality system-wide using a sysctl file, as is the status quo up to Fedora 44.

This is a compromise proposal to followup several failures to achieve a consensus.

Owner :open_book:

Detailed Description :open_book:

ptrace is a kernel API that enables debugging-like tools to inspect and take control of processes and their data on a linux system. It is essential for profilers and debuggers. The linux environment traditionally allows a user to ptrace (debug) only their own processes, but does not restrict processes to ptrace other processes of the same user. A few years ago, a linux security module called [https://www.kernel.org/doc/Documentation/admin-guide/LSM/Yama.rst yama] was added to the kernel to further limit ptrace to child processes only. This mode allows debuggers and profilers to start child processes to inspect, but not to attach to another preexisting process, even if it belongs to the same user. This mode setting does not affect processing core files nor producing core dumps. Also, this mode setting does not affect root.

Since yama broke several use cases for developers, Fedora included an override sysctl.d file in the elfutils-default-yama-scope subpackage, which was required by a low-level library required by core Fedora userspace, thus installed on every Fedora system. This means on current Fedora versions, yama is disabled and ptrace operations are generally permitted. The kernel default is that yama is enabled. Most Linux distributions adopted the kernel default (e.g., Arch, openSuSE, Ubuntu), others disabled yama like Fedora (e.g., Debian). But other distributions do not necessarily reflect the best compromise for Fedora.

This proposal implements a compromise of different stakeholders about an acceptable balance between security advantages of yama and the user experience for developers: The kernel yama linux security module setting enabled is systemwide, which restricts ptrace for those fedora machines where no debugging type tools are installed, but ptrace is fully enabled (disabling yama) once one is installed. Specifically:

  • Remove the Requires: default-yama-scope dependency from elfutils-libs
  • For handling upgrades, add Obsoletes: elfutils-default-yama-scope there.
  • Rename elfutils-default-yama-scope to yama-ptrace-enable.
  • Add Recommends: yama-ptrace-enable (or Requires: if appropriate) to each debugger type tool that customarily uses non-child ptrace functionality. None of these packages is installed by default in common composes.
    ** elfutils
    ** systemtap
    ** gdb (currently Recommends: default-yama-scope)
    ** lldb
    ** delve
    ** strace
    ** ltrace
    ** …

Feedback :open_book:

Suggestions related to this have been brought up several times over the years, generally arousing controversy. Most recently, [[Changes/Restrict_ptrace_for_unprivileged_users_to_child_processes_to_match_kernel_default]] was rejected by FESCO, inviting this present change as compromise alternative.

Benefit to Fedora :open_book:

Potential security benefit in some conditions from malicious or captured processes that become unable to inspect a user’s other processes, which may hold crypto or other secrets that might be hard to penetrate otherwise.

Scope :open_book:

  • Proposal owners: Tweak elfutils subpackages as above. File bugs against known ptrace-dependent packages to notify them of the change.
  • Other developers: Packagers of debugging / profiling tools that may customarily operate in non-child mode need to add a Recommends: yama-ptrace-enable or similar to their .spec files.
  • Release engineering: [Making sure you're not a bot! forge 13191]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: Security while still embracing developers and other users.

Upgrade/compatibility impact :open_book:

Machines upgraded from previous versions of Fedora, without any of the non-child ptrace debugger type tools installed, should have the elfutils sysctl file removed. (If FESCO prefers upgrades not to default to the new behaviour, we can omit this part by dropping the “Obsoletes:” part above.)

Machines being upgraded with those non-child ptrace tools already installed should get the file preserved.

Machines that have any debugger-type tools installed should fully work with non-child “-p $PID” type operation.

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? Y/N

How To Test :open_book:

Run a Fedora live-image or install a Fedora image.

Verify that sysctl -a | grep yama shows kernel.yama.ptrace_scope = 1.

Install elfutils or another similar package.

Verify that sysctl -a | grep yama shows kernel.yama.ptrace_scope = 0.

Verify that eu-stack -v -p $$ works.

User Experience :open_book:

Users should not generally notice a difference, unless they use debugger-like packages that do not follow the above “Recommend:” migration path, or are hand-compiled or script-language-based.

Dependencies :open_book:

Debugger type tools that customarily enable non-child ptrace operations should be packaged with the new RPM dependency.

Interpreted programming language runtimes that expose ptrace incidentally should probably not be packaged with this new dependency. Programs written in these languages, packaged into separate RPMs, should.

Contingency Plan :open_book:

  • Contingency mechanism: Restore status quo ante in elfutils.spec.
  • Contingency deadline: Any time before release compose.
  • Blocks release? No.

Documentation :open_book:

“With Fedora 45, the [https://www.kernel.org/doc/Documentation/admin-guide/LSM/Yama.rst kernel] restricts ptrace debugging-type operations in some ways by default, as a security measure. When a debugger-type package is installed, full traditional ptrace functionality is enabled. Install the yama-ptrace-enable package manually if needed.”

Release Notes :open_book:

\n

Last edited by @alking 2026-02-02T14:50:46Z

Last edited by @alking 2026-02-02T14:50:46Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I’m not sure I like the solution proposed here. As I understand it, installing any of the tools listed in the proposal would pull in the yama config override which in turn will allow ptrace system-wide, not only for those specific tools?

I found that there was a previous Change related to ptrace, but using SELinux:
https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace

Do you think it would it be possible to use SELinux to block ptrace for all except some allowlisted programs instead of using the system-wide yama setting? That might allow for more granularity and less surprising effects when installing one of the listed tools.

4

It’s not my favorite approach as we decide for all developers that they want yama disabled & ptrace enabled systemwide and permanently, without asking or informing them, including users who just install it to play without really using it (we propagate that packages can be left installed as this does not “hurt”/impact beyond storage use → 1st proposal).

But that said, FESCo made clear they want us to compromise and that it does not want to take over discussion/compromising: this is what we did, and I have to say I cannot speak for most developers/engineers with gdb/strace use cases as I’m rarely active in this realm, and those developers/engineers who actively spoke up were those +1 to focus on UX rather than yama. In case of a doubt, I assume that they might be more representative for gdb-strace-user-needs than me, and I prefer to not tell them about their own needs → implications have been sufficiently documented in the debates. Among the active contributors in this debate, I see a 2:2, so we need to give both sides equal credit towards a consensus. And given the context we are now working in, the possibilities are to keep it systemwide for everybody the way it is, or only those using gdb etc. With this in mind, I find this a good compromise, and then we can work on better long term solutions that are acceptable for everyone.

Keep in mind that users still can override the override in /etc/sysctl.d/99-sysctl.conf or so. And the maintainers also will have some possibilities to impact their respective tool.

I think most has been said already about the user confinement, enabling SELinux also within/among accounts’ processes (which currently does not touch the processes we “fear” regarding ptrace exploitation): we cannot maintain that, and a lot of stuff is broken regularly (video conferencing in browser for 2 years, cockpit every few updates, flatpak, etc. → we cannot obligate users to write that much bug tickets, even if the issue is often not SELinux but other stuff acting inappropriately, that’s worse and less predictable everything yama could cause :).

The proposal you mention says that it even includes unconfined_t, so without the user confinement: the boolean still exists, but it is effectively equal to the kernel default as far as I see it, but without allowing any exception at all by default. Modifying this to achieve what we want would add much more complexity that needs longer analysis and testing, if it works reliably at all in a way we intend to → implications are less explicitly foreseeable. This is nothing for F45, at least I would not feel able to endorse something like this short term since I’m not sure about the implications and outreach (up to if and when it can break things → not endorsing myself doesn’t mean I would like it if someone could invest the time to get this done asap) → all this would bring us back to keeping yama disabled systemwide for everybody even longer. Based on the experiences with the confined users and other tests , I see much more potential for issues and unintended outcomes with such an SELinux solution for ptrace rather than with the current proposal, which is predictable. I am not convinced that there is a verifiable fire-and-forget SELinux solution to this that is fine grained.

However, reading this proposal of Dan, not sure @zpytela has thoughts about it? Is there a simple and reliable way to use SELinux to restrict ptrace to the few gdb/strace-like use cases without a noteworthy maintenance burden and predictable risks for all use cases of Fedora? (Just in case he knows that off the cuff or so; he surely knows more of it than me)

In any case, even if it is realistic, I think we should go ahead with what we have, and then improve and refine the outcome, may it be with something that has relations to SELinux (I think we need Zdenek on board for this) or without.

5

Tools like GDB and strace need to be able to interact with any program on the system. To be able to do this, any SELinux policy that could be written for them would be smoke & mirrors, no better than unconfined. If policy allowed only GDB/strace to use the ptrace feature, policy would then have to then stop every other process from being able to use gdb/strace for this to be useful, and most non-service processes still run unconfined today.

IMHO this new ptrace proposal is much closer to a reasonable tradeoff than the previous change proposals.

If people consciously install strace/gdb/etc, then it is right that we make those tools work fully. Limitations previously proposed where you could launch a program under gdb/strace, but not attach to an existing program were very unsatisfactory for common development needs.

It would be important, however, to be concious of other RPMs that might have redundant/extraneous dependencies on strace/gdb/etc which would unexpectedly/unwittingly pull them into an non-developer install.

An example of this might be systemtap-testsuite, which IIUC is promoted as a way for sysadmins to validate a systemtap install. That has a slightly surprising dependency on strace. I’m sure there’s a good reason for this dep, but it could still be a surprise to have security weakened by it pulling in strace, which pulls in ptrace policy.

6

Good point, when we found the ptrace_scope condition of Fedora originally several months ago, our (the people discussing in the first topic) assumption was that explicitly this has happened, and that it was an accident that it became a systemwide condition on all default installations (an assumption that has proven wrong of course, but it caused some confusion). Anyway, is there a way to explicitly output all packages that have any of the ptrace-enabled-packages as dependency? An experienced Fedora packager (which I’m not) might know that off the cuff :smiley:

This solution is in any case better than the current condition, as at least the majority will have ptrace_scope protection. But improvement might be possible if some Fedora packages pull gdb/strace and such whereas they do not really need it (not as part of the proposal but inform the maintainers that the impact of these packages has changed → the assumption that, in case of a doubt, more packages as dependencies take just a little more space, does no longer apply here).