Page 294 - DCAP103_Principle of operating system

Unit 9: System Security

9.1 Overview Notes

Security systems generally implement a useful subset of a 3-dimentional matrix with dimensions
of actor, object, and action. Implementing the full matrix is never done for both performance
and usability reasons.
Mainstream operating system security is primarily based on access control lists. For each object,
we can maintain a list of actors which may manipulate it.
Capability-based systems, not to be confused with the systems that refer to special administrative
abilities as capabilities, flip things around the other way. For each actor, they maintain a list of
objects upon which the actor may act.

Mainstream operating system security is discretionary. That is, an object owner may decide
who else has access to the object.

Mandatory access control is non-discretionary. A set of rules acts to enforce security, setting
up permissions that users are unable to override. This stops insiders from being effective spies,
selling designs to the competition, sharing medical records with the press, running spyware,
and making many types of user errors.
None of the above methods excludes any other of the above methods. DG/UX has capabilities,
discretionary ACLs, and mandatory access control. Linux provides discretionary ACLs and
several choices for mandatory access control. File descriptors, available on all UNIX-like systems,
can serve as capabilities.

9.1.1 Protection
The first security attempts were protection schemes, which controlled the access of programs to
sensitive areas like the 0 page, where the software interrupts for the operating system calls were
usually stored for efficient calling, or the operating system areas, where the operating system
code was kept while it was running. This capability was required for time-sharing because
neophyte programmers sometimes overwrote the operating system shutting down the whole
computer because they didn’t understand the addressing system. CPU’s like the Z80 began to
be designed to set aside “System” areas so that they couldn’t be overwritten by mistake.
One way of doing this was to create a separate name space for the system and control access
to it. Often the documentation of how to access the protected mode was scant, or missing from
popular books, as an attempt to secure it by obscurity. This turned out to be relatively useless
since it meant that an underground market for information was created, and only the crackers
knew for sure how they were breaking into the operating systems.
Some CPU’s set up complex software interrupts as gateways between the protected mode memory
and the user areas. Each user area had its own software interrupt area, that did a system call to
the protected system area because the interrupt area was within the user space, the interrupt
vectors could be overwritten with impunity, without affecting any other programs use of the
operating system. This was a useful mechanism because peripheral drivers tended to supply
their own interrupt service routines for specific peripherals.

An application like Windows could create a virtualized version of itself, and modify the interrupts
within that one virtual version, without affecting the rest of the operating system. This is usually
what the difference is, between 286 and 386 protective mode, the Virtual copy of windows
with the ability to modify its own interrupt vectors and not affect the rest of the machine. Up
to now until the 386 protected mode, all programs shared the same interrupt vectors and one

LOVELY PROFESSIONAL UNIVERSITY 287