Level of Access control

Access control works at a number of levels described in
the following:
1. The access control mechanisms, which the usersees at the application level,
may express a very rich and complex security policy. A modern online business could assign staff to one of dozens of different roles, each of which could
initiate some subset ofseveral hundred possible transactions in the system.
Some of these (such as credit card transactions with customers) might require
online authorization from a third party while others (such as refunds) might
require dual control.

2. The applications may be written on top of middleware,such as a database
management system or bookkeeping package, which enforces a number of
protection properties. For example, bookkeeping software may ensure that a
transaction that debits one ledger for a certain amount must credit another
ledger for the same amount.

3. The middleware will use facilities provided by the underlying operating system. Asthis constructs resources such as files and communications portsfrom
lower-level components, it acquires the responsibility for providing ways to
control access to them.

4. Finally, the operating system access controls will usually rely on hardware
features provided by the processor or by associated memory management
hardware. These control which memory addresses a given process can access.
As we work up from the hardware through the operating system and middleware to
the application layer, the controls become progressively more complex and less reliable. Most actual computer frauds involve staff accidentally discovering features of the
application code that they can exploit in an opportunistic way, or just abusing features
of the application that they were trusted not to. But in this chapter, we will focus on the
fundamentals: access control at the hardware and operating system level. (Applicationlevel controls aren’t different in principle, but I leave detailed discussion to Part 2 of
this book.)

As with the other building blocks discussed so far, access control makes sense only
in the context of a protection goal, typically expressed as a security policy. This puts
us at a slight disadvantage when discussing PCs running single-user operating systems
such as DOS and Win95/98, which have no overt security policy: any process can
modify any data. People do have implicit protection goals, though; you don’t expect a shrink-wrap program to trash your hard disk. So an explicit security policy is a good
idea, especially when products support some features that appear to provide protection,
such as login IDs.
I mention one protection technique—sandboxing—later, but leave off a substantial
discussion of viruses and the like to Section 18.4. In what follows, the focus will be on
protection mechanisms for systems that support the isolation of multiple processes. I
discuss operating system mechanisms first, as it is their requirements that usually drive
hardware protection system design.