Notes on Windows Kernel Security...

Having been the lead architect on more than a few security projects - I can really appreciate the aims of the windows security kernel API.

A token to represent every object in the system. Objects live everywhere, as files, users, domains, et cetera.

But somewhere along the development timeline, vain attempts to obfuscate the true meaning of certain elements were chosen over safe techniques, using provably secure algorithms and clear documentation.

Simply speaking, it became an extreme example of complication with varying true security value. Drivers which run within the kernel are treated as aliens, pretending to be running in restrictions which are entirely fictitious fantasies - leading to insecurities and ultimately more bugs.

Provable security is difficult enough within the computer environment - safe timing, "true" randomness and safe, tested cryptographic algorithms are difficult enough as it is.

Don't get me wrong - the security paradigm of Windows is arguably much better (at least theoretically) than Unix. It's just done very badly.

For example, having to decide if I need a Security Context, a SID, LUID, SecurityUserData, or perhaps an Access token is inane and utter bull. All these types could easily be represented as a single type, with perhaps a non-referenced user-mode handle for safety.

So, for now, I put this down on my " Top Ten Horrors of the Security World."