|Home » Learning Curve
Service Pack 3
Two roads diverged in a Seattle wood.
The following article was first published at radsoft.net on 31 July 2004. It was written in anticipation of the coming hype wave for XP Service Pack 2.
Although the likelihood of a Service Pack 3 is now as then nonexistent, Microsoft do have Vista on the way and some people might be tempted to hope that yes, at long last and after so many failed attempts for so many millennia, they will finally get it right.
But they are not going to get it right - not unless...
[Although the article makes a jab with the famous kernel of Linus Torvalds, the astute reader will note all of the features mentioned are found as well (or in some cases only) in OS X.]
Microsoft readies to leverage its somewhat anticipated new service pack for their flagship operating system Windows XP. The finest software Microsoft have ever released according to swamis Steve Ballmer and Jim Allchin, XP has instead become the laughing stock of the industry. Exploits against its kernel and against its wobbly and hyperactive web browser Internet Explorer and fumbling email client Outlook have only served to 'eXacerbate the Pain'.
Now Microsoft must move. Yes folks, it's do or die for the Redmond juggernaut! What road will they take?
Ars Technica's Wanker Desk [sic] has a review. It's three wide web pages long with numerous screen shots and it can be summed up tidily by no more than the following:
- Firewall protection more obsequious than before.
- Zeroconf for wireless connections.
- Windows Update works differently.
- Internet Explorer blocks popups (sort of, and lamely).
Which all told is - not a lot! It's a matter of making token adjustments to beef up the perimeter while leaving the compound as wide open as ever.
Presuming Microsoft will scramble quickly with Service Pack 3 when the hackers sitting in their underwear several thousand miles away chop it all to pieces in no time flat, what can we expect Chief Software Architect Bill Gates and company to do?
We can expect them to do one of two things.
As any true modicum of security must come from beefing up security inside the compound (and not trying anymore to get ICANN, Vint Cerf, IANA, the CIA, the FBI, the NSA, Hercule Poirot, the French Surete, Q, M, MI6, Miss Moneypenny, the KGB, the members of Echelon, the Jedi, the League of Extraordinary Gentlemen, and the secret police of the Maldives to change the entire Internet just because one vendor can't cut it), there remains a list of places where things obviously could be better - and methods to obviously make them better.
- Make the entire OS kernel open source.
- Simplify the permissions system. Make it eminently accessible and obsequious.
- Give files ownership. Make them belong to groups.
- Give the most important and sensitive files to the system.
- Distinguish between access rights for file owners, group members, and others.
- Give directories similar protection.
- Batten down system areas tight.
- Give each user their own 'Program Files' area. Only system modules should be global. Add-on or third party software should never enter a system area.
- Scrap Visual Basic as its weaknesses force the system as a whole to be weak.
- Do not allow use of system modules by other than a superuser or administrator.
- Do not allow directory modifications to system areas. This means files in these areas may not be modified or deleted, nor can they be renamed, nor can new files be added.
- Unbuckle the Registry. Make it XML-based and split it up into system defaults, local network defaults, local machine defaults, and user-specific defaults. Split it further per function and per application to minimise system vulnerability. Place the new files at strategic places. Do not let users modify system defaults, but let their own defaults override them.
- Scrap the entire CLSID and Interface systems. Getting rid of these makes the system more stable and gives lurkers less chance of hiding.
- Do not allow application startups from other than system areas and do not allow modification by other than a superuser.
- Allow only proprietary login and place each user in a proprietary area. Allow the user to specifically close off this area to all other users except the superuser.
- Do not give ordinary users administration privileges. Make the user who sets up the machine an administrator, but disable the superuser account. Allow privilege escalation to superuser status temporarily only - and only through authentication.
- Do not allow the superuser to access the Internet. Do not allow privilege escalation while connected to the Internet.
- Do not allow 'safe mode' and Internet connectivity simultaneously.
- Have clear text policies about who can do what and who can escalate to what and when. Allow administrators to view these policies, but allow only the superuser to modify them.
- Do not allow dynamic privilege escalation through code. Allow privilege escalation only through file permissions and regulated authentication.
- Make sure no files on the system are writable by everybody.
- Make sure no accounts not in use are enabled. Set up a new system with only one account enabled: that of the administrator (and not the superuser). Have this administrator automatically create a lesser privileged account for Internet connectivity. Disallow, if possible, Internet connectivity through the administrator account or reversion to the administrator account while connected to the Internet.
- Establish an on-disk security system: if a file is owned by the superuser, then only the superuser can run that file, look at that file, modify, delete, or rename that file. Most importantly, program files may only be run by their owners or by members of their group, and group rights extend only if the owners specifically permit it.
- Only the owner of a file system object may change its permissions.
- Establish a routine for auditing the system regularly for proper file privileges, changes to system settings, addition of bogus files, et al.
- Do not allow resolution of web links in the email client that replaces Outlook. Make plain text email the default and store email messages in plain text format and not the gobbledegook presently used.
- Scrap COM and DCOM completely as they represent more than half the woes Windows has today. (Yes, this means OLE2/ActiveX is gone too - isn't it about time?)
- Rewrite the GDI in C. It should never have been written in C++ in the first place. That was very stupid. And it took a dork like Bill Gates to give the go-ahead. And it is because of these linguistic underpinnings the GDI is the weakest part of the kernel. Fire the team (the 'Undead') that came up with this silly idea. Their team leader spent more time trying to break the bank in Atlantic City than writing good code - give him a one-way ticket to Atlantic City.
- Migrate the Win32 subsystem back out of the kernel. Accept the performance write-off - see below.
- To accomplish the above, scrap the shell namespace so Windows Explorer can list a directory in less than half a day without crutches like the (now invisible) shell icon cache.
- Fire the current Internet Explorer team. Fire the Outlook team too. They're worse than the old Soviet nuclear scientists. They cheat to impress the higher-ups.
- Revamp the shell so it doesn't do things in 16-bit mode anymore. Do not allow 'mangled' file names anywhere.
- Revamp the file system so there's better security right on the disk. Allow only one file system, and make that a secure file system.
- Start showing people where their desktop folder really is and give every user their own desktop folder in their own proprietary home area.
- Stop pretending Control Panel is part of a file hierarchy. It's system settings and no more. Stop being pretentious. Stop playing games. Stop being stupid.
- Take all similar entities - printer settings et al - out of any semblance of belonging to a 'folder hierarchy'.
- Stop using drive letters. What a stupid system. It might have been OK thirty years ago with experimental machines but it's not OK anymore.
Release Microsoft Linux.