3 ms·

Ummm, there is a general acceptance of a newer version of LFS, version 3. If version mistaken, you must be thinking of just two distros. - NixOS, like totally

Ummm, there is a general acceptance of a newer version of LFS, version 3. If version mistaken, you must be thinking of just two distros. - NixOS, like totally tossed LFSv3 out, 100% - RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out.

egberts1 4y ago
A tiny smatters of Linux distro are smushing both /tmp and /var/tmp. That one is never a good idea, not even in production servers nor embedded world. /tmp gets emptied with each reboot. /var/tmp is about surviving across reboot. But the app would run just fine if it were ever to be emptied. # Alternatively Some have said that /var/cache would be the more appropriate use over /var/tmp. But /var/cache is used for daemon cold restart and reconstruction of internal structures after reboot, restart, reload, or worse, Ethernet cable disconnect under only systemd-networkd (daemon gets killed by systemd). Your prized networked daemon falls into this category. /var/tmp is generally for session-specific (that are expected to survive across reboot) as opposed to daemon’s internal structure. ISC DHCP client is one.
packetlost 4y ago
> This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. Can you expand on that? What does /usr/bin have to do with embedded systems programming??
- egberts1 4y ago
  Glad you ask. In a really, really secured Unix environment, the /bin is typically a read-only partition. In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. Busybox would encompass most of the entries under /bin but it is often that package management must negotiate out-of-band with admin doing upgrades when using bigger “busybox” like GNU utils. Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. So where do you put the upgrades for Intel Management Engine? This paper indirectly covers Intel’s future plan of dealing with these shortcomings. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf https://www.intel.com/content/dam/www/public/us/en/security-... Today’s fight is about making these partitions as easy to upgrade as possible (for /bin.). My assertion is that remote upgrade^H^H^H^H^H^Hrecovery should never be a possibility when your /bin code has been thoroughly vetted and secured.
  - ElectricalUnion 4y ago
    > In a really, really secured Unix environment, the /bin is typically a read-only partition. > In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. I fail to see how this is secure without also securing /etc (PATH, LD_LIBRARY_PATH), /lib, /usr/lib, /usr/bin, /usr/local/bin - and at this point, might as well make the whole root mount thing RO and have a separated block device for the RW parts instead. > Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. Intel ME is _trusted computing_, among with all sad characteristics that "trusted computing" implies; you either have faith that it is working correctly, or your shoud not be making anything that you need security on a platform that embeds it.
    - egberts1 4y ago
      PATH can get emptied and the directory of its own executable is retrieved before a secured app shells out to another app. I think it’s great that you think it is “trusted”, but I prefer the “trust but verify” approach. That’s why using a separate hardware flash chip, that cannot be controlled by CPU instruction due to a hardware switch, has become that last bastion of security nowadays. It is just that it becomes an inconvenience for ease of use in these days and ages. Trade offs.
      - ElectricalUnion 4y ago
        > I think it’s great that you think it is “trusted”, but I prefer the “trust but verify” approach. I don't trust "Trusted computing" at all. It is, by it's own definition, rotten to the core. > The core idea of trusted computing is to give _hardware manufacturers_ control over what software does and does not run on a system by refusing to run unsigned software. "hardware manufacturers" in this case meaning, of course, Intel, not whoever is using their product to build actually productive things.
ElectricalUnion 4y ago
RHEL/Fedora going for unified /bin is about system recovery. On the types of systems you're expected to install RHEL, if you can't mount the root filesystem correctly, then /bin isn't going to help you either - what you need instead is that dracut put your repair/minimal tool set in your initramfs.
- egberts1 4y ago
  System recovery should comprise of two distinct and separate components: - a simple, hardened and vetted “handler” - the upgradable components RedHat now chose to combine the two. And RedHat’s current approach is just now muddling security boundary between the two as my experience shows. This is not new trend but a constant battleground that I have personally fought alongside over many RedHat distros since 1998. After all, their customers are overwhelming them for ease of use of system recovery, as well as for security against persistence malware. But you cannot do both. That’s why Intel is taking another stab at TPM/ME. While Intel is reworking, the current and prudent thing to do is to lockdown the /bin (expand initramd mountings, and I think this should include a separate /usr mount so that / can be mount read-only for one mission profile and /usr be mount read-only for another) Of course, in these days and age, the best security is for /bin to be in a flash partition that is protected by a hardware switch, for /bin not to have any network tools/access, and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to).
  - ElectricalUnion 4y ago
    > But you cannot do both. That’s why Intel is taking another stab at TPM/ME. I trust Intel and their closed blob firmware much less that I trust Red Hat. > While Intel is reworking (...) > Of course, in these days and age (...) and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to). I agree that the current Intel ME isn't trustworthy. It is "trusted computing"/"treacherous computing" after all. But I am also very skeptical about a "new Intel ME" being trustworthy as well. > then to never, ever use the management Ethernet port that ME is tied to This doesn't help a lot when the ME has powers over protection ring -1, and can arbitrarily mess up with your main system.
