The Future of Trusted Linux Computing
ttttt writes "MadPenguin.org tackles the idea of Trusted Computing in its latest column. According to author Matt Hartley, the idea of TC is quite reasonable; offering a locked-down environment offers several advantages to system administrators with possibly troublesome users. 'With the absence of proprietary code in the mix users will find themselves more inclined to trust their own administrators to make the best choices ... And so long as any controlled environment is left with checks and balances [like] the option for withdrawal should a school or business wish to opt out, then more power to those who want a closed off TC in an open source world." LWN.net has an older but slightly more balanced look at the TC approach.
As I understand it, the meaning of Trusted Computing is not that the system administrator will be able to provide a locked-down system. That has long been available with ordinary security measures on Linux and other systems. Rather it means that even the system administrator - even the owner of the computer - will not be able to make the computer do what he wishes rather than what the record industry or movie studios want it to do. This is done by Intel or others supplying some special hardware which won't reveal its private encryption key unless it detects that authorized, signed code is running. Not authorized by the legitimate owner of the computer who is Intel's customer - no, that wouldn't do at all. Rather, that the code is signed by some third party such as Microsoft and there is a secure boot sequence to prevent 'tampering' (i.e., the computer's owner trying to reprogram his or her system).
I don't think the author of the article has understood what Trusted Computing means at all. He is just talking about thin clients and locked-down systems in school environments, which is not really the same thing.
-- Ed Avis ed@membled.com
If you are really paranoid compile the compiler with a different compiler. Or use a different compiler to compile two linux systems, and only allow logon to one from a remote shell from the second.