building secure systems

74
Building Secure Systems Walter Kriha, Computer Science and Media Faculty August 2, 2006 Plattform Security – Isolation, Privileges and Server Security GENERALLY ACCESSIBLE

Upload: stesha

Post on 12-Jan-2016

57 views

Category:

Documents


1 download

DESCRIPTION

GENERALLY ACCESSIBLE. Building Secure Systems. Plattform Security – Isolation, Privileges and Server Security. Walter Kriha, Computer Science and Media Faculty August 2, 2006. Overview: Plattform-level Methods for Secure Systems. Different privilege levels - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Building Secure Systems

Building Secure Systems

Walter Kriha, Computer Science and Media Faculty

August 2, 2006

Plattform Security – Isolation, Privileges and Server Security

GENERALLY ACCESSIBLE

Page 2: Building Secure Systems

Overview: Plattform-level Methods for Secure Systems

Different privilege levels

Isolation of components (virtual memory, micro kernels)

Interception with Wrappers

Virtual Machines

Inversion of Control, Dependency Injection Architectures

Capabilities

Name Spaces, Services and Components

Trusted Computing Bases

Sandboxes

Jails

Funnels

Code Verification

Page 3: Building Secure Systems

Current Problems and Approaches

Page 4: Building Secure Systems

Distributed, after-the-fact security for home computers

Directory

Admins

SMS based code control

MS-Data Center

Security Specialists

PC with tracking SW

PC with tracking SW

report

Analysisupdate

security tools

office home

Page 5: Building Secure Systems

A Sandbox restricts a users rights! It needs a description containing the rules for a specific domain (constrained program). A reference monitor reads those rules. Every access by the code is intercepted by the monitor and the rules are applied. If the rules do not match the intended access it is blocked. No matter how powerful the users rights are, the code cannot escape the sandbox as long as the reference monitor is not bypassed.

The Sandbox (Access Domain)

Program started by user

User A

object

All resources the user has a right to access (ACL)

CODE

object

object Z

service Y

service

service

Sandbox

Reference Monitor

Sandbox Policy:Program X is allowed to use

service Y and Object Z

User rights:

May do everything!

Page 6: Building Secure Systems

Process

Main(string FileName = „foo“)

All Files

Open(fileName)

File named „foo“User has rights for all those files. Process needs the same rights as it does not know which one the user would like to process

Mapping string to resource

Page 7: Building Secure Systems

Process

Main(FileDescriptor) for open file „foo“

Read(FileDescriptor)

User has rights for all those files. Process needs NO rights to open user files. Gets open stream as a capability

„foo“ file

No mapping from string to resource!

Page 8: Building Secure Systems

User F Rechte

Ambient Authority

Server Rechte

Sandbox

Benötigte Rechte für Aufgabe

Page 9: Building Secure Systems

System Architecture and Security Consequences

Page 10: Building Secure Systems

Immutable Laws of Security?

