Transcript Lecture 4 - Nipissing University Word

Lecture 4
Security Mechanisms
1
Security Mechanisms
 How
can computer systems enforce operational
policies in practice?
 You have to answer the following questions:
 Where should access control be located?
(Second Fundamental Design Decision)
 Are there any additional security
requirements your solution forces you to
consider?
2
Content
Historic examples, to keep matters simple
 Reference monitor, security kernel, and
TCB
 Status information & controlled invocation
 Security features in microprocessors
 Memory management and access control
 Hand-off (delegation, impersonation)
 Reflection, and in-line reference monitors

3
Important Concepts
(TCSEC)
Reference monitor: access control concept
that refers to an abstract machine that
mediates all accesses to objects by subjects.
 Security Kernel: The hardware, firmware,
and software elements of a TCB that
implement the reference monitor concept. It
must mediate all accesses, be protected
from modification, and be verifiable as
correct
 Trusted Computer System Evaluation Criteria
(TCSEC).

4
Trusted Computing Base
(TCB)

5
The totality of protection mechanisms within a
computer system - including hardware, firmware,
and software - the combination of which is
responsible for enforcing a security policy. A TCB
consists of one or more components that together
enforce a unified security policy over a product or
system. The ability of the TCB to correctly enforce a
security policy depends solely on the mechanisms
within the TCB and on the correct input by system
administrative personnel of parameters (e.g., a
user’s clearance) related to the security policy.
Operating System (O/S)
Integrity




6
Assume that your O/S prevents unauthorized access
to resources (as long as it works as intended).
To bypass the protection mechanisms, an attacker
may try to disable the security controls by modifying
the O/S. You now face an integrity problem, even if
your original concern was confidentiality. The O/S is
not only the arbitrator of access requests, it is itself an
object of access control.
New security policy: Users must not be able to
modify the operating system.
This is a generic security policy, needing strong and
efficient support.
Operating System
Integrity



7
To make life more complicated, you have to address
two competing requirements.
 Users should be able to use (invoke) the O/S.
 Users should not be able to misuse the O/S.
Two important concepts commonly used to achieve
these goals are:
 status information
 controlled invocation, also called restricted
privilege
These concepts can be used in any layer of a
computing system, such as application software,
operating system, or hardware.
Modes of Operation



8
To protect itself, an O/S must be able to distinguish
computations ‘on behalf’ of the O/S from computations ‘on
behalf’ of a user.
A status flag allows the system to work in different modes.
 Motorola 68000: one status bit to distinguish between
user mode and supervisor (system) mode
 Intel 80x86: two status bits and four modes
 Unix distinguishes between user and superuser (root)
Why are such modes useful? For example, to stop users
from writing directly to memory and corrupting the logical
file structure, the O/S could grant write access to memory
locations only if the processor is in supervisor mode.
Controlled Invocation




9
We continue our example. A user wants to execute an
operation requiring supervisor mode, e.g. write to memory.
To deal with this request, the processor has to switch
between modes, but how should this switch be performed?
Simply changing the status bit to supervisor mode would
give all privileges associated with this mode to the user
without any control on what the user actually does.
Therefore, the system should only perform a predefined set
of operations in supervisor mode and then return to user
mode before handing control back to the user. We refer to
this process as controlled invocation.
Core Security Mechanisms
applications
services
operating system
OS kernel
hardware
10
Why Mechanisms at the
Core?
For security evaluation at a higher level of assurance.
Security mechanisms in a given layer can be compromised
from a layer below. To evaluate security, you must check
that security mechanisms cannot be bypassed. The more
complex a system, the more difficult this check becomes.
At the core of a system you may find simple structures
which are amenable to thorough analysis.
 Putting security mechanisms into the core of the system
can reduce performance overheads caused by security.
Processor performance depends on the right choice and
efficient implementation of a generic set of operations that
is most useful to the majority of users. The same holds for
security mechanisms.
 Note: Some sources assume that TCBs and security
11kernels must enforce multi-level security policies.

Computer Architecture

For our purpose, a simple schematic description of a
computer will do. We have
a
central processing unit (CPU)
 memory
 a bus connecting CPU and memory
 input/output devices
I/O
12
CPU
Bus
Memory
Core CPU Components


13
Registers: general purpose registers and dedicated
registers like
 program counter: points to the memory location