soraminazuki 4y ago
> NixOS, like totally tossed LFS out, 100% Not quite. NixOS still relies heavily on the FHS layout. It just dropped the usage of some global directories in order to provide features it otherwise couldn't have. More specifically: * Only a few top-level directories are actually dropped, like /bin, /lib, /share, and /usr. Well technically /usr exists, but it only has /usr/bin/env in it and /usr/bin is excluded from the default $PATH. * Individual packages placed under /nix/store/ still adheres to FHS. While packages technically don't need to adhere to FHS, Nix expects commands to be placed under ./bin, man pages under ./share/man, and so on and so forth.
- egberts1 4y ago
  My bad, like 80%.
stryan 4y ago
> RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. FYI, UsrMerge is being (rightfully) adopted by multiple distros including SUSE, Debian, and Arch.
- egberts1 4y ago
  yes, that is the decision made by said distros in the best interest of working toward an easier but REMOTE recovery mechanism. Not something one would not want to do in terms of increasing the overhead of remote (and thusly its general) system administration nor weaken the security stance of an overall host. It may look good to do such smushing of [/usr]/bin for the short term but the introduction of vastly more surface attack areas should give any serious security architects the pause.
trasz 4y ago
Solaris had merged /bin and /usr/bin for like two decades. The difference nowadays is mostly cosmetics; one is a symlink to the other and that’s mostly it. It could make a difference in the eighties when there was a reason for a separate /usr.
- egberts1 4y ago
  yeah, that is true, I havent seen multi-source updater nor embedded feature within SolarisOS/SunOs.
  - trasz 4y ago
    Solaris was sometimes used embedded in some larger machinery, like AWACS.

egberts1 4y ago

A tiny smatters of Linux distro are smushing both /tmp and /var/tmp. That one is never a good idea, not even in production servers nor embedded world. /tmp gets emptied with each reboot. /var/tmp is about surviving across reboot. But the app would run just fine if it were ever to be emptied. # Alternatively Some have said that /var/cache would be the more appropriate use over /var/tmp. But /var/cache is used for daemon cold restart and reconstruction of internal structures after reboot, restart, reload, or worse, Ethernet cable disconnect under only systemd-networkd (daemon gets killed by systemd). Your prized networked daemon falls into this category. /var/tmp is generally for session-specific (that are expected to survive across reboot) as opposed to daemon’s internal structure. ISC DHCP client is one.

packetlost 4y ago

> This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. Can you expand on that? What does /usr/bin have to do with embedded systems programming??

egberts1 4y ago
Glad you ask. In a really, really secured Unix environment, the /bin is typically a read-only partition. In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. Busybox would encompass most of the entries under /bin but it is often that package management must negotiate out-of-band with admin doing upgrades when using bigger “busybox” like GNU utils. Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. So where do you put the upgrades for Intel Management Engine? This paper indirectly covers Intel’s future plan of dealing with these shortcomings. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf https://www.intel.com/content/dam/www/public/us/en/security-... Today’s fight is about making these partitions as easy to upgrade as possible (for /bin.). My assertion is that remote upgrade^H^H^H^H^H^Hrecovery should never be a possibility when your /bin code has been thoroughly vetted and secured.
- ElectricalUnion 4y ago
  > In a really, really secured Unix environment, the /bin is typically a read-only partition. > In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. I fail to see how this is secure without also securing /etc (PATH, LD_LIBRARY_PATH), /lib, /usr/lib, /usr/bin, /usr/local/bin - and at this point, might as well make the whole root mount thing RO and have a separated block device for the RW parts instead. > Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. Intel ME is _trusted computing_, among with all sad characteristics that "trusted computing" implies; you either have faith that it is working correctly, or your shoud not be making anything that you need security on a platform that embeds it.
  - egberts1 4y ago
    PATH can get emptied and the directory of its own executable is retrieved before a secured app shells out to another app. I think it’s great that you think it is “trusted”, but I prefer the “trust but verify” approach. That’s why using a separate hardware flash chip, that cannot be controlled by CPU instruction due to a hardware switch, has become that last bastion of security nowadays. It is just that it becomes an inconvenience for ease of use in these days and ages. Trade offs.
    - ElectricalUnion 4y ago
      > I think it’s great that you think it is “trusted”, but I prefer the “trust but verify” approach. I don't trust "Trusted computing" at all. It is, by it's own definition, rotten to the core. > The core idea of trusted computing is to give _hardware manufacturers_ control over what software does and does not run on a system by refusing to run unsigned software. "hardware manufacturers" in this case meaning, of course, Intel, not whoever is using their product to build actually productive things.

