5 ms·

Somehow I feel that if all the time that has been invested in debating and discussing this had been spent on patching the affected apps, the problem would be pr

Somehow I feel that if all the time that has been invested in debating and discussing this had been spent on patching the affected apps, the problem would be properly solved. I mean, yeah, I get it, systemd bad, democracy good, but these world-writable lock folders are actually a huge pain, and adding some shim code to upgrade to a more secure solution seems achievable?

kees99 1y 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 1y ago
  The 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 1y ago
    [deleted]
  - amiga386 1y 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 1y ago
      Yep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".
      - seanhunter 1y ago
        Yup 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 1y 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 1y ago
      > now you gotta guess which process created the darn lockfile Or you can use “lsof” to just tell you.
- albertzeyer 1y ago
  The argument is also that you could effectively DoS the system by exhausting space or inodes.
pjc50 1y ago
Hmm - I see there's now "lockdev" for managing access to things like serial lines, but what's the preferred method of expressing "only one instance of this program should run at any one time"?
- jcgl 1y ago
  I don't know what the preferred method is. But so far, flocking on my own executable works for me.

kees99 1y 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 1y ago
The 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 1y ago
  [deleted]
- amiga386 1y 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 1y ago
    Yep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".
    - seanhunter 1y ago
      Yup 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 1y 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 1y ago
    > now you gotta guess which process created the darn lockfile Or you can use “lsof” to just tell you.
albertzeyer 1y ago
The argument is also that you could effectively DoS the system by exhausting space or inodes.

pjc50 1y ago

Hmm - I see there's now "lockdev" for managing access to things like serial lines, but what's the preferred method of expressing "only one instance of this program should run at any one time"?

jcgl 1y ago
I don't know what the preferred method is. But so far, flocking on my own executable works for me.