Most active commenters
  • charcircuit(4)
  • hypeatei(3)

←back to thread

Linux Capabilities Revisited

(dfir.ch)
190 points Harvesterify | 16 comments | 22 Oct 25 13:50 UTC | HN request time: 0.002s | source | bottom
Show context
surajrmal ◴[22 Oct 25 14:42 UTC] No.45669852[source]▶
A shared global namespace ultimately makes it very difficult to have a decent capability based security system. Namespaces limited to the set of actions you have and a hierarchy of capabilities whereby children can only be given access to capabilities their parents have is required for a sane view of how things work. Much like encapsulation makes it easier to reason about abstractions in a program, this nested hierarchy of capabilities makes it easier to reason about the privilege of various parts of the system. Instead we have soup where no one can quite reason about what has access to what.
replies(6): >>45670120 #>>45670198 #>>45670857 #>>45671117 #>>45671465 #>>45674367 #
1. rootnod3 ◴[22 Oct 25 14:57 UTC] No.45670120[source]▶
Even if not super fine grained, I think that OpenBSD’s pledge is really nicely done.

Next after that I’d vote for FreeBSD’s capsicum.

replies(2): >>45670403 #>>45671131 #
2. hypeatei ◴[22 Oct 25 15:13 UTC] No.45670403[source]▶
OpenBSDs pledge is so simple and nice to use. I really wish Linux would incorporate it. Seccomp is a nightmare to implement.
replies(2): >>45670913 #>>45672383 #
3. rootnod3 ◴[22 Oct 25 15:46 UTC] No.45670913[source]▶
I'd rather have a simple coarse-grained mechanism than whatever feverdream that seccomp, selinux and apparmor are. A convoluted mess incorporating almost Turing complete languages that are just asking to shoot yourself in the foot a mile deep.

The simplicity of pledge is good enough for 99% of use-cases I'd wager AND easy to add to existing code.

4. charcircuit ◴[22 Oct 25 16:00 UTC] No.45671131[source]▶
I disagree. Pledge requires every app to OPT IN to security. This means that most apps won't do it, and the ones that do will likely be lazy and restrict their usage to what they use before and won't do the work of rearchitecting things.
replies(4): >>45671362 #>>45671634 #>>45672570 #>>45675089 #
5. hypeatei ◴[22 Oct 25 16:13 UTC] No.45671362[source]▶
So we shouldn't provide simple hardening tools because it won't be used or applied how you'd like in 100% of software? This mindset in security circles really needs to stop.

If a piece of important or foundational software wants to lock itself down today, look at the myriad of convoluted "solutions" mentioned in a sibling comment. If you wanted to discourage progress in this area, that's how you'd design something. I'm not assuming malice, obviously, but it's certainly a product of the endless nitpicking and "not good enough, doesn't cover <niche usecase>" type of thinking.

EDIT:

> and the ones that do will likely be lazy

I'd argue the opposite, any developer taking the time to add some pledge calls to their code is probably mindful of security and wants to improve it. If you wanted to be lazy, you'd just... not implement pledge at all since it'd get in your way and be too restrictive.

replies(1): >>45674220 #
6. cyberax ◴[22 Oct 25 16:31 UTC] No.45671634[source]▶
The thing is, it works better. A simple API like pledge/unveil allows apps to significantly improve the security level without much of time investment.

Meanwhile, complex external systems like SELinux end up being unused because they are complex and external (and thus can just be ignored).

replies(2): >>45674031 #>>45674615 #
7. eikenberry ◴[22 Oct 25 17:29 UTC] No.45672383[source]▶
There is a port...

    https://github.com/jart/pledge

    https://justine.lol/pledge/
replies(1): >>45672804 #
8. elevation ◴[22 Oct 25 17:42 UTC] No.45672570[source]▶
Tools like SELinux allow administrators to restrict a program before it runs, a sort of guard rail.

pledge() allows developers to further restrict a program dynamically at runtime. More like defensive driving.

Both are useful techniques.

9. hypeatei ◴[22 Oct 25 17:57 UTC] No.45672804{3}[source]▶
That uses seccomp under the hood and requires a custom libc, I think?

Definitely a nice project, but I don't know if I'd use it in production.

10. charcircuit ◴[22 Oct 25 19:32 UTC] No.45674031{3}[source]▶
>it works better

It doesn't. You can download malware and the app can cryptolock your entire system. Sure, if the malware called pledge to block opening files but what malware is going to do that?

11. charcircuit ◴[22 Oct 25 19:47 UTC] No.45674220{3}[source]▶
It's not that we shouldn't provide it, but it doesn't make sense invest into when OpenBSDs security is so far behind the rest of the industry. A program being able to steal your .ssh keys without you knows is unacceptable. Not only that but programs can keylog you, take pictures of what you are doing, or take remote control of your computer.
replies(1): >>45674667 #
12. lagosfractal42 ◴[22 Oct 25 20:18 UTC] No.45674615{3}[source]▶
> 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

replies(1): >>45674738 #
13. munchlax ◴[22 Oct 25 20:22 UTC] No.45674667{4}[source]▶
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 community does.

Edit: I missed the ssh key stealing. My keys are always encrypted.

replies(1): >>45676973 #
14. cyberax ◴[22 Oct 25 20:28 UTC] No.45674738{4}[source]▶
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.

15. 0x457 ◴[22 Oct 25 21:01 UTC] No.45675089[source]▶
Sure, it won't be used a lot, but some applications will. Including application that lets you wrap any other application like https://wiki.alpinelinux.org/wiki/Bubblewrap
16. charcircuit ◴[23 Oct 25 00:49 UTC] No.45676973{5}[source]▶
Bash aliases and PATH aren't protected so malware can change ssh to something else and steal your encryption password to decrypt your keys.