3 ms·

> 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 t

> 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.

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.