Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Because it's intractable on Linux and advocates don't want to admit that. The entire security model on Linux is resistant to deeper levels of access and control for applications, which is required for kernel level anti-cheat. While these forms of anti-cheats can't stop cheating, they are clearly more effective than user-space anti-cheats. For 99% of users, we gladly accept these more "invasive" anti-cheats because it means less cheating in the games we enjoy. Linux developers will never allow this kind of access because it is antithetical to their ideological beliefs around security. They gladly exclude any kernel level cheats to maintain the security model. It is a permanent impasse. One which I believe will never be solved with user-space or server-side detection. This is why the most common retort is: "just play different games."

To be frank, the argument that kernel level anti-cheats are invasive has never been all that accurate or compelling. Any user-space application already has numerous privileges which could ruin your day. You trust a developer and application every time you run it, irrespective of its access level. Valve has an opportunity now with SteamOS to impose technologies like SecureBoot and "safe" deeper layer anti-cheats which actually work. Yes, Linux enthusiasts would be up in arms, but it would mean that the most popular online FPS games would be supported on Linux, and I think that's far more important.



> For 99% of users, we gladly accept these more "invasive" anti-cheats because it means less cheating in the games we enjoy.

The modal user likely doesn’t even know anti-cheat exists, and if they did, wouldn’t care at all. They just want to play the game.


They want to play the game without cheaters. That's why studios use anti-cheats.


Well, it's not intractable if it's pushed to the underlying hardware and signed drivers.

Valve could build something into their chipset and start signing the Steam Deck drivers, create secure boot etc and essentially create an Apple SIP equivalent. Wouldn't work for the rest of the Linux ecosystem or other devices, and people would absolutely howl about it, but they could do it.


The other side is linux totally permits you to do whatever you like to your system, and then it's similar discussion to DRM (digital rights management, not direct rendering manager). When you're trying to the user from doing things they're not allowed to and the same user can fiddle with the system, there's no starting point for trust.


I run Steam in flatpak, so my games are sandboxed and do not have access to my home directory. I don’t have to trust anyone.


That's an added layer of protection but it's hardly foolproof. A malicious game/app can still:

* Exfiltrate personal data from allowed Flatpak directories

* Steal data you intentionally open via portals (e.g., documents, password files, wallet backups)

* Store malware or persistence files inside the Flatpak sandbox

* Use network access to phone home data or join botnets

* Abuse CPU/GPU for crypto mining

* Delete or modify files in your home directory if granted --filesystem=home

* Read browser cookies, auth tokens, SSH keys, cloud credentials if home is exposed

* Install persistence via ~/.config/systemd/user/ services

* Global keystroke logging on X11

* Screenshot entire desktop on X11

* Inject fake input events to the system (mouse/keyboard) on X11

* Record screen via portals if user once granted permission

* Gain full FS access if granted --filesystem=host

* Abuse DBus to change system settings or trigger polkit actions

* Install software outside the sandbox (e.g., ~/.local/bin or autostart scripts)

* Interact with hardware via /dev if granted --device=all

* Trigger kernel or driver privilege-escalation vulnerabilities

* Load or execute unsafe third-party mods, DLLs, or anti-cheat binaries

* Malicious patchers or mod loaders downloading external payloads

* Replace shell history or alter aliases to hide malicious activity

* Encrypt local or network-mounted files (ransomware)

* Spread laterally via stolen SSH keys to other machines

* Manipulate GPU/driver calls for rootkit-like persistence

* Abuse Wine/Proton compatibility layers to escape sandbox using native loaders

* Modify dotfiles (.bashrc, .profile) for stealth persistence

* Abuse LAN trust to attack other devices on the network

* Disrupt system performance via thermal abuse (extreme sustained loads)

* Exfiltrate browser sessions or wallet seeds stored in plaintext

* Execute background processes whenever game is launched without user awareness


Same.

This is The Way.

Bonus: No game files junking up my home directory.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: