3 ms·

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 mor

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.

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.