Secure Systems - Operating Systems Group

os.inf.tu.dresden.de

Secure Systems - Operating Systems Group

Faculty of Computer Science Institute for System Architecture, Operating Systems Group

Secure Systems

Stefan Kalkowski

Dresden, 2008-01-08


• Basics

So far ...

• Device Drivers

• Real time

• Naming

• Resource Management

• Virtualization / Legacy Container

Secure Systems

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 2 von 39


Outline

Secure Systems:

● Detailed example: Mikro-SINA

● Definitions

● Security policies

● Bastei's stacked policies

● Overlay window management

● Demo

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 3 von 39


Mikro-SINA

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 4 von 39


Secure Internet Network Architecture

• VPN based security architecture by 'Bundesamt

für Sicherheit in der Informationstechnik'

• IPSec and PKI

• Intrusion detection

& response

• Complex real

world scenario

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 5 von 39


SINA Box

• Minimized & hardened Linux

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 6 von 39


Linux complexity

• Linux is complex!

• SLOC for kernel 2.6.18

● All: 4.983.723

● Architecture specific: 817.880

● x86 specific: 55.463

● Driver code: 2.365.256

● Common: 1.800.587

• Running kernel > 2 millions lines of code

• Minimized & hardened version > 500.000 LOC

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 7 von 39


• Goals:

Project Mikro-SINA

● Reduce Trusted Computing Base of VPN

gateway

● Enable high level evaluation (e.g.: Common

Criteria)

• Objectives:

● Confidentiality and integrity of sensitive

network data inside the VPN

• Exploit microkernel features

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 8 von 39


IPSec – the heart of VPN security

• IPSec is a protocol suite for securing the

Internet protocol

• Authentication header

● Guarantees integrity

and authentication

• Encapsulating Security

Payload

● Also confidentiality

• Two different modes

● Tunnel vs. transport

Application

TCP/UDP

IPSec

Data Link Layer

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 9 von 39

IP


Easy approach

• Use paravirtualized L4Linux as a tool

• Identify the security relevant parts in the

insecure application and separate them

• 'Viaduct' is used for authentication, key

management and en- and decryption

L 4 Linux

TCP/IP

IPSec

Fiasco

IPSec

„Viaduct“

Fiasco

L 4 Linux

TCP/IP

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 10 von 39


Viaduct in details

• IP packets must be passed to the Viaduct

● Use TUN/TAP driver in Linux to tunnel IP

TCP/IP

L 4 Linux

eth0 l4tun0

Fiasco

Viaduct

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 11 von 39


Fragmentation of IP packets

• Encrypted IP packets get fragmented

● Problem for decryption

• IP packets have to be unfragmented before

they are passed to the Viaduct

μ-SINA

Gateway

L4Linux Viaduct

IP router IP router

μ-SINA

Gateway

L4Linux Viaduct

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 12 von 39


Let Linux do the dirty work ...

• Register new transport protocol

• IP stack will unfragment IP packets

L 4 Linux

AH/ESP

TCP/IP

eth0 l4tun0

Fiasco

Viaduct

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 13 von 39


What about confidentiality?

• L4Linux is untrusted

● but handles encrypted and unencrypted data

• Use a second L4Linux instance

● Each L4Linux instance drives its own ethernet

card exclusively

L4Linux Viaduct

L4 Internet Linux

LAN

eth0

Fiasco

eth1

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 14 von 39


Mikro-SINA so far

• 'Outer' L4Linux instance handles encrypted

data only

• 'Inner' L4Linux instance handles unencrypted

data and cannot communicate to the other

instance or the 'outgoing' network device

L4Linux Viaduct

L4 Internet Linux

LAN

eth0

Fiasco

eth1

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 15 von 39


Mikro-SINA: Multi Level Security

• Different security levels for data from different

organizational levels

• Use an own L4Linux instance for each level,

that handle the unencrypted data

L 4 Linux

L 4 Linux

L 4 Linux

Fiasco

Viaduct

L 4 Linux

eth0

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 16 von 39


Reduce untrusted code size

• Do we need two L4Linux instances for a VPN

gateway?

� Linux user level, process management,

scheduling, file systems etc. are not necessary

• Use FLIPS (Flexible IP Stack): standalone

TCP/IP stack

FLIPS

Viaduct

Fiasco

FLIPS

eth0 eth1

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 17 von 39


Techniques

• Fine grained isolation

� Microkernel feature

� Enables implementation of principle of least

privilege

• Minimize complexity of TCB for security

relevant code

� Split applications in security relevant and

nonrelevant parts

� Use trusted wrappers (e.g.: Viaduct)

� Minimize common code (microkernel approach)

• Usage of legacy code

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 18 von 39


Nizza - security architecture

• Beyond Mikro-SINA: greater vision Nizza

Common secure

platform

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 19 von 39


Terms & Models

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 20 von 39


Secure system

Secure System * :

� A secure system is a system that starts in an

authorized state and cannot enter an

unauthorized state.

Security Policy * :

� A security policy is a statement that partitions

the states of the system into a set of

authorized, or secure, states and a set of

unauthorized, or nonsecure, states.

* Matt Bishop: Computer Security – Art and Science

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 21 von 39


Security Policy:

Policy and Mechanism

� A security policy is a statement of what is, and

what is not allowed.

� e.g.: SELinux policy, pagetable, /etc/passwd

Security Mechanism:

� A security mechanism is a method, tool, or

procedure for enforcing a security policy

� e.g.: Capabilities, paging hardware

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 22 von 39