containing the next instruction to be executed
 stack pointer: points to the top of the system
stack
 status register: allows the CPU to keep essential
state information
Arithmetic Logic Unit (ALU): executes instructions
given in a machine language; executing an
instruction may also set bits in the status register.
Processes and Threads




14
Process: a program in execution, consisting of executable
code, data, and the execution context, e.g. the contents of
certain CPU registers.
A process works in its own address space and
communicates with other processes only through O/S
primitives. The logical separation between processes is a
useful basis for security. However, a context switch
between processes can be an expensive operation.
Threads: strands of execution within a process. Threads
share an address space to avoid the overheads of a full
context switch, but they also avoid potential security
controls.
Processes and threads are important units of control for
the O/S, and for security. They are the ‘subjects’ of access
control.
System Stack
 System
stack: A specially designated part of
memory containing return address, local
variables and function arguments.
 The stack can be accessed by pushing data on
its top or by popping data from its top
 Beware of the dangers of abstraction. In an
abstract discussion it is reasonable to assume
that the size of the stack is unlimited. An actual
implementation, however, could well allocate a
fixed memory section for the stack. If the stack is
allowed to grow beyond its maximal size,
security problems can occur.
15
Memory Structures
The security characteristics of different types of memory:




16
RAM (random access memory): read/write memory; no
guarantees for integrity and confidentiality
ROM (read-only memory): provides integrity, does not
guarantee confidentiality; ROM could store (part of) the
O/S
EPROM (erasable & programmable read-only memory):
could store parts of the O/S or cryptographic keys;
technologically more sophisticated attacks threaten
security
WROM (write-once memory): memory contents are
frozen once and for all, e.g. by blowing a fuse placed on
the write line; WROM could hold cryptographic keys or
audit logs
Memory Structures



17
Volatile memory loses its contents when power is
switched off. To be precise, memory contents degrade
and may still be present after a short power loss and
can be reconstructed by special electronic techniques if
power has been switched off for some time. To counter
such attacks, memory has to be overwritten repeatedly
with suitable bit patterns.
Non-volatile (permanent) memory keeps its content
when power is switched off. If attackers have direct
access to memory bypassing the CPU, cryptographic or
physical measures are needed to protect sensitive data.
For example, a light sensor in a tamper resistant
module may detect an attempted manipulation and
trigger the deletion of the data kept in the module.
Traps - Interrupts
The CPU deals with interruptions of executions, created by
errors in the program, user requests, hardware failure, etc.,
through mechanisms called exceptions, interrupts, and
traps. These terms refer to different types of events, but as
ever there are competing classifications. We use trap as the
generic term.
 A trap is a special input to the CPU, which includes an
address (interrupt vector) in an interrupt vector table giving
the location of the program (interrupt handler) which deals
with the condition specified in the trap.
 When a trap occurs, the CPU saves its current state on the
stack and then executes the interrupt handler. In this way,
control is taken away from the user. The interrupt handler
has to restore the CPU to a proper state, e.g. by clearing the
supervisor status bit, before returning control to the user.
18

Interrupt Vectors
Interrupt
Interrupt vector table
Memory
TRAP #n
Interrupt vector
Interrupt
handler
19
Interrupting Interrupts



20
A further interrupt may arrive while the CPU deals with a
current interrupt, so the CPU may have to interrupt the
current interrupt handler.
Improper handling of such a situation can cause security
failures. Consider a system where a user can interrupt
the execution of a program by typing CTRL-C so that
the CPU returns to the O/S prompt with the status bit of
the current process. A user could then enter supervisor
mode by interrupting the execution of an O/S call.
The interrupt table is a particularly interesting point of
attack and has to be protected adequately. Redirecting
pointers is a very efficient way of compromising the
integrity of the O/S.
Example 1: Motorola
68000



21
16-bit status register: the top section, the system byte,
contains bits relevant for security controls.
 S: supervisor bit, two modes
 T: trace bit, exception raised after each instruction
 I2I1I0: interrupt level number
After a reset, the 68000 always boots in supervisor
mode. Once the S bit has been set to 0, it can only be
set to 1 by a TRAP #n instruction. The operand #n
gives the exception (interrupt) vector. The S bit is reset
by the RTE instruction.
There are seven levels of interrupt priorities. Interrupts
can be masked: interrupts with a higher priority will not
be interrupted by a low priority interrupt.
Memory Management


