Linux Capabilities Revisited • Hacker News Board

Re: Linux Capabilities Revisited

#41

Post by cyphar » Thu, Oct 23, 2025, 12:09 PM UTC

cyberax wrote: post #30

lagosfractal42 wrote: post #28

Earlier quoted context omitted.

> Meanwhile, complex external systems like SELinux end up being unused because they are complex and external (and thus can just be ignored). Wdym? It's very notably used in Android

Yeah, because they have a team of engineers working on it. They can afford that. I have never seen SELinux used on a regular server. Heck, Amazon Linux AMIs on AWS even disable it by default. Yeah, yeah, personal experience and all that.

This has changed a lot in the past decade -- any modern Fedora box has SELinux enabled by default now and so I would wager the majority of Fedora/CentOS/AlmaLinux/RHEL boxes have SELinux enabled and in enforcing mode. openSUSE/SLES is also switching to SELinux in 16.0.

Disclaimer: I work for SUSE.

Re: Linux Capabilities Revisited

#42

Post by cryptonector » Thu, Oct 23, 2025, 3:48 PM UTC

WhyNotHugo wrote: post #24

I find Linux’s approach on capabilities underwhelming, and not even close to a true capability-based system. For example, you can pass a program a capability to bind any privileged port, but not a specific one. For this scenario, just passing an fd bound to the port is actually much simpler and safer. For other capabilities, they’re just too coarse. The fact that capabilities are implicitly inherited also doesn’t sou…

Ditto Solaris' privileges system (which is basically Linux capabilities done better, but still the same abstract model).

Re: Linux Capabilities Revisited

#43

Post by munchlax » Thu, Oct 23, 2025, 5:47 PM UTC

charcircuit wrote: post #36

munchlax wrote: post #29

Earlier quoted context omitted.

I doubt you could keylog my openbsd server that I remote into over ssh or serial. I also doubt you can take pictures of me when it doesn't have cameras attached. If it did and you were to take pictures, you'd see some blinking leds and cables all day. And I highly doubt you could take remote control even if I had openssh open to the public. Perhaps your industry just doesn't care about the same things the openbsd com…

Bash aliases and PATH aren't protected so malware can change ssh to something else and steal your encryption password to decrypt your keys.

Yeah but how does the malware get there?

It would be very powerful to get malware into ports and packages. It would also be noticed rather quickly. OpenBSD developers tend to run everything through dynamic tracers and other debugging tools.