Image Image Image ImageImage
Image
Welcome!
Image
Creative Services for
Image
Roughly Drafted
Image
Daniel Eran
Image
Image
Image
Image
Image Image

Five Architectural Flaws in Windows Solved In Mac OS X
What was intended to be a short aside about Mac OS X's strengths turned into an entire series on Windows NT/2000/XP flaws! Here is the first of five examples of core Windows architectural problems that relate to process management, applications and security.
When writing the second article in the Wishlist for Mac OS X 10.5 Leopard series, I started by comparing ideas Apple that had borrowed from Windows, ideas they could borrow, and areas where Mac OS X was already ahead. The latter begat five articles, of which this is the first.

It is useful to understand why bad ideas are bad. It's also useful to identify how significant and difficult to solve a given problem is. This article tries to give a brief indication of why these design flaws are real and significant issues for Microsoft, and the real world problems they cause for Windows users.

I tried to limit the scope of this article to flaws related to process management and security. I've also separately written another article related to the Windows Registry that I'll be publishing soon. Without further ado, here is:


Flaw 1 - Windows' Interactive Services
Like all Unix distributions, Mac OS X spawns background system processes, called daemons, to handle various tasks. When a user logs into Mac OS X, a special security context is created for that user. Any applications that user launches are started under that user's credentials. Background processes can respond to requests from user-level applications, but they can not initiate any contact with the user, nor present any graphical interface, because they operate in a separate security context.

This is an important security measure that is missing in Windows, which allows for "interactive services." Allowing system processes running as root ("Services running as LocalSystem" in Windows-speak) to present a graphic UI to a logged in user ("become interactive with the desktop") is, to quote an MSDN blogger, a "spectacularly bad idea that should never have been added to the system."

Window's casual mix of security contexts makes it easy for malicious code to jump from the user's limited access realm into the root context, making it easy for a basic exploit to take over the entire machine. Exploiting this Windows-only flaw is called a Shatter Attack.

Three years ago, Microsoft replied to the threat of Shatter Attacks by stating that it was a known problem, and only offering that the inherently insecure and commonly used feature shouldn't be used (while citing earlier documentation that explained how to use it); that it only affected computers where a user could log in, such as a terminal server, or a workstation, or a server allowing logins (boggle!); and that, while a Shatter Attack could own your Terminal Server, it couldn't directly own the network. Of course, there are other security flaws to use once an exploit owns a trusted server.

Microsoft has decided to remove interactive services from Windows Vista (five years after the discovery became widely publicized), but this will break all the Windows services that currently use this insecure mechanism.

As a side note, Mac OS X's security edge over Windows in this example wasn't a product of hindsight; Apple just employed reasonable, known security principles. Shatter Attacks were exposed in 2002, the timeframe of Jaguar, after Apple had completed most of Mac OS X's security policy.

Next:
| | Digg

Flaw 2 - Windows' opaque and illogical file system presentation
Image

More Journal Entries | More Tech Articles | Get Tech Support | My Resume | Links | Contact RoughlyDrafted

 Articles Copyright © 2006 Daniel Eran. All rights reserved.
Suggestions and comments welcome. Contact RoughlyDrafted.
Read more about:
Click one of the links above to display related articles on this page.