←back to thread

466 points CoolCold | 2 comments | | HN request time: 0.018s | source
Show context
rahen ◴[] No.40207843[source]
I thought doas had solved this already.
replies(2): >>40207875 #>>40207960 #
progval ◴[] No.40207875[source]
doas uses SUID
replies(1): >>40208038 #
bandrami ◴[] No.40208038[source]
It either has to be SUID or it has be a daemon running as root (or with enough caps to make the difference not matter). Adding a needlessly verbose configuration ecosystem doesn't change that. I imagine there's going to be some cool stuff this can do with homed and userctl, but it's not like the fundamental problem of "this program can grant root privileges" can ever go away.
replies(1): >>40208419 #
dale_glass ◴[] No.40208419[source]
The problem is not "this program can grant root privileges", it's that the setuid bit sucks.

Linux processes inherit a lot of state from the parent which means it's absolute hell to make a secure setuid binary. And at any time the Linux kernel can add a new feature which will be inherited by a child process, but that the process can't defend against because it wasn't even a thing when the code was written.

Running a binary at all also goes through a complex set of initialization steps a lot of programmers barely know exist, let alone are able to understand fully.

replies(1): >>40208955 #
1. bandrami ◴[] No.40208955[source]
Sure, but your choices are running an on-demand binary suid root, or running a persistent daemon as root.

Both have problems, but if you're going to switch users to root you have to do one of them.

replies(1): >>40209123 #
2. dale_glass ◴[] No.40209123[source]
The tool doesn't try to do away with root, it tries to do await with the setuid bit. Meaning, "running a persistent daemon as root" is the intentional solution, and presented as the significantly better option for good security.