3 ms·
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
by JoshTriplett 2y ago
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
- Retr0id 2y agoTrue, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
- hedora 2y agoHow is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket? The original unix process abstraction was extremely simple; the entire spec is a few pages. The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works. Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
- Dylan16807 2y ago> How is that any different than a daemon that has a parser error in its message handler The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
- hedora 2y agoAssuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default). Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c https://github.com/TheMilkies/rut/blob/main/rut.c (Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list). The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell). There’s also the config file, but that’s the same for both. Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.