3 ms·

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 co

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.

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.