Here we're going to
talk about design. Much of what we say applies
to implementation as well. But we're going to focus this
on the higher-level design. So you can see how broadly the principles we talk about
are going to be applied. I'm going to give
you a quick overview of the principles and
the ideas underlying them. Then, we're going to talk
about the principles. These are from Saltzer and
Schroeder's principles as updated by Saltzer and
Kaashoek quite recently. There was one change
that I will talk about because it's a very
interesting change. Now, as a puzzle, Windows and Unix and Linux like systems all have this admin or root user that
effectively is omnipotent, they can do whatever
they like on the system. Dennis Ritchie, one of the
designers of the Unix system, called the existence
of such a user a theoretical flaw as
well as a practical one. Why? I'll give you about 30 seconds to
think this one through. The main problem is that user is simply too powerful. It combines necessary
functionalities, but it combines them all together on one system in one user. What happens if that user
makes a mistake? What happens if
someone breaks into the system and acquires
access to that account? They can do whatever they want. Ideally what should happen are the functionality should be
split up among many users. So if for example I break into the one that controls backups, I still can't affect networking of people on
the system currently. All right. So, let's look
at these design principles. First of all, they have
two themes underlying them. The theme of simplicity and
the theme of restriction. Simplicity is basically well, if it's simple is less
that can go wrong and it's easier to understand. So there are fewer
inconsistencies and I'm more likely to find inconsistencies or problems than if it's very hideously complex. Restriction goes back
to the security rule of try to keep things as
contained as possible. Minimize access,
inhibit communication where communication is not
necessary and so forth.