Building a Good Security System
Imagine that you want to build a perfect security system. The first thing you might do is categorize all of the things that a program can do safely. This list might include writing to a private file that the program has created. You would permit the program to carry out such activities transparently, while other tasks would require some form of user confirmation.
Once you’ve built the system, you try running an application. Immediately, the user is prompted with hundreds of dialog boxes with messages like these:
- This program has just tried to connect to the Internet...
- This program has just tried to access this file...
- This programs has just tried to...
The user clicks OK for all of these messages, and the program runs happily. A little while later, however, another dialog box pops up with a different kind of message: "This program has just tried to modify the kernel’s system call vectors...."
What does the user do? He has been trained by all of the other dialog boxes that clicking OK makes programs work, so he clicks OK. Oh, dear, now a rootkit is installed.
A concrete example of a security system like this is Microsoft’s ActiveX. ActiveX components are basically COM controls—dynamic libraries supporting a well-defined interface. Obviously, you don’t want arbitrary code running on your machine, so Microsoft made sure that ActiveX controls would be loaded only if the user wanted them to be. Every time you visit a web site that contains an ActiveX control, a dialog box pops up with information about that control, and asks you whether you want to run it. The result? Users got used to clicking OK whenever an ActiveX control wanted to run, and a significant amount of malware spread via this mechanism.
Sadly, it seems that Microsoft hasn’t learned from this mistake. Windows Vista (if it’s ever released) is going to feature even more dialog boxes popping up and encouraging the user to click OK to any security-related question.