22
Memory mapped I/O treats memory and input/output
devices in a unified manner.
The function codes FC2, FC1, FC0 indicate the
processor status so that the address decoder may
select between user and supervisor memory or
between data and programs.
FC2 FC1 FC0
0
0
0
0
0
1
0
1
0
0
1
1
1
0
0
1
0
1
1
1
0
1
1
1
(undefined,reserved)
user data
user program
(undefined,reserved)
(undefined,reserved)
supervisor data
supervisor program
interrupt acknowledge
General Lessons
23

The ability to distinguish between data and
programs is a useful security feature, providing a
basis for protecting programs from modification.

From a more abstract point of view, memory has
been divided into different regions. Access
control can then refer to the location a data
object or program comes from.

This can serve as a first example for location
based access control. Distributed systems or
computer networks may use location based
access control at the level of network nodes.
Example 2: Intel 80x86
Support for access control at machine language level is
based on protection rings.
 A two-bit field in the status register defines four privilege
levels. Unix, Windows 2000 use levels 0 (O/S) and 3 (user).
 Privilege levels can only be changed through the POPF
command.
 Processes can only access objects in their ring or in outer
rings. Processes can invoke subroutines only within their
ring. Processes need gates to execute procedures in an
inner ring.
 Information about system objects like memory segments,
access control tables, or gates is stored in descriptors. The
privilege level of an object is stored in the DPL field of its
descriptor.
24

Intel 80x86 - Access Control

Descriptors are held in the descriptor table and are
accessed via selectors. A selector is a 16-bit field
containing an index for the object’s entry in the descriptor
table and a requested privilege level (RPL) field. Only the
O/S has access to selectors.
INDEX
Descriptor DPL
RPL
selector
Descriptor table
Current privilege level (CPL): the code segment register
stores the selector of the current process. Access control
decisions can be made by comparing CPL (subject) and
25 DPL (object).

Intel 80x86 - Controlled Invocation


Gate: a system object that points to a procedure,
where the gate has a privilege level different from
that of the procedure it points to.
Gates allow execute-only access to procedures in
an inner ring.
outer ring procedure
Gate
inner ring procedure
26
Intel 80x86 - Controlled
Invocation


27
A subroutine call saves state information about the
calling process and the return address on the stack.
 Should this stack be in the inner ring? Violates
the security policy forbidding write to an inner
ring.
 Should this stack be in the outer ring? The return
address could be manipulated from the outer ring.
Therefore, part of the stack (how much is described
in the gate’s descriptor) is copied to a more
privileged stack segment.
A Loophole?



28
When invoking a subroutine through a gate, the CPL
changes to the level of the code the gate is pointing to.
On returning from the subroutine, the CPL is restored to
that of the calling process.
The outer-ring process may now ask the inner-ring
procedure to copy an object residing in the inner ring to
the outer ring. This will not be prevented by any of the
mechanisms presented so far, nor does it actually violate
the stated security policy.
To take into account the level of the calling process, use
the adjust privilege level (ARPL) instruction. This
instruction changes the RPL fields of all selectors to the
CPL of the calling process. The system then compares
the RPL (in the selector) and the DPL (in the descriptor) of
an object when making access control decisions.
Comparing RPL and
DPL
Descriptor table
selector
INDEX
Descriptor DPL
?
=
29
RPL
Security Mechanisms in
O/S



30
O/S manage access to data and resources. Multitasking
O/S interleave the execution of processes belonging to
different users. They have to
 separate user space from O/S space
 logically separate users
 restrict the memory objects a process can access
Logical separation of users can take place at two levels:
 file management, deals with logical memory objects
 memory management, deals with physical memory
objects
For security, this distinction is important.
Segments and Pages


31
Segmentation divides memory into logical units of
variable lengths.
+ A division into logical units is a good basis for
enforcing a security policy.
 Units
of variable length make memory
management more difficult.
Paging divides memory into pages of equal length.
+ Fixed length units allow efficient memory
management.
 Paging is not a good basis for access control as
pages are not logical units. One page may
contain objects requiring different protection.
Page faults can create a covert channel.
A Covert Channel




