How security configurations go bad
With best intentions I set up a demonstrator for a development project on my Windows Home Server (WHS). After a small amount of difficulty that turned out to be due to the version of .NET running on WHS being behind the version I used for development everything was running.
For a while.
After the system works fine at home, I try to demonstrate the system at a conference a few weeks later and the site no longer works. When I get back home I discover that the event log is indicating that the IIS installation does not have the correct access permissions to the directory any more.
Or rather, the event log contains a series of cryptic and peculiar messages from which I am led to deduce that the application failled because it did not have the right access permissions. Granting full access to every authenticated user makes the problem go away.
According to the principle of least privillege this is of course very bad. I should fine tune the system so that only the minimum level of access necessary is granted. But this is simply impossible with the tools provided. The error log does not tell me the user account that made the failed access attempt, not do I know which file it attempted to access. I am left to guess.
The first time around I did the job right and worked out exactly which process I had to give the access to. Since then the WHS has installed a patch that has performed some sort of reset on the security configuration of the server and it no longer works. And so the only way to make sure that the system works in future is to use the big hammer and grant full access to everyone.
As it happens the security exposure in this case is small, only three people have accounts on the machine. But the same sort of thing happens repeatedly with other security configurations. Thus Hallam-Baker's first law of security configuration:
Making the system work will always take priority over making it work securely.
Too many systems are designed to make it possible to configure the system securely rather than making it easy to configure the system securely. For some reason Operating System designers are particularly incapable of designing systems that provide the operator with the information that they need to know to do their job.
Comments
Phillip says:
Since then the WHS has installed a patch that has performed some sort of reset on the security configuration of the server and it no longer works.
Which leads me to ask:
Did they really do such a reset? How did you verify this? Such a reset sounds like an extremely irresponsible thing for a patch provider to do.
Now as for your final comment, that has had me howling at OS developers for years. I can't say the howling has done any good though:(
So this time the question inspired it: what social movement will it take to get OS developers to change their lax attitude and get serious?
Posted by: Matthew Johnson | September 2, 2008 11:14 AM