1. If the data hasn’t crossed a trust boundary, you don’t really care about it. 2. If the threat requires that the attacker is ALREADY running code on the client at your privilege level, you don’t really care about it. 3. If your code runs with any elevated privileges (even if your code runs in a restricted svchost instance) you need to be concerned. 4. If your code invalidates assumptions made by other entities, you need to be concerned. 5. If your code listens on the network, you need to be concerned. 6. If your code retrieves information from the internet, you need to be concerned. 7. If your code deals with data that came from a file, you need to be concerned (these last two are the inverses of rule #1). 8. If your code is marked as safe for scripting or safe for initialization, you need to be REALLY concerned.

Page 11: Building Secure Systems

OS-Architecture and Security Mechanisms

Page 12: Building Secure Systems

CPU Protection Levels

Most CPUs offer a simple protetion scheme. Dangerous operations (sensing, control) are only allowed when the CPU has been put in kernel mode (protection bit is set). Applications can NOT change the state of the CPU arbitrarily. They MUST use certain controlled gates (software interrupts) to change the mode. From then on, operating system code runs!

Sensing operations (I/O)

Control operations (halt, memory mgmt.)

Regular compute operations (add, mul)

0/1

State of protected mode bit:

1 = protected/kernel mode

0 = application/user mode

Page 13: Building Secure Systems

Switching to Kernel Mode

Only in kernel mode will the CPU allow critical instructions. The application will be terminated if it tries to execute critical instructions without changing through kernel traps into protected mode.

Application

Kernel Mode, CPU doing critical things

User Mode, CPU doing harmless things System Call Library

Software Interrupt – Kernel Trap(CPU instruction)

C Language Library

Operating System

Hardware (CPU, I/O)

Application stack used

Kernel stack used

Page 14: Building Secure Systems

Security Properties of Privilege Modes

code

code

code code

code

code

codecode

code

code

Rights/Authority

Turn off privileged mode

Attack code on same level

Trick code into extending callers privileges

Page 15: Building Secure Systems

Security Properties of Privilege Modes

1. Rights organized as privilege levels typically lead to ambient authority for code pieces because no sectors are possible within the levels. Most code pieces would need a different segmentation of rights.

2. On the same level each piece of code is a threat to all others (same privileges, no sep.)

3. Every mode change needs to be undone later. Software needs to make sure that on the way back the privilege mode gets reversed to the old value. There cannot be a bypass of this piece of code

4. The mode change needs to be authorized

5. The privileged code needs to interpret arguments carefully to avoid extending the callers privileges in an unwanted way (confused deputy)

Page 16: Building Secure Systems

Address Isolation

256 MBRandom Access Memory

(physical)

000000000000000000000000000000

CPU

32 bit address register

Memory ManagementUnit (MMU)

Same! Virtual Address

Physical Address Process A

page table

Process A

page table

Process B

Application 1: all addresses in same range as app 1.

Application 2: all addresses in same range as every other app.

Physical Address Process B

Page 17: Building Secure Systems

Kernel Functions

Monolithic Kernels

Application 1

Kernel Mode

User Mode

device drivers

memory managment

file management

process management

device driver

firewallmodule

audiodriver

runtime loadable

compiletime

Fast access to functions and shared kernel data

Data

Page 18: Building Secure Systems

MicrokernelsApplication 1

Kernel Mode

User Mode

Clock driver

memory managment server

file management server

process management server

security management server

basic security

basic memory management

Device Driver

Device Driver

Interrupt handling

Context switching

Interprocess comm.

Fast access to functions and shared kernel data

Interprocess Communication or system calls

Page 19: Building Secure Systems

From: G.Heiser, Virtualization of Embedded Systems

Page 20: Building Secure Systems

Armored Monolithic Kernels

Kernel Mode

User Mode

device drivers

memory managment

file management

process management

audiodriver

compiletime

Intercepted and controlled calls to and from kernel

Data

Kernel functions

Wrapper gurantees transactional updates

Data

Temporary Copy of kernel data

Modified page table to restrict driver to certain kernel addresses

Page 21: Building Secure Systems

VM Armored Micro Kernels

Kernel Mode

User Mode

memory managment

file management

process management

Data

Kernel functions

device drivers

VM VM

Inter Kernel Communication

Inter Kernel Communication

Microkernel (e.g. L4)

Page 22: Building Secure Systems

The Secure Extension Problem

Page 23: Building Secure Systems

Extern ProcTab tab;

Extern int criticalFunc()

Init()

Read()

Write()

IOCtrl()

HandleInt()

Driver Controller

driverControl()

ProcTab

criticalFunc()

Kernel Device Driver

Resolved at runtime or linktime

Gobal:

Page 24: Building Secure Systems

private ProcTab tab;

private int criticalFunc()

Init(ProctTab, crit.Function)

Read()

Write()

IOCtrl()

HandleInt()

Driver Controller

driverControl()

ProcTab

criticalFunc()

Kernel Device Driver

Gobal:

criticalFunc()criticalFunc()

Dependency injection

Page 25: Building Secure Systems

• Der Driver kann ausschließlich über die Argumente und deren Methoden auf Kernel-Daten oder Funktionen zugreifen. Es gibt keine andere Möglichkeit, auch nicht durch die Navigation von globalen Verzeichnissen oder durch sog. Composite Objects (Design Pattern), die über ihre Tree-Navigation Zugriffe auf viele andere Objekte gestatten.

• Der Treiber macht eigene Abhängigkeiten und Bedürfnisse im Interface der init-Methode sichtbar: Dort steht, was der Treiber vom Kernel benötigt, um zu funktionieren.

• Der Kernel ist in der Lage, Proxy Objekte oder speziell für den Treiber zugeschnittene Closures (das sind initialisierte higher-order Functions oder deren objektorientiertes Äquivalent bzw. deren Simulationen durch Command Patterns) herzustellen und an den Treiber zu übergeben. Damit kontrolliert der Kernel komplett die Ausführungsumgebung des Drivers.

Page 26: Building Secure Systems

Init(Node)

Read()

Write()

Initiate Call (IOC principle)

Framework Plug-in

Use reference (object capability principle)

Node

NodeNode

Inject dependency (DI principle)

Node does not allow traversal and so plug-in cannot access parent node. The plug-in declares ist dependencies in ist interface

Declare dependency

Page 27: Building Secure Systems

Modes and Privileges

Page 28: Building Secure Systems

Legacy OS

System call Interface

Privileged Utilities

Huge Libraries

Driver

Module Module

Driver Driver

Common Filesystem

Global Administrator

Server

(privileged)Application

Hardware (CPU etc.)

Covered channels (cache, bios, CPU)

Attacks on random number generation

>300 complex system calls

Lots of unverified system libraries with memory leaks etc.

A common, navigable filesystem with ambient authority

Cycle stealing applications create a problem for near-realtime multimedia applications

Tons of unsafe but privileged scripts and utilities (setUid)

Countless dynamically loadable modules

Dangerous accounts, single audit and log features

>100.000 drivers for windows

Incomplete quota administration

Same runtime environment for all applications

Unsafe kernel languages (memory)

Huge TCB, 2 modes only

Network scans (IP seq.)

Page 29: Building Secure Systems

If (uid = 0) {

// do something harmless

}

// run as root now!

Driver.c:

Page 30: Building Secure Systems

Para-virtualisierung

Interprocess communication

Trusted Computing Base

Page 31: Building Secure Systems
Page 32: Building Secure Systems

Rules for Virtualization/Guest Operating Systems

VMs (die gewöhnlich unter privilegierten Accounts arbeiten) sollen wie andere kompromittierbare Dienste behandelt werden, d.h. am Besten unter Verwendung von Isolationstechniken wie chroot, systrace, ACLs, sowie POLA Regeln.

Die Virtuellen Maschinen wie die Gast-Betriebssysteme sollten so schmal wie möglich konfiguriert sein. Ungenutzte Hardware-Treiber oder Services sind auch beim Gast zu entfernen.

Die Integrität der Gastsysteme ist genauso zu sichern wie die der Trägermaschinen durch regelmässige Updates, Privilegieneinschränkungen der Gast-Applikationen etc.

Systeme die mehrere unterschiedliche Privilegienzonen ermöglichen sind vorteilhaft (XEN). Sicherheitslevel von Plattformen (z.B. Berkeley Security Levels) sind zu nutzen. [Orm]

Ressources: Ormandy

Page 33: Building Secure Systems

Software-based Isolation: Singularity

Page 34: Building Secure Systems

Singularity Features

Die Kapselung beruht auf leichtgewichtigen Prozessen

Kernel, Applikationen, Treiber und System-Server sind allesamt Prozesse

Ein Prozess ist ein geschlossener Object-Space, der keine Referenzen in andere Prozesse hinein besitzt

IPC ist durch ein Kanalkonzept realisiert, das sich durch streng typisierte Kommunikation, definiert durch State-Machines, auszeichnet

Objekte können an andere Prozesse übertragen werden, wechseln dann jedoch den Besitzer, so dass keine cross-process synchronization Probleme oder zentrale Garbage Collection nötig sind.

Ein kleiner Teil Code ist unverified und trusted, der große Rest von Microkernel und Applikationen etc. ist verifiably trusted, d.h. er wurde vom sicheren Compiler erzeugt.

Es sind keine dynamischen Erweiterungen von Prozessen (Code laden) erlaubt. Jede Erweiterung muss ein eigener Prozess sein.

Jede Softwarekomponente ist durch Meta-Daten umfangreich beschrieben und wird ohne eigenen Installer installiert.

Page 35: Building Secure Systems

Individual runtimes (GC, libraries)

One virtual address space

Safe interprocess communication (separation)

Small, light-weight processes

No cross object space sharing

p1

p2

Trusted, not verifiably safe

Page 36: Building Secure Systems

Runtime

CLR Lib.

Extension

Code

Runtime

CLR Lib.

Application

Code

Eheap

No common, shared variables between both object spaces

Typed channels with state-machines for IPC

Page 37: Building Secure Systems

public contract NamespaceContract : ServiceContract {

in message Bind(char[] in path, ServiceContract.Exp:Start exp);

out message AckBind();

out message NakBind(ServiceContract.Exp:Start exp);

in message Notify(char[] in pathSpec, NotifyContract.Imp:Start imp);

out message AckNotify();

out message NakNotify(NotifyContract.Imp:Start imp);

in message Find(char[] in pathSpec);

out message AckFind(FindResponse[] in results);

out message NakFind();

out message Success();

override state Start: one {

Success! -> Ready; }

state Ready: one {

Bind? -> ( AckBind! or NakBind! ) -> Ready;

Find? -> ( AckFind! or NakFind! ) -> Ready;

Notify? -> ( AckNotify! or NakNotify! ) -> Ready; }}Als eingebettete Klassen eines Kanals werden jeweils ein exporter bzw. importer definiert, die die entsprechenden Messages des Kontrakts zugeordnet bekommen. Will ein Prozess einen Kanal eröffnen, dann erzeugt er Instanzen von exporter und importer und schickt die exporter-Instanz über einen existierenden Kanal an den Empfänger. Danach können beide miteinander kommunizieren.

Page 38: Building Secure Systems

<manifest>

<application identity="S3Trio64" />

<assemblies>

<assembly filename="S3Trio64.exe" />

<assembly filename="Namespace.Contracts.dll" version="1.0.0.2299„ />

<assembly filename="Io.Contracts.dll" version="1.0.0.2299" /> …..

<assembly filename="ILHelpers.dll" version="1.0.0.2299" />

<assembly filename="Singularity.V1.ill" version="1.0.0.2299" />

</assemblies>

<driverCategory>

<device signature="/pci/03/00/5333/8811" />

<ioMemoryRange baseAddress="0xb8000" rangeLength="0x8000„ fixed="True" />

<ioPortRange baseAddress="0x4ae8" rangeLength="0x2" fixed="True" /> ….

<extension startStateId="3" contractName="Microsoft.Singularity-.Extending.ExtensionContract" endpointEnd="Exp„ assembly="Namespace.Contracts" />

<serviceProvider startStateId="3" contractName="Microsoft-.Singularity.Io.VideoDeviceContract" endpointEnd="Exp„ assembly="Io.Contracts" /> </driverCategory> </manifest>A manifest file describes the physical structure of an application and its installation needs. Control is never passed to the application for installation purposes (no setup.exe)

Page 39: Building Secure Systems

/bin/sshd @ /users/ted (+ {/grp/pathrole})* + /bin/ms/office/word

Compound Principal

Page 40: Building Secure Systems
Page 41: Building Secure Systems

When creating a TRef<T>, the constructor requires an object of type T as an argument. The caller must have ownership of the object at the construction site. After the construction, ownership has been passed to the newly allocated TRef. The Acquire method is used to obtain the contents of a TRef. If the TRef is full, it returns its contents and transfers ownership to the caller of Acquire. Afterwards, the TRef is said to be empty. Release transfers ownership of a T object from the caller to the TRef. Afterwards, the TRef is full. TRefs are thread-safe and Acquire operations block until the TRef is full.

Tracked data structures with ownership transfer

Page 42: Building Secure Systems

Privilege Reduction vs. Capabilities

Page 43: Building Secure Systems

Privilege Restriction and Separation with Rights Reduction vs Capabilities

Root

User

Change owner

change identity to user

Change runtime environment to jail

Subtractive Model

User

Directory

capability

Hand directory capability to unprivileged user process. Without capabilities user process cannot access resources

additive Model (default is deny)

Jails strips off other rights

Page 44: Building Secure Systems

L2

L1

Classic *-properties Vista Integrity Levels

Write-up

Write-down

Read-up

Read-down

L2

L1

Write-up

Write-down

Read-up

Read-down

Vista: Lower level unprotected against upper level attacks. Upper level open to luring attacks and data exposure. Ambient authority through queries and messages

L1

Page 45: Building Secure Systems

Systrace intercepts system calls and evaluates them according to specified policies. By wrapping user shells, applications and daemons most code can be easily sandboxed.

Systrace in OpenBSD

Application

Operating System

open(/tmp/foo, mode);System Call:

wrapper (etc/systrace)

policy_for_application:native_read filename match

„/tmp/*“ then permit

Systrace Interceptor

/etc/systrace (policies)

Page 46: Building Secure Systems

DecreaseMyRights MakeMeAdmin

UserAdmin Rights

ProgramRights

Reduce

Roles etc.

start

User

Admin Rights vector

Program

Rights

Extend

Roles etc.

start

Privilege Starter

Prog.

Admin Rights vector

Privilege Restriction and Separation with Identities or ACLs

start

Page 47: Building Secure Systems

The file is edited in the context of a powerless dummy user and then copied back. The application gets the file via the so called „powerbox“ – a GUI component that distributes capabilities upon user request.

Polaris

Page 48: Building Secure Systems

Windows Operating System

Dummy user session with restricted rights

Real user session

Excel file

With macros

Excel file

With macros

Running Excel program

Polaris

Secure

Desktop

Copy over

Copy back

Running mail program

open attachment

Execute with macros enabled

„Sandbox“

Page 49: Building Secure Systems

Secure Server Design and Reduction of Exposure by Software-Architecture

Page 50: Building Secure Systems

Sicherheitsprinzipien beim Server-Design

• Isolierung der Server-Prozesse durch chroot oder jails

• Server-Prozesse laufen als unprivilegierte User

• Der Zugriff auf die Datenbank sollte minimale Rechte besitzen

• Verschiedene Funktionalitäten sollten auf verschiedene Prozesse verteilt werden

Nach: Maxwell Krohn, Building Secure High-Performance Web Services with OKWS

Page 51: Building Secure Systems

ServerSocket ss = new ServerSocket(port);

for(;;) {

Socket client = ss.accept();

BufferedReader in = new BufferedReader(

new InputStreamReader(client.getInputStream()));

PrintWriter out = new PrintWriter(client.getOutputStream());

while((line = in.readLine()) != null) {

// read command (or filename) from network

// execute command

}

out.print(result);

}David Flanagan, Java Examples in a Nutshell (shortened)

Page 52: Building Secure Systems

OS

Realm

File

Resource

App.

Realm

Company

Realm

VO

Realm

Task1

Network

Resource

Cell

Realm

Task2

technical

administrative

Task oriented

OS

Appl.

DB

DB

Realm

Page 53: Building Secure Systems

Danger of Server Applications

Server sind einfach zu erstellen, bieten aber immer potenzielle Einfallstore für Angreifer.Selbstgebaute Authentisierungen können gefährlich sein.Hohe Rechte für den Server sind gefährlich im Fehlerfall.In den Systemen ist meist viel Ambient Authority verfügbar. Server irren sich bei den Zugriffsrechten (Confused Deputy Problem).Server machen Fehler bei der Umsetzung von Eingabestrings in Ressourcen.Manche Server implementieren sehr verschiedene Funktionen, die es schwierig machen, das gesamte Gefahrenpotential abzuschätzen.Server müssen teilweise privilegierte Operationen ausführen und brauchen daher spezielle Rechte, zumindest für gewisse Zeit. Dies ergibt Angriffsmöglichkeiten.Falls der Aufrufer nicht gegen die Betriebssystem-Registry autorisiert wurde, haben die Betriebssysteme keine Möglichkeit die Aktionen des Servers intern zu kontrollieren.Die Rechte der Aufrufer können weit mehr umfassen, als die Server-Applikation eigentlich benötigen würde. Ohne Sandbox-artige Einschränkung der Server Applikationen existiert auch dadurch Ambient Authority.

Page 54: Building Secure Systems

Server components

„Server“

Process

(execution

Environment)

Service

Code

User

State

All User Data

Page 55: Building Secure Systems

Service Y

User C State

Process

One Process per User- too expensive? (idle users?)

„Server“

Service Y

User B State

Process

Page 56: Building Secure Systems

Service Y

User A State User F State

Process

Process is either single-threaded, event-driven or multithreaded.

One Process per Service.

„Server“

Page 57: Building Secure Systems

Service X

User State

Process

One Process

Many Services

Many User (States)

„Server“

Service Y

User StateUser State

User StateUser State

User StateUser State

User State

Page 58: Building Secure Systems

Memory mapped into Process or Virtual Machine

SAP „Server“

Process

(execution

Environment)

Service X

Code/Data

User A

Session Data

Page 59: Building Secure Systems

SAP VM

Page 60: Building Secure Systems

Authority Restriction with Secure Software Entities

Page 61: Building Secure Systems

DispatcherConfig

ServerLoader

Web

Service ALog Service

Web

Service B

DB

Proxy

DB

Proxy

http requests

Child P.

Child P.

Child ProcessChild process

Child Process

request

Log requestjail

jail

jail

machine

root

Service A partition

Service B

partition

authentication

Page 62: Building Secure Systems

Data in Database

User F data

Service C partition

User A data

Compromised

Process which

Serves

Service C

Page 63: Building Secure Systems

Data in Database

User F data

Service C partition

User A data

Compromised

Process which

Serves

Service C

Page 64: Building Secure Systems

Data in Database

User F data

Service C partition

Data relevant for

User F + Service C

User A data

Data relevant for

User A + Service C

Page 65: Building Secure Systems

Data in Database

User F data

Service C partition

Compromised

Data User F/Serv. C

User A data

Page 66: Building Secure Systems

Database Views to reduce exposure and use backend access control

Table with users and

Services

View for

Service A

View for

Service B

Authorized: Service A

Authorized: Service B

Page 67: Building Secure Systems

Administration and Race Conditions

Root

User

Change owner

change identity to user

Change runtime environment to jail

Jails strips off other rights

Not atomic!

Page 68: Building Secure Systems

Entry

Regeln:

-welche Objekte gehören zu welcher Domain?

-welche Rollen dürfen welche Domäins betreten?

-Zwischen welchen Domains kann ein Übergang (transition) stattfinden? Zwischen welchen Rollen?

-Welchen domains erlauben objekte welche operationen?

Benutzer Identität und Rolle

Domäne

Objekt

Domäne

EntryObjekt

Transition

Kernel prüft!

Page 69: Building Secure Systems

All the resources have an attached ACL which says that user A may access the object. This allows malicious code once started by a user to access and abuse all resources the user has access to.

Malicious Code

Program started by user

User A

object

All resources the user has a right to access (ACL)

CODE

object

object

service

service

service

what the user wanted

what the code did

Page 70: Building Secure Systems

Hardware (e.g. Crypto Processors)

Operating System and Kernel

(Device Drivers, Rights Management)

Application/Server Architecture

(Runtime Authority, Modularity)

Computer Languages and VM‘s

(Type Safety)

Access Rights (Roles or Identity based

Vs. Capability based)

Security Libraries and Frameworks

Principles and Patterns:

• POLA,

• Authority + Designation

• No side-effects

• Closures

• Forced Interceptors

• Usability

Page 71: Building Secure Systems

Threats:

• Buffer Overflow Attack on Server Application (external)

• Administrator rights abuse

• Kernel Network stack vulnerability

• Weak keys in application (e.g. SSO)

• Race condition attack on admin scripts

• shatter attack (windows)

• root-kit placement from CD or DVD

• resource hogging application (cycle stealer)

• Input validation problem in application

• Bad device drivers (stability, malicious code)

Page 72: Building Secure Systems

• Teure Adressraum-Umschaltungen

• Grosse TCBs

• Effiziente IPC

• IO (speziell DMA) nicht virtualisierbar auf manchen Plattformen

• Cache Management (coloring)

• Wenig Privilegien-Schichten auf manchem Plattformen

Page 73: Building Secure Systems

OSGI

Mission Critical Security

OSGI is a first step towards a reliable, type-safe platform for mission critical applications in homes, cars and industries. But it is not perfect: class loaders are a terrible way to achieve isolation. Service management is coarse grained and not expressive enough (e.g. if there are two similiar services available I‘d like number A). The difficulty is to allow the addition or removal of services ANY TIME. Interesting combinations of OSGI and Peer-to-Peer technologies (JXTA) are currently investigated.

• Java Code Security (Protection domain = Codebase, Signature, Principal)

• Added permissions for administration and service management

• Service registry and service interfaces to control export/import and use of services and packages with the help of the class loader

Page 74: Building Secure Systems

Objcect Capabilities

Fine-Grained Authority Reduction

Each application or module gets only as much authority as it needs for the job. This allows safe plug-ins like the renderer for a mail type. From the DARPA browser study (www.combex.org)