Last week, Redmond's hardware security flying circus arrived in the UK and I had an opportunity to attend a briefing on NGSCB (or even as MS techies still call it, Palladium). I didn't take a notepad with me, but as it seems to have been a standard presentation, its details can be found, for instance at cap-talk mailing list.

Looking at diagrams during the meeting, it struck me how similar the concept of separation of trusted/untrusted resources and kernel modules is to something like type enforcement implemented in Security-Enhanced Linux.

Other thing that came to my mind during the meeting was that although Palladium provides opportunity to improve overall system security, it is unlikely that initial release of Longhorn (in which it will be built-in) all security holes will magically disappear. There are two resons for that - legacy applications and software development practices. Legacy software living on top of the O/S from Redmond would have to be rewritten to use new security APIs. As rewriting software is not something that is generally economically rewarding, it is unlikely this will happen at large scale.

The second reason is that Palladium will not protect anyone from bad programming practices. The new Windows release will provide secure, backwards compatible APIs plus new, secure, Palladium-esque APIs. My unsubstantiated guess is that developers will frequenly need to use both trusted and untrusted APIs and all other factors remaining same, unless they know how to do it properly, resulting applications will not be neccessarily more secure.

So it seems that the observation that security is a process and not a product still holds true and Palladium is not the silver (or not even platinum) bullet for our security problems.

7:42:08 PM