3 ms·

We can now kiss-gone the security for embedded world and its IoT-related security brethren. It is often the directory separation of /bin and /usr/bin that is u

We can now kiss-gone the security for embedded world and its IoT-related security brethren. It is often the directory separation of /bin and /usr/bin that is used to denote the extent of firmware’s scope between these binaries that are require for a boot up and what are they require to support their applications. (Thanks, PDP-11). Such wonderful boundaries of IoT upgrade scope can and is often denoted as two-stage upgrade with /bin as read-only; now, not so much. This is yet another case of IoT system engineering design getting steamrolled by the diminutive desktop-mindsets despite progress by its systemd author. Try yanking that Ethernet cable from its physical socket and watch if your long-running deeply-stateful process can survive. (It won’t, unless you retrain it against KISS principle to ignore such netdev disappearance.)

yjftsjthsd-h 5y ago
> We can now kiss-gone the security for embedded world and its IoT-related security brethren. Is anyone using Debian for that kind of thing? When I hear embedded, I expect buildroot or at least Alpine Linux.
WhyNotHugo 5y ago
Using `/usr/bin/` readonly is also a thing on some few distros (e.g.: Fedora Silverblue), so maybe you want to consider that for your usecase. For device-local binaries (e.g.: not part of firmware), /usr/local/bin sounds like the right choice (also, somewhat in line what some BSDs do).
- egberts1 5y ago
  This is just another direction to desktop-hive mentality with a focus toward minimizing security. Perhaps, it might be ideal and suitable to Windows-ize for your case; the security modeling of many designs, not so much.
  - WhyNotHugo 5y ago
    How does this minimise security? I don't see how Window is relevant; it doesn't have /usr nor /usr/bin.
    - egberts1 5y ago
      Precisely, Windows have centralized directories for system executables.
      - tremon 5y ago
        Perhaps it would be better if you stopped implying and started to make your point explicitly. Because if your point is that there is some security boundary in Windows that allows an application installer to write to %PROGRAMFILES% but not to \WINDOWS\SYSTEM32, then you are sorely mistaken.
Nullabillity 5y ago
First of all, this is a reliability question, not a security one. If someone malicious already has write access to /usr/bin then you're already screwed, there's not much damage you can do with a compromised /bin that you can't already do with a compromised /usr/bin. Not to mention that they probably also have enough privileges already to do whatever damage they want to do, without having to trick some other process into running their payload. From the reliability perspective (protecting against accidental damage), the /usr merge makes it easier to set up A/B booting and protect the entire system, rather than blessing a small subset of the system and preventing anyone from upgrading those components at all in the future.

yjftsjthsd-h 5y ago

> We can now kiss-gone the security for embedded world and its IoT-related security brethren. Is anyone using Debian for that kind of thing? When I hear embedded, I expect buildroot or at least Alpine Linux.

WhyNotHugo 5y ago

Using `/usr/bin/` readonly is also a thing on some few distros (e.g.: Fedora Silverblue), so maybe you want to consider that for your usecase. For device-local binaries (e.g.: not part of firmware), /usr/local/bin sounds like the right choice (also, somewhat in line what some BSDs do).

egberts1 5y ago
This is just another direction to desktop-hive mentality with a focus toward minimizing security. Perhaps, it might be ideal and suitable to Windows-ize for your case; the security modeling of many designs, not so much.
- WhyNotHugo 5y ago
  How does this minimise security? I don't see how Window is relevant; it doesn't have /usr nor /usr/bin.
  - egberts1 5y ago
    Precisely, Windows have centralized directories for system executables.
    - tremon 5y ago
      Perhaps it would be better if you stopped implying and started to make your point explicitly. Because if your point is that there is some security boundary in Windows that allows an application installer to write to %PROGRAMFILES% but not to \WINDOWS\SYSTEM32, then you are sorely mistaken.

Nullabillity 5y ago

First of all, this is a reliability question, not a security one. If someone malicious already has write access to /usr/bin then you're already screwed, there's not much damage you can do with a compromised /bin that you can't already do with a compromised /usr/bin. Not to mention that they probably also have enough privileges already to do whatever damage they want to do, without having to trick some other process into running their payload. From the reliability perspective (protecting against accidental damage), the /usr merge makes it easier to set up A/B booting and protect the entire system, rather than blessing a small subset of the system and preventing anyone from upgrading those components at all in the future.