3 ms·

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

> 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

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.