Formal security model: Bell-LaPadula

• Subjects and objects have a security label,

consisting of a security level and category set

• A security label dominates another one, if its

security level is greater or equal than the

other one and its category set is a superset of

the other one

{National,Foreign}

{National} {Foreign}

{}

Top Secret

Secret

Confidential

Unclassified

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 23 von 39


Formal security model: Bell-LaPadula

• Example: Label L 1 : (Topsecret, {National})

dominates L 2 (Secret, {})

• Simple Security Condition: S can read O if S

dominates O (no reads up)

• *-Property: S can write to O if and only if O

dominates S (no writes down)

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 24 von 39


Bell-LaPadula summary

• Information flow policy, that preserves

confidentiality

• Very simple model, proof of model's security

properties is also trivial

• No integrity concerns in the model (use Biba)

• Problem: information flows only in one

direction

� A lot of underlying system software (e.g.

device drivers) has to be used by all different

security levels

� Mostly these parts are excluded from the model

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 25 von 39


More flexible security models

• Type Enforcement

� Subjects and objects have types

� Types can be compounded to other types

� Explicit rules state what types can access

(read, write) what other types

• Very general model

• In general: its more hard to prove specific

security properties in such a policy

• SELinux is an example for TE in practice

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 26 von 39


SELinux

• Developed by the NSA

• Based on Linux Security Modules (LSM)

• Linux functionality leads to complex security

policy

• Standard (NSA) policy

� over 300 domains

� ~ 50.000 rules

� Tools might help to keep the overview

• Problem: monolithic kernel leads to monolithic

reference monitor with one big policy inside

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 27 von 39


Decompose security policies

• Szenario: Content Management System +

typical web services

TCP/IP

Stack

Ethernet

1000 Card

ATA

Driver

User

Alice

Intel 100

Pro

PCI Host

Controller

Device

Manager

User

Bob

TPM

LPC

Controller

Web

Getty

Content

System

Init

Document

Store

TCP/IP

Stack

Audit

Passwd

Auth

Mailserver

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 28 von 39

DMZ

SSL

Auth

Webserver

DNS


Decompose security policies

• Application specific policy stack

• Diverse security policy types can be combined

TCP/IP

Stack

Ethernet

1000 Card

ATA

Driver

User

Alice

Intel 100

Pro

PCI Host

Controller

ACM

User

Bob

TPM

LPC

Controller

Web

Getty

TE +

Roles

ACM

Document

Store

TCP/IP

Stack

Audit

Passwd

Auth

Mailserver

iptables

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 29 von 39

SSL

Auth

Webserver

DNS


Use Bastei sessions

• In Bastei every task dominates its children

with respect to sessions outside the child's

own subtree

• Eases up multilateral security

– Every organization unit can

integrate its own policy

Child 1 Child 2

just

do it!

dominates

second policy

decision

Init

Grand-

Child

dominates

first policy

decision

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 30 von 39


Overlay Window

Management

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 31 von 39


Legacy application: web browser

GET https://my-bank.com

Browser

App.

Loader

L4Linux

Proxy

stub

GET https://my-bank.com

DOpE

Webproxy

FLIPS

L4Env

Fiasco

firefox https://my-bank.com

start

Browser

Secure

Storage

App.

Loader

L4Linux

Proxy

stub

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 32 von 39


Legacy application: web browser

• Browsing Domain 1 under Domain sensitive 2

Domain domains 3 Domain (e.g. 4 online

banking) is done in a automatically newly

created L4Linux sandbox

• L4Linux sandbox uses read-only root

filesystem + ramdisk (we can use freezer)

Webproxy

• No need to touch the web browser at all

• You only have to register the web proxy as a

Secure

valid certification DOpEinstance

FLIPS (for Storagehttps

only)

• Problem: how to integrate L4Env the web browser

windows on top of the different L4Linuxes

Fiasco

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 33 von 39


Overlay Window Management

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 34 von 39


Overlay Window Management

• Technique for integration of different legacy

window managers is called Overlay Window

Management (supported by Nitpicker / DOpE)

• Trusted multiplexer of framebuffer and input

events

• 'Trusted' – due to low complexity

� Nitpicker < 2.000 LOC

• Isolation between different guest windows to

prevent spyware (e.g.: a keylogger)

Secure labeling of guest windows

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 35 von 39


DEMO

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 36 von 39


Summary

• How to construct safe systems with less effort

• Techniques: application splitting, virtualization

• Security Policies:

� A little bit about formal models (more in

'Distributed Systems' lecture)

� Stacking of security policies

• How to integrate legacy window managers

• ... and a lot of cool examples!

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 37 von 39


References

• Matt Bishop: Computer Security – Art and Science,

Addison-Wesley 2003

• Christian Helmuth et. al.: µSINA - Eine

mikrokernbasierte Systemarchitektur für sichere

Systemkomponenten, Tagnungsband 8. Deutscher

IT-Sicherheitskongress des BSI 2003

• Hermann Härtig: Security Architectures Revisited,

Proceedings of the 10th ACM SIGOPS European

Workshop 2002

• Norman Feske et. al.: Overlay Window

Management: User interaction with multiple

security domains, Technical Report 2004

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 38 von 39


Next Lesson

• Next week (12.01):

� Continuation of secure systems

� More about Nizza

� Trusted computing

• Tomorrow:

� Practical exercise: Bastei

TU Dresden, 2008-01-08 MOS - Secure Systems Slide 39 von 39

More magazines by this user
Similar magazines