32
When a process makes access to a logical object
stored on more than one page, a page fault occurs
whenever a new page is requested.
A covert channel exists if page faults can be observed.
Consider a password scheme where the password
entered is compared character by character with the
reference password stored in memory. Access is denied
the moment an incorrect match is found.
If a password is stored across a page boundary, then
observing a page fault indicates that the piece of the
password on the first page has been guessed correctly.
If the attacker can control where the password is stored
on the page, password guessing becomes rather easy.
Exploiting the Covert
Channel
Page 1
TENEX
For PDP-11
Page 2
P ASSWORD
PA SSWORD
PAS SWORD
PASS WORD
1st guess
2nd guess
3rd guess
4th guess
…
33
http://www.securitytechnique.com/1/8
Memory Protection

34
The O/S has to control access to data objects in
memory. A data object is physically given by a collection
of bits stored in certain memory locations. Access to a
logical object is ultimately translated into access
operations at machine language level. At this level, you
can pursue three options for controlling access to
memory locations,
 the operating system modifies the addresses it
receives from user processes
 the operating system constructs the effective
addresses from relative addresses it receives from
user processes
 the operating system checks whether the addresses it
receives from user processes are within given bounds
Address Sandboxing
(Modification)


Address consists of a segment identifier and an offset.
When the operating system receives an address, it sets
the correct segment identifier as follows:
A bitwise AND of the address with mask_1 clears the
segment identifier; then a bitwise OR with mask_2 sets
the segment identifier to the intended value SEG_ID
address seg_id
offset
mask_1
0....0
1….1
0….0
offset
mask_2 SEG_ID
0….0
effective address SEG_ID
35
offset
} bitwise AND
} bitwise OR
Relative Addressing


Clever use of addressing modes can keep processes out
of forbidden memory areas.
Fence registers: base register addressing keeps users out
of O/S space; fence register points to top of user space.
memory
offset
user space
base
O/S space
fence register
+
Bounds register define the bottom of the user space. Base
and bounds registers allow to separate program from data
space.
 Tagged architectures indicate the type of each memory
36 object.

Process Management






37
During execution, a process can create new child
processes (threads), maybe on a different machine
(Remote Procedure Call)
The child has to be given access rights (privileges) to
be able to do its work
In an O/S where the privileges of a process are
derived from the ‘identity (uid)’ it is running under, the
parent could delegate its identity to the child
In Windows, this step is called impersonation
Delegation has many meanings, hand-off is a more
neutral term
As an alternative, the child asserts its privileges, e.g.
with SUID programs in Unix
Delegation



38
Alice delegates (grants) to Bob the right to use one
of her resources: put this access right into an ACL
 It depends on policy whether Bob can delegate
this right to another user; Alice can manage her
own ACL
Alice ‘delegates her identity (uid)’ to a process
(subject) running in a computer system
 It depends on policy whether the process can
delegate her uid to other processes, but usually it
is not an option to ask Alice
Treating delegation between principals and
delegation between subjects in the same way is a
recipe for confusion
Logical Protection in ‘Real’ O/S
 For
each O/S, find out:
 What
are the subjects?
 What are the objects?
 Which access control structures are used?
 What are the rules for evaluating the access
control structures?
 What are the main issues when mapping an
organisational security policy into an
automated security policy?
39
Logical Protection at
the Application Level
 Can
be implemented by placing a reference
monitor ‘in front of’ the component to be
protected. Instead of calling the component
directly, other components have to call the
reference monitor (wrapper) first.
 Wrappers in Unix (more in a moment)
 Reflection in object-oriented systems
40
Reflection
meta object
1
invocation
view of
client
client
return value
1.
2.
3.
4.
41
4 2
3
object
Call reflected to meta object, which performs
security checks
Meta object passes control to object
Object performs its computation and returns value
to meta object
Meta object performs further checks before
retuning value to client
Current trends
 ‘Open’
e-commerce systems move from
identity-based access control towards codebased access control
 Access operations move from simple
read/write instructions to applets
 Expressiveness of rules moves from ACLs to
assertion languages ( trust management)
 Location of rules moves to decentralized
systems using certificates/credentials
 Compliance checking may delegate evidence
evaluation to other parties
42
Summary
Reference monitor, security kernel, and TCB
 Status information & controlled invocation
 Security features in microprocessors
(Motorola 68000 & 80X86)
 Memory management and access control
 Process management (delegation,
impersonation)
 Reflection (Object systems)

43