3 ms·
Genuinely curious - why would world-writeable directory be bad for security? Assuming of course, it's on a separate filesystem mounted with sensible options. He
by kees99 11mo ago
Genuinely curious - why would world-writeable directory be bad for security? Assuming of course, it's on a separate filesystem mounted with sensible options. Here's what I see from "grep /run/lock /proc/mounts" in sid:
rw,nosuid,nodev,noexec,size=5120k
- seanhunter 11mo agoThe classic is say you know a root process will write a file called foo.lock in /run/lock, and you (a bad person) have write access to that directory. Then you make foo.lock a symlink to some file (/bin/init or /bin/sh or ld.so for example would be very inconvenient choices) and when the root process writes its lock it destroys that file. Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.
- deleted 11mo ago[deleted]
- amiga386 11mo ago> and when the root process writes its lock it destroys that file. Unless you do open("/run/lock/foo.lock", O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW)
- kees99 11mo agoYep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".
- seanhunter 11mo agoYup to both of you. But all of this is to say, running shellscripts as root (in particular) needs to be done with extreme care, because if people forget those precautions when writing C, they sure as heck don’t trouble themselves to do it when they’re writing shell. I remember the time (around 2001-2002) when just about every binary was discovered to have some variant on this exact exploit. I happened to be linux sysadmin for a very large, high-profile set of linux boxes at the time. Happy times.
- mschuster91 11mo ago> Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way. Annoying side effect: now you gotta guess which process created the darn lockfile. A more sensible approach is to do sanity checking on the lockfile and its contents (i.e. does the contained PID match one's own binary).
- seanhunter 11mo ago> now you gotta guess which process created the darn lockfile Or you can use “lsof” to just tell you.
- albertzeyer 11mo agoThe argument is also that you could effectively DoS the system by exhausting space or inodes.