SELinux Protected Paths Revisitedselinuxsymposium.org/2006/slides/03-pp_revisit.pdf · Trent Jaeger Department of Computer Science and Engineering Pennsylvania State University March

1Department of Computer Science & Engineering

SELinux Protected Paths Revisited

Trent JaegerDepartment of Computer Science and Engineering

Pennsylvania State University

March 1, 2006


Talk Topics

Mechanism for MAC enforcement between 2 machines Labeled IPsec

Protected Paths Are we ready?

Distributed System MAC What else do we need?

Claims Distributed enforcement: distributed, shared monitor Trust in that enforcement: trust representation Simplicity and scalability: can virtual machines help?


Mandatory Access Control

Linux Kernel SELinuxModule

MACPolicy

Appl Appl Appl


Mandatory Access Control

Linux Kernel

SELinuxModule

MACPolicy

Appl Appl Appl

File X


Network MAC


MACPolicy

Appl ApplAppl

System


MACPolicy

Appl Appl Appl

System

X


Client-Server MAC


MACPolicy

Appl Appl

Client


MACPolicy

Appl Appl Server

Server

Appl

Worker


Location-independent MAC


MACPolicy

Appl ApplNew

Remote System


MACPolicy

Appl Appl Master

Base System

Create


Labeled IPsec

Leverage IPsec Advantages Secure communication Easy to integrate to kernel MAC

Add MAC Labeling to IPsec Control application access to IPsec “channels” Can only send/receive with MAC permission

Results Application to application control is possible BLP controls between applications on different machines Applications can use labeling information

Label child processes Part of Linux 2.6.16-rc* kernel

Will be in 2.6.16 kernel


Client-Server Usage

OS KernelAccessControlModule

MACPolicy

Appl Appl

System

OS KernelAccessControlModule

MACPolicy

Appl Appl Appl

System

Appl

Worker

(1) Black must be able to access green policy (among others)(2) Black can extract label of SA for socket (3) Prototyped using getsockopt(…, SO_PEERSEC)


Get Peer Label

TCP Is a socket connected? (TCP_ESTABLISHED) getsockopt(.. SO_PEERSEC ..) dst_entry cache of socket (labeled SA)

UDP Connectionless Set IP_PASSSEC socket option recvmsg now returns context as well

For UNIX stream, dgram (soon) and INET stream, dgram Work by Catherine Zhang at IBM Research


Use Labels in Client Control

Network Services vsftpd, xinetd

Get label using TCP method Configuration

Get xinetd to use labels based on configuration Storage Security

Proxy-based Server proxy limits access based on client label

Server is trusted Client proxy connects based on client label

Client proxy processes need not be trusted


Distributed MAC Goal

Protected Paths From “Inevitability of Failure”

Direct, Authenticated Communication Integrity-preserved from input to output Get peer’s label reliably

Comparable to Authenticated IPC UNIX domain sockets

Where are we relative to achieving protected paths for real? Are protected paths enough?


Protected PathsX

serv

er

Win

dow

Man

ager

App

licat

ion

Ope

ratin

g Sy

stem

sNetwork

Operating System

s

Application

Window

Manager

Xserver


Protected PathsX

serv

er

Win

dow

Man

ager

App

licat

ion

Ope

ratin

g Sy

stem

sNetwork

Operating System

s

Application

Window

Manager

Xserver

MAC Label


Protected PathsX

serv

er

Win

dow

Man

ager

App

licat

ion

Ope

ratin

g Sy

stem

sNetwork

Operating System

s

Application

Window

Manager

Xserver

AttestMAC Label

User


Protected Path Challenges

User-to-Application Xserver Control Window Manager Control

Application-to-OS Labeled IPsec Application Control Using Label

OS-to-OS Reference Monitoring MAC Policy, Labeling Remote Attestation, Building Trust from Secure Hardware


Existing Solutions

Distributed Policy Management E.g., Tivoli Access Manager, Microsoft Windows Domains

Virtual Machine Systems NetTop Terra

Logic of Authentication Taos and Secure Boot

Trust Management Systems E.g., PolicyMaker, KeyNote, etc.

Trust Negotiation


Secure Coalition System

Recent IBM Technical Report -- RC23865 Work with J. McCune at CMU; S. Berger, R. Caceres, R.

Sailer at IBM Research


Distributed, Shared Monitor

Distributed, Shared Reference Monitor TPM attestation of each physical machine’s reference monitor Common enforcement properties: monitoring, MAC policy


Virtual Machines

Advantages Coarser-grained protections

Coarser-grained policy Simpler reference monitor

VM per application (simplify policy within VM) Challenges

Dynamic policy (Yin and Wang, USENIX 2005) Doesn’t fix user-to-user (Nitpicker’s, ACSAC 2005) Translate into client-specific rights (finer-grained) Scalable construction, maintenance of trust


Building Trust

Build Trust in Other System’s Reference Monitoring And MAC Policy And Labeling of Subjects and Objects

Why is this necessary? Internet-scale

Register TPM and physical protection, but a different admin Administration errors

Misconfiguration of a machine Malice

Compromised platform Build trust from secure hardware up


Internet-Scale Distributed Systems

Simple Langauge of Trust Limited by Reference Monitoring Properties Monotonic Reasoning

Multiple Layers of Reasoning Machine Virtual Machine Coalition

Building Systems to Test Soundness/Completeness Web Hosting Internet Suspend/Resume Distributed Computations -- Student Testing


Summary

Aim: Network MAC to Distributed System MAC

Have IPsec MAC controls What is an appropriate goal for distributed system MAC

Protected Paths plus Remote Attestation plus Virtual Machines? Distributed, Shared Reference Monitor

Several Challenges Remain Trust across systems Compatibility (policy, labeling) across systems Service awareness Building all the way to the user


Questions?

Contact Trent Jaeger, [email protected] Penn State SIIS Lab, siis.cse.psu.edu www.cse.psu.edu/~tjaeger

DSRM prototype report IBM Tech Report RC23865 -- With McCune, Berger, Caceres, Sailer

Linux kernel www.kernel.org

SELinux www.nsa.gov/selinux

SELinux Protected Paths Revisitedselinuxsymposium.org/2006/slides/03-pp_revisit.pdf · Trent Jaeger Department of Computer Science and Engineering Pennsylvania State University March

Documents