Download A Pattern Language for Secure Operating System Architectures

Secure Operating System
Architectures Patterns
Secure Systems Research Group - FAU
Security and operating systems (OS)
• OS act as an intermediary between the user of a
computer and its hardware
• OS supports the execution of all the applications
• The OS architecture is fundamental in the
organization its components and for utilization of
these component services in a given application
• It is the most critical of the software layers because
compromise can affect all applications and
persistent data
• Most reported attacks occur through the OS
Secure Systems Research Group - FAU
OS architectures
•
Patterns representing an abstract view of
the four basic architectures of operating
systems:
1) Modular Operating System Architecture
2) Layered Operating System Architecture
3) Microkernel Operating System
Architecture
4) Virtual Machine (VM) Operating System
Architecture
Secure Systems Research Group - FAU
Operating System Architectures
Can be combined
Layered Modular
Operating
System Architecture
Modular Operating
System Architecture
Can run
Can be combined
Can be combined
Layered Operating
System Architecture
Layered Microkernel
Operating
System Architecture
Can be combined
Secure Systems Research Group - FAU
Can run
Can run
Microkernel Operating
System Architecture
Virtual Machine
Operating
System Architecture
OS functional components
•
•
•
•
•
•
•
Process Management
Memory Management
File Management
I/O Management
Networking
Protection System
User Interface
Secure Systems Research Group - FAU
Object-oriented model of OS Components
OS
1
1
ProcessMgmt
1
1
StorageMgmt
ProcessLife
createProcess
destroyProcess
security
UserInterface
1
1
1
I/OMgmt
1
1
ProcessSchedule
MemoryMgmt
MassStorageMgmt
assignProcess
dispatch
allocate
deallocate
protect
allocate
deallocate
NetworkingMgmt
connect
disconnect
communicate
security
1
1
ProcessComm
communication
sychronization
FileMgmt
create
delete
open
security
1
DeviceI/OMgmt
*
DeviceDriver
Secure Systems Research Group - FAU
Modular Operating System
Architecture
• Example
– Our group is building a new OS that should support various types of
devices requiring dynamic services with a large variety of security
requirements. We want to dynamically add OS components,
functions, and services, as well as tailor their security aspects
according to the type of application. For example, a media player
may require support to prevent copying of the contents. Or we
could remove a module for which a vulnerability alert has been
issued.
•
Context
– Operating systems are large systems that must accommodate a
variety of diverse applications.
• Problem
– We need to be able to add/ remove functions in the easiest way.
How do we structure the functions for this purpose?
Secure Systems Research Group - FAU
Modular Operating System
Architecture
• The possible solution is constrained by the
following forces:
– OSs for PCs and other types of uses require a large variety of
plug-ins. New plug-ins appear frequently and we need the ability
to add and remove them without disrupting normal operation.
– Some of the plug-ins may contain malware, we need to isolate
their execution so they do not affect other processes.
– We would like to hide security-critical modules from other modules
to avoid possible attacks.
– Modules can call each other, which is a possible source of
attacks.
Secure Systems Research Group - FAU
The Modular Operating System
Architecture pattern
• An object oriented approach is used to
dynamically load and link loadable
modules to the core component of the OS
LoadedModule
Can call
*
LoadableModule
*
Secure Systems Research Group - FAU
*
1
KernelCore
Solaris 10 Operating System
device and
bus drivers
scheduling
classes
file systems
core Solaris
kernel
miscellaneous
modules
STREAMS
modules
Secure Systems Research Group - FAU
executable
formats
loadable
System calls
Solaris 10 Operating System
Secure Systems Research Group - FAU
Modular Operating System
Architecture
•
•
Advantages:
– Flexibility to add/ remove functions contributes to security in that we
can add new versions of modules with better security.
– Each module is separate and communicates with other modules
over known interfaces. We can introduce controls in these
interfaces.
– It is possible to partially hide critical modules by loading them only
when needed and removing them after use.
– By giving each executing module its own address space we can
isolate the effects of a rogue module.
Liabilities:
– Any module can see all the others and potentially interfere with
their execution.
– Uniformity of call interfaces between modules makes it difficult to
apply stronger security restrictions to critical modules.
Secure Systems Research Group - FAU
Modular Operating System
Architecture
• Known uses
– Solaris version 10
– ExtremeWare from Extreme Networks
[Ext].
• Related patterns
– The Controlled Execution Environment
pattern [Fer0] can be used to isolate
executing modules.
Secure Systems Research Group - FAU
Layered Operating System
Architecture
• Separate the OS into layers
• OS has more control over separation of
concerns
• Overall features and functionality are
separated into layers
• Clearly defined interfaces between each
kernel section of the OS and between user
applications and the OS functions
Secure Systems Research Group - FAU
Layered Operating System
Architecture
• Example
– Our system is very complex and we would like to
separate different aspects to handle them in a more
systematic way. We want to control the use of OS
components and services.
•
Context
– Operating systems are large systems that must
accommodate a variety of applications.
• Problem
– Structure the components into hierarchical layers.
Secure Systems Research Group - FAU
Layered Operating System
Architecture
• The possible solution is constrained by the
following forces:
– Interfaces should be stable and well defined. Going through any interface
could imply authorization checks.
– Parts of the system should be exchangeable or removable without
affecting the rest of the system. For example, we could have modules that
perform more security checks than others.
– Similar responsibilities should be grouped to help understandability and
maintainability. This contributes indirectly to improve security.
– We should control module visibility to avoid possible attacks from other
modules
– Complex components need further decomposition. This makes the design
simpler and clearer and also improves security.
Secure Systems Research Group - FAU
Layered Operating System
Architecture Pattern
• Define a hierarchical set of layers and
assign components to each layer. Each
layer presents an abstract machine to the
layer above it.
Secure Systems Research Group - FAU
Layered Operating System
Architecture Pattern
Client
<<uses>>
LayerN
1
LayerN-1
.
.
.
1
Layer2
1
Layer1
Secure Systems Research Group - FAU
Layered Operating System
Architecture Pattern Dynamics
• Sequence diagram for opening and reading a disk file
<<actor>>
aUser:
:OSInterface
:FileManager
openFile(…)
openFile(…)
readDisk(…)
•A user sends an openFile( ) request to the OSInterface
•The OSInterface interprets the openFile( ) request
•The openFile( ) request is sent from the OSInterface to the FileManager
•The FileManager sends readDisk( ) request to the DiskDriver
Secure Systems Research Group - FAU
:DiskDriver
Layered Operating System
Architecture
• Implementation –
– List all units in the system and define their dependencies.
– Assign units to levels such that units in higher levels depend only
on units of lower levels.
– Once the modules in a given level are assigned, define a language
for this level. This language includes the operations that we want to
make visible to the next level above. Add well-defined operation
signatures and security checks in these operations to assure the
proper use of the level.
– Hide in lower levels those modules that control critical security
functions.
Secure Systems Research Group - FAU
OS Layered Architecture
users
utilities
file system
I/O drives
disk drives
...
UserApplication
Layer 5
Utilities
Layer 4
FileSystem
Layer 3
I/Odrives
Layer 2
Hardware
Layer 1
hardware
Secure Systems Research Group - FAU
Layered Operating System
Architecture
• Advantages:
– Clearly defined interfaces between each OS layer
and the user applications
– Control of information using layer hierarchical
rules using enforcement of security policies
between layers Each core component is separate
– Each layer hides existence of certain data
structures, operations and hardware from higher
levels
– Lower levels can be changed without affecting
higher layers
Secure Systems Research Group - FAU
Layered Operating System
Architecture
• Liabilities:
– It is not clear what to put in each layer
– There may be less efficiency as information needs
to go through each layer
– The layers are restricted to interface only with
immediate neighboring layers. This restriction
reduces flexibility and provides additional over
head for to go through adjacent layers in order to
use the services of layers i+2 and greater or layers
i–2 and less.
Secure Systems Research Group - FAU
Symbian layered OS architecture
Connectivity framework
Application services
Application
protocols
Connectivity plug-ins
Application
engines
Messaging
Application
framework
Narrow
band
protocols
Multimedia
Graphics
Secure Systems Research Group - FAU
WAP
browser
Web
browser
WAP
Stack
Web
Stack
JavaPhone
JavaRuntime
Infrared Bluetooth Networking
Comms infrastructure
Security
Connectivity
link
Serial
Comms
Telephony
Base
Unix layered OS architecture
Secure Systems Research Group - FAU
Layered Operating System
Architecture
• Known uses
– OS/2 of IBM, Symbian OS [Sym01]
• Related patterns
– specialization of the Layers architectural
pattern [Bus96].
– A security version of the layers pattern is
presented in [Fer02] and in [Som05].
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture
• Move as much of the OS functionality from
the kernel space
• Very basic set of functions in microkernel
• Use external and internal servers
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture
• Example
We are building an OS for a range of applications with
different reliability and security requirements and a
variety of plug-ins. We would like to provide OS
versions with different types of modules, some more
secure, some less so.
• Context
– Operating systems are large systems that require
decomposition for control of system functions
• Problem
– In general purpose environments we need to be
able to add new functionality and security
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture
• The possible solution is constrained by
the following forces:
– The application platform must cope with continuous hardware
and software evolution; these additions may have very different
security or reliability requirements.
– Strong security or reliability requirements indicate the need for
modules with well-defined interfaces.
– We may want to perform different types of security checks in
different modules, depending their security criticality.
– We would like a minimum of functionality in the kernel so we
have a minimum of processes running in supervisor mode. A
simple kernel can be checked and this is good for security.
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture pattern
• Separate all functionality into specialized
services and provide an efficient way to
route requests to the appropriate servers
• microkernel is the central communication
for the OS
• one microkernel and several internal and
external servers
• an adapter is used between the client and
the microkernel or an external server
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture pattern
ExternalServer
*
calls
Microkernel
1
receive request
dispatch request
execute service
*
execute mechanism
init communication
find receiver
call internal server
send message
create handle (unique ID)
1
InternalServer
*
1
activates
receive request
dispatch request
execute service
Initializes
communication
1
sends request
1
Adapter
calls service
creates request
Secure Systems Research Group - FAU
Client
1
1
calls service
do task
Microkernel Operating System
Architecture pattern dynamics
:Client
:Adapter
call service
:Microkernel
:ExternalServer
create request
init communication
find receiver
receive request
dispatch request
execute service
Secure Systems Research Group - FAU
QNX Microkernel Architecture
• The QNX Microkernel responsibilities
include the following [QNX]:
– IPC (interprocess communication)
– low-level network communication
– process scheduling
– first-level interrupt handling
Secure Systems Research Group - FAU
QNX Microkernel Architecture
Process
B
Process
A
Process
C
Network
Interface
Network
Manager
IPC
Scheduler
Interrupt
redirector
Network media
Hardware
interrupts
source: [QNX ]
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture
• Advantages:
– Provides a good degree of security
because of the well defined interfaces
between servers.
– Can add even more security by putting
fundamental functions in internal servers.
• Liabilities:
– Communication overhead due to message
passing
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture Variants
• The Microkernel OS Architecture Pattern
can be combined with the Layered OS
Architecture pattern
– Many applications in the PalmOS do not
use the microkernel services; they are
handled automatically by the system
– microkernel functionality is provided for
internal use by system software or for
certain special purpose applications
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture Variants
68K Applications
ARM Applications
PACE
Palm OS Application
Compatibility Environment
Background
PIM
System
Licensee
Tasks
Graphics/ UI
Media playback
Multimedia
HotSync
Data Manager
Microkernel
Exchange
Security
Internal storage
I/O Subsystem
Networking
VFS
Telephony
Hardware
Driver Set
source: [PalmOS ]
Secure Systems Research Group - FAU
Microkernel Operating System
Architecture
• Known uses
– PalmOS [PalmOS], QNX [QNX]
• Related patterns
– specialization of the microkernel pattern
[Bus96].
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture
• Provides a set of replicas of the hardware
architecture to separate operating
systems
• Strong isolation between each OS
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture
• Example
– A web server is hosting applications for two competing
companies. These companies use different operating
systems. We want to ensure that there is no access to their
files
• Context
– Mutually suspicious sets of applications that need to execute
in the same hardware. Each set requires isolation from the
other sets.
• Problem
– Sometimes we need to execute different operating systems
in the same hardware. How do we keep those OSs isolated
from each other?
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture
• The possible solution is constrained by
the following forces
– Each OS has its own set of machine
dependent features
– When an OS crashes or is penetrated by a
hacker, the effects of this situation should
not propagate to other OSs in the same
hardware
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture pattern
• Define an architectural layer that is in control of
the hardware and supervises and coordinates the
execution of each OS environment.
• This extra layer, usually called a Virtual machine
Monitor (VMM) or Hypervisor presents to each
operating system a replica of the hardware.
• The VMM intercepts all system calls and
interprets them according to the OS from where
they came.
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture pattern
VMOS
1
*
<<controls>>
VirtualMachineMonitor
VM
*
*
Can run
*
Supports
*
LocalOS
1
Hardware
*
LocalProcess
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture pattern dynamics
:LocalProcess
:Hypervisor
:LocalOS
:Hardware
OS call
OS call
interpret call
perform operation
return(…)
return(…)
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture example resolved
• Two companies using Unix and Linux in
different virtual machines
UNIX
Linux
VM1
VM2
VMM (virtual machine monitor)
hardware
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture
• Advantages
– Each environment (VM) does not know about the
other VM(s).
– Errors or attacks to a given VM have no way to
propagate to other VMs
• Liabilities
– Extra overhead in use of privileged instructions
– It is rather complex to let VMs communicate to
each other (If this is needed).
Secure Systems Research Group - FAU
Virtual Machine Operating System
Architecture
• Known uses
– IBM VM/SP, Vmware
• Related patterns
Secure Systems Research Group - FAU