3 ms·

That feels entirely wrong to me. sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper

by rurban 3y ago

That feels entirely wrong to me. sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper cleanup.

yjftsjthsd-h 3y ago
OpenSUSE did that; it was IMO marginally inconvenient because (IIRC) it broke tab completion of sbin binaries, even with sudo. Ex, "sudo pow<tab>" wouldn't give you poweroff.
- rurban 3y ago
  Well, that would be trivial to fix by detecting the magic sudo, and add /usr/sbin to the completion searchpath
amluto 3y ago
There are really quite few programs that can’t be invoked by regular-ish users in the brave new world of user namespaces. It’s also entirely unclear to me why trying to sort programs into these particular buckets is useful. At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.
- spookie 3y ago
  We should learn from the xz incident. It's little things like these that make compromise harder. Not saying the fact that sbin exists did anything, but that more layers of armor is always better.
  - amluto 3y ago
    We should learn from the xz incident by adding real security. For example, the ways programs use libraries could be restructured to prevent libraries, and especially libraries whose functions are not called, from having side effects. Or packaging tools could learn to verify that a release is exactly a git commit and not some tarball that may or may not have any particular relationship to a commit. Or we could make sure sshd is in /usr/sbin? I don’t get it. What does that accomplish? It’s not as if the stuff in a directory called “sbin” is inherently more “secure”.
    - spookie 3y ago
      If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). Look, I don't say this as the end all, be all. Just another piece of the puzzle. Think of how chaotic Linux land is. It's true it can be thought as a liability, but distros' heterogeneous nature could also be a defense, and sbin itself can be thought as another defense. For example, in openSUSE Leap 15.6 at least, a lot of critical binaries are located in sbin. They are placed there not only as a static fallback for maintenance, but also as a means to minimize the attack surface of the OS. It is much more likely for your system to be compromised at a user level, and not at a superuser level. I know the xz incident wasn't the best example, and of course there are better solutions than this.
      - amluto 3y ago
        > If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have. (Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)
  - Nullabillity 3y ago
    sbin is not, and was never, a security barrier.
kazinator 3y ago
Aren't you advocating breaking scripts that reference executables in /sbin or /usr/sbin? sbins that could be invoked by users cannot just move to /bin, if scripts expect them to be in /sbin. It looks like Fedora has decided that the sbin distinction is historic fluff. There is no need to put a program in a separate directory just because it makes system calls that require root and therefore fail for a regular user. The article makes it clear that before this change, there is already no /bin directory, but rather /bin is a symlink to /usr/bin and /sbin is a symlink to /usr/sbin. I.e. they already decided that the the shortened /bin and /sbin paths are historic fluff; everything will be in /usr. The symlinks are needed for compatibility. You know, like #!/bin/sh and whatnot. Now they are getting rid of /usr/sbin. So that becomes a symlink to bin (I'm assuming relative, I.e. /usr/sbin -> bin). Thus, all combinations of {/usr}?/{bin|sbin}/<program> become equivalent, and only /usr/bin is a real directory where all the system binaries live.

by rurban 3y ago

That feels entirely wrong to me. sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper cleanup.

yjftsjthsd-h 3y ago

OpenSUSE did that; it was IMO marginally inconvenient because (IIRC) it broke tab completion of sbin binaries, even with sudo. Ex, "sudo pow<tab>" wouldn't give you poweroff.

rurban 3y ago
Well, that would be trivial to fix by detecting the magic sudo, and add /usr/sbin to the completion searchpath

amluto 3y ago

There are really quite few programs that can’t be invoked by regular-ish users in the brave new world of user namespaces. It’s also entirely unclear to me why trying to sort programs into these particular buckets is useful. At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.

spookie 3y ago
We should learn from the xz incident. It's little things like these that make compromise harder. Not saying the fact that sbin exists did anything, but that more layers of armor is always better.
- amluto 3y ago
  We should learn from the xz incident by adding real security. For example, the ways programs use libraries could be restructured to prevent libraries, and especially libraries whose functions are not called, from having side effects. Or packaging tools could learn to verify that a release is exactly a git commit and not some tarball that may or may not have any particular relationship to a commit. Or we could make sure sshd is in /usr/sbin? I don’t get it. What does that accomplish? It’s not as if the stuff in a directory called “sbin” is inherently more “secure”.
  - spookie 3y ago
    If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). Look, I don't say this as the end all, be all. Just another piece of the puzzle. Think of how chaotic Linux land is. It's true it can be thought as a liability, but distros' heterogeneous nature could also be a defense, and sbin itself can be thought as another defense. For example, in openSUSE Leap 15.6 at least, a lot of critical binaries are located in sbin. They are placed there not only as a static fallback for maintenance, but also as a means to minimize the attack surface of the OS. It is much more likely for your system to be compromised at a user level, and not at a superuser level. I know the xz incident wasn't the best example, and of course there are better solutions than this.
    - amluto 3y ago
      > If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have. (Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)
- Nullabillity 3y ago
  sbin is not, and was never, a security barrier.

kazinator 3y ago

Aren't you advocating breaking scripts that reference executables in /sbin or /usr/sbin? sbins that could be invoked by users cannot just move to /bin, if scripts expect them to be in /sbin. It looks like Fedora has decided that the sbin distinction is historic fluff. There is no need to put a program in a separate directory just because it makes system calls that require root and therefore fail for a regular user. The article makes it clear that before this change, there is already no /bin directory, but rather /bin is a symlink to /usr/bin and /sbin is a symlink to /usr/sbin. I.e. they already decided that the the shortened /bin and /sbin paths are historic fluff; everything will be in /usr. The symlinks are needed for compatibility. You know, like #!/bin/sh and whatnot. Now they are getting rid of /usr/sbin. So that becomes a symlink to bin (I'm assuming relative, I.e. /usr/sbin -> bin). Thus, all combinations of {/usr}?/{bin|sbin}/<program> become equivalent, and only /usr/bin is a real directory where all the system binaries live.