ElectricalUnion 4y ago

RHEL/Fedora going for unified /bin is about system recovery. On the types of systems you're expected to install RHEL, if you can't mount the root filesystem correctly, then /bin isn't going to help you either - what you need instead is that dracut put your repair/minimal tool set in your initramfs.

egberts1 4y ago
System recovery should comprise of two distinct and separate components: - a simple, hardened and vetted “handler” - the upgradable components RedHat now chose to combine the two. And RedHat’s current approach is just now muddling security boundary between the two as my experience shows. This is not new trend but a constant battleground that I have personally fought alongside over many RedHat distros since 1998. After all, their customers are overwhelming them for ease of use of system recovery, as well as for security against persistence malware. But you cannot do both. That’s why Intel is taking another stab at TPM/ME. While Intel is reworking, the current and prudent thing to do is to lockdown the /bin (expand initramd mountings, and I think this should include a separate /usr mount so that / can be mount read-only for one mission profile and /usr be mount read-only for another) Of course, in these days and age, the best security is for /bin to be in a flash partition that is protected by a hardware switch, for /bin not to have any network tools/access, and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to).
- ElectricalUnion 4y ago
  > But you cannot do both. That’s why Intel is taking another stab at TPM/ME. I trust Intel and their closed blob firmware much less that I trust Red Hat. > While Intel is reworking (...) > Of course, in these days and age (...) and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to). I agree that the current Intel ME isn't trustworthy. It is "trusted computing"/"treacherous computing" after all. But I am also very skeptical about a "new Intel ME" being trustworthy as well. > then to never, ever use the management Ethernet port that ME is tied to This doesn't help a lot when the ME has powers over protection ring -1, and can arbitrarily mess up with your main system.

soraminazuki 4y ago

> NixOS, like totally tossed LFS out, 100% Not quite. NixOS still relies heavily on the FHS layout. It just dropped the usage of some global directories in order to provide features it otherwise couldn't have. More specifically: * Only a few top-level directories are actually dropped, like /bin, /lib, /share, and /usr. Well technically /usr exists, but it only has /usr/bin/env in it and /usr/bin is excluded from the default $PATH. * Individual packages placed under /nix/store/ still adheres to FHS. While packages technically don't need to adhere to FHS, Nix expects commands to be placed under ./bin, man pages under ./share/man, and so on and so forth.

egberts1 4y ago
My bad, like 80%.

stryan 4y ago

> RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. FYI, UsrMerge is being (rightfully) adopted by multiple distros including SUSE, Debian, and Arch.

egberts1 4y ago
yes, that is the decision made by said distros in the best interest of working toward an easier but REMOTE recovery mechanism. Not something one would not want to do in terms of increasing the overhead of remote (and thusly its general) system administration nor weaken the security stance of an overall host. It may look good to do such smushing of [/usr]/bin for the short term but the introduction of vastly more surface attack areas should give any serious security architects the pause.

trasz 4y ago

Solaris had merged /bin and /usr/bin for like two decades. The difference nowadays is mostly cosmetics; one is a symlink to the other and that’s mostly it. It could make a difference in the eighties when there was a reason for a separate /usr.

egberts1 4y ago
yeah, that is true, I havent seen multi-source updater nor embedded feature within SolarisOS/SunOs.
- trasz 4y ago
  Solaris was sometimes used embedded in some larger machinery, like AWACS.