<< Chapter < Page Chapter >> Page >

Policies and mechanisms

Policies are real world statements about the protection that the system provides. These are all statements of (significantlydifferent) policies:

  • Users should not be able to read each other's mail
  • No student should be able to see answer keys before they are made public
  • All users should have access to all data.

The various systems in a computer system that control access to resources are the mechanisms that are used to implement apolicy. A good security system is one with clearly stated policy objectives that have been effectively translated into mechanisms.

The fact that data security does not stop with computer security cannot be understated. If your computer is perfectly secure,and an employee photocopies printouts of your new chip design, don't blame the computer security system.

Design principles

Although every security system is different, some overriding principles make sense. Here is a list generated by Saltzer andSchroeder from their experience on MULTICS that remain valid today (these are fun to apply to caper movies - next time you watch Mission Impossible orSneakers or War Games, try to spot the security flaws that let the intruders work their magic):

  • Public Design Surprisingly public designs tend to be more secure than private ones. The reason is that the security community as a while reviewsthem and reports flaws that can be fixed. Even if you take pains to keep the source code of your system secret, you should assume that attackers have accessto your code. The bad guys will share knowledge, the good guys should, too.
  • Default access is no access. This holds for subsystems just like login screens. It sounds like a platitude, but is a principle worth following atall levels. People who need a certain access will let you know about it quickly.
  • Test for current authority Just because the user had the right to perform an operation a millisecond ago doesn't mean they can do it now. Testthe authority every time so that revocation of that authority is meaningful.
  • Give each entity the least privilege required for it to do its job. This may mean creating a bunch of fine-grained privilege levels. The moreprivilege an entity possesses the more costly a mistake or misuse of that entity is. Printer daemons that run as root can cause logins that run as root.
  • Build in security from the start. Adding security later almost never works. There are too many holes to plug, and as a practical mattersecurity is nearly impossible to add to a fundamentally insecure system.
  • In order to make such a design integration, it must be simple and capable of being applied uniformly.
  • The system must be acceptable to the users. All security systems are a compromise between security and usability. The more features a system has,the more likely opportunities there are for exploitation. Furthermore, if a security feature is too onerous to the users, they will just invent ways tocircumvent them. These circumventions are then available for the attackers. An unacceptable security system is automatically attacked from within.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Operating systems. OpenStax CNX. Aug 13, 2009 Download for free at http://cnx.org/content/col10785/1.2
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Operating systems' conversation and receive update notifications?

Ask