3 ms·
The problem with set-user-ID executables is that they (and the dynamic loader they use) effectively operate in a "blacklist" basis: there's a list of "evil" thi
by cesarb 7y ago
The problem with set-user-ID executables is that they (and the dynamic loader they use) effectively operate in a "blacklist" basis: there's a list of "evil" things they have to protect against (in this case, environment variables controlling the dynamic loader), and if they fail to protect against one of them (in this case, the dynamic loader didn't think of protecting against low RLIMIT_DATA, though a component called later by chpass did) it's game over.
Contrast with something like a service called over dbus: the caller has little to no control over the service's environment, and the most the caller can do is try to confuse it with nonsense dbus calls. It's a "whitelist" basis: only calls the service understands (or think it understands) can do anything, everything else is rejected by default.
- useerup 7y agoThis. setuid/SUID root was - and still is - a terrible idea. It is a (deliberate) hole in the security barrier. It was an idea spawned out of necessity because of the limited expressiveness of the standard Unix security model. Once you let a process run with root or other elevated capabilities, that process should be isolated so nothing about the process can be controlled by the unprivileged user. SUID root utilities violates that.
- cryptonector 7y agoIt was a reasonable enough mechanism for the 70s. It certainly isn't now. Now you want to do all legitimate local privilege escalations via IPC.
- deleted 7y ago[deleted]