Skip to content

[BUG] Using toggle-anticheat-support to disable anti-cheat breaks dangerzone #1972

@jherzstein

Description

@jherzstein

Description

With dangerzone installed, disabling anti-cheat using the toggle-anticheat-support script will break dangerzone due to ptrace_scope being too restrictive. toggle-anticheat-support on disable will set ptrace_scope to 3 and dangerzone requires ptrace_scope is set to 2 or lower.

This bug is a bit of an edge case and fairly easy to avoid, but can still occur if the user is not paying attention to how they're using their scripts and how it's affecting ptrace permissions.

Reproduce

Here is one way this issue might be reproduced:

  1. Have toggle-anticheat-support to enable anti-cheat or manually set ptrace_scope = 1 in /etc/sysctl.d/61-ptrace-scope.conf.
  2. Layer the dangerzone package using install_dangerzone ujust script.
  3. Use toggle-anticheat-support to disable anti-cheat; ptrace_scope is set to 3.
  4. Reboot to apply ptrace permissions.
  5. Run dangerzone.

Expected

I see a few ways toggle-anticheat-support can have better guardrails to avoid this:

  1. toggle-anticheat-support sends a warning if dangerzone package is detected on the host system and functionality will break before disabling anti-cheat.
  2. toggle-anticheat-support quietly sets ptrace_scope to 2 on disable if dangerzone is detected on host system, but this is a security degradation and arguably breaks userspace.
  3. toggle-anticheat-support sends a prompt on whether to still allow "admin-only" ptrace on anti-cheat disable.

My first impression is that option 3 would be the best approach. However, I think there should be feedback on if another implementation is preferred before this becomes a PR.

Another thing worth considering is how this should look when implementing a consistent style for ujust commands (see: #1488, #1161). For example, if toggle-anticheat-support becomes set-anticheat-support <on | off> in the future, should there be a suppression flag for the prompt as described in option 3? It's worth considering.

Actual

See #1523, ptrace permissions break dangerzone.

Image

ostree-image-signed:docker://ghcr.io/secureblue/sericea-main-hardened:latest Digest: sha256:34d97f217df10bf84f6ff3902d3d0762ed76a8a70410970b422242bb6ed02eb8 Version: 43.20260221.0 (2026-02-22T02:44:33Z)

Upstream

...

Declaration

  • I agree to follow this project's Code of Conduct.
  • I declare that this is not a request for alternate community messaging or social platforms.
  • I declare that I have read the secureblue website and my feature request is in-scope.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinggood first issueGood for newcomers

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions