On 17 Apr 2003, Eric W. Biederman wrote:
Adam Agnew agnew@cs.umd.edu writes:
The one in question is 6,185,678 http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=...)
That was an interesting read. At least I now have an idea of what Bill was thinking of. Most interesting is that there is not a mechanism for the trust to go both ways. In particular how is the loaded code to know it is running on a trusted system.
In addition there are some fundamental things in his description that I would simply not implement as described. Nastily extending DHCP and TFTP when IPsec could be used. And in general I don't think any trust is needed at all of the Network Packets. Just the loaded image needs to carry a signature that can be verified.
A lot of things like that in the description weren't implemented by choice. All we've done is to check elf image signatures so far. I think you'd agree that's the only part that was really necessary towards getting an operating system up in a trusted state. As long as you confine execution to elf images, you can continue to chain along.. As far as etherboot goes, same rules. No need to worry about individual packets. I'm just going to check the signature once it all arrives anyway.
And the description does not address when the system has exploitable bugs. In particular systems like the X-box can be compromised with buffer overflows and other security standard security holes. Allowing an untrusted application to gain special privileges on the machine.
Right, we trust that the components are signed and therefor an authority intended to grant the component permission to run on the machine. It does not mean that we trust the new component not to break the chain of trust, or be bug ridden. Why, we even thought about "trusting" certain closed operating systems!