←back to thread

466 points CoolCold | 2 comments | | HN request time: 0.635s | source
Show context
tommiegannert ◴[] No.40215122[source]
This is playing on the difference between hoping that sudo does the right thing juggling setuid and capabilities, and having a strict IPC boundary between privilege levels.

It sounds like a great use of systemd, for those who want to use it.

replies(1): >>40222162 #
AshamedCaptain ◴[] No.40222162[source]
There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components.

There's no reason to think that if you can't make a simple setuid binary safe, you can make IPC safe. IPC is an order of magnitude more involved. Specially because in order to gain any effective security you need a 3 way IPC (1st level = the client, which is completely untrusted; 2nd level = the request parser, which is trusted but runs without elevated permissions; 3rd level = the actual elevator process, which must run with elevated permissions).

replies(2): >>40228672 #>>40234699 #
1. intelfx ◴[] No.40234699[source]
> There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components

Incorrect, because nowhere in the IPC dance are these components exposed to the same untrusted environment as they are with sudo.

replies(1): >>40234857 #
2. AshamedCaptain ◴[] No.40234857[source]
Yes, they are. The kernel for obvious reasons. Second, the IPC server now has to handle (and possibly pass through data) from the untrusted environment, unless you are happy with a sudo that does not even ferry stdio. Frankly, having properly working suid (the kernel does most of the job) sounds MUCH easier than having this type of APIs exposed to arbitrary users from pid1. In fact, as per Lennart's last sudo tty bug, the issue was with how sudo was exec()ing the target binary in the _target_ context (not the original context). Having sudo as a global daemon instead of a suid exec is not going to protect you against those; actually may make them worse for all I know.