This is really more about robust computing than safe computing per se, but of course the one is pretty much a prerequisite for the other.
The excellent Susan Bradley recently pointed out this interesting blog post, describing one of the many ways in which a careless or misinformed administrator can break Windows. In short, one of the built-in operating system services had been reconfigured to use a different security context than the one it was supposed to. The only way the problem was identified was by comparing the entire registry to that of a clean system, and, presumably, hand-picking through the huge number of irrelevant differences to identify the relevant one.
Now, David is certainly correct in saying that changing the security context in which a built-in service runs in is a bad idea, but he doesn’t ask the obvious question: why the heck can you make such a change in the first place?
Answer: because the service configuration, including the security context, is stored in the Windows registry. And anything that’s stored in the registry can be changed, whether it should be configurable or not.
All together now: This Is A Bad Idea.
The registry isn’t the only part of Windows that has too darn many “moving parts”, however. I’ve just completed a basic Windows 7 installation on a virtual machine, and it has over 32,000 files. That’s before installing any applications, mind you.
Now, Windows isn’t as vulnerable to loss of system files as it used to be, but that’s mostly because of mechanisms that make it harder for a file to be improperly removed or modified and help repair damage if it does occur. This is better than nothing, but it isn’t a good solution. A good solution would be to have fewer separate files in the first place.
For the record, Unix operating systems (including Mac OS X) don’t have a registry, but they do have too darn many files, just like Windows.
So how many files is too many? The obvious answer here is “two” but I think that would be taking a good idea more than a bit too far!
Ideally, the OS itself would indeed be contained in but a single file with a digital signature. As well as the code, this would include the default settings for everything that is configurable. In addition to reducing the number of moving parts, this would make it a whole lot easier for external security tools to check for any tampering with the OS.
Local configuration settings – any setting which has actually been configured – would be in another file. It would probably also be sensible to keep backup copies of this file to allow a previous configuration to be easily restored.
Any device drivers not included in the base OS would take up one file apiece, as would installed applications. Similar to the OS, each of these would have a corresponding configuration file containing any non-default settings.
Finally, depending on the hardware one or more additional files might be necessary for the boot process, virtual memory and hibernation support. Oh, and I guess the user might want to save some files too. 🙂
OK, so much for the file system. Going back to the registry, I should admit that making almost everything configurable isn’t a completely silly idea: it allows for very flexible troubleshooting, which is valuable. To accommodate that, we should ensure that configuration settings (for the OS, the device drivers, and applications) are stored in a manner that allows there to be lots of different settings with a structured namespace, and that is easy for the programmer to access.
In other words, something very much like the Windows registry. However, there are a few critical points that need to be kept in mind: first and foremost, the system must always know what the default value is for any setting; secondly, it must be easy to enumerate those settings which have been configured [*]; and finally, there must be a separation of domains, so that (for example) a third-party application can’t change the OS settings but only its own.
Additionally, there should be a clear distinction between settings which are normally changed and those which are not, so that it is easy to enumerate abnormal settings. If the Windows registry provided this functionality, the Case of the Mysterious Access Denied could have been solved almost straight away, because this would be one of the very first things any trouble-shooter would check. This should perhaps be a sliding scale, starting with settings that have to be defined (the timezone, perhaps) and moving on to settings that are usually defined, those that are uncommon but supported, and through to settings intended only for advanced troubleshooting performed under expert advice.
It would also be preferable if it were not possible to (unintentionally) configure a setting which does not exist or configure a setting to a syntactically meaningless value.
[*] As a minor point of fine-tuning, note that there is a distinction between a setting which is not configured, and one which is configured but happens to be equal to the default value.