Too bad the major Linux Distros tossed this out the window years ago.
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.
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.
Can you expand on that? What does /usr/bin have to do with embedded systems programming??
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-...
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.
> 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.
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.
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.
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.
- 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).
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.
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.
FYI, UsrMerge is being (rightfully) adopted by multiple distros including SUSE, Debian, and Arch.
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.