SELinux Symposium Notes: Session 3

[Editor's note: More notes taken during the talks at the 2006 SELinux Symposium. Use at your own risk, etc., etc.]

Reference Policy for Security Enhanced Linux (Chris PeBenito et. al., Tresys Technology)

goal: make policy understandable; close-coupling means developers must understand entire policy
3rd parties need to be able to create policy modules — lack of understanding hurts security
refpolicy reduces complexity & exploits software engineering: documented, modular, configurable
core infrastructure is mature, large # of modules (70%)
security goals: OS self-protection, secure extensability (protect code & modules from each other), assurance, improved role separation (not there yet)
loadable modules, enhanced support for tools, managing complexity, better comprehension, single unified src
design concepts: layering, modularity, encapsulation, abstraction (all “enforced” by convention) [eventually native language support...]
layering only organizational
modules have private code, public interfaces, labeling statements — no global types/attributes

Dynamic Policy Enforcement in a Network Environment (Mark Butler et. al., University of Tulsa)

booleans + expert system to switch security states based on observed state of system (events – IDS/logs)
tools to let admin associate events & booleans to modify
agent collects “facts” (events or static) as system runs, & generates boolean changes
requires a large amount of initial configuration

SELinux Protected Paths Revisited (Trent Jaeger, Pennsylvania State University)

network MAC, client-server MAC forking new procs based on client’s label, location-independent MAC (access control follows objects across networks)
leverages labeled IPSec for secure communications
get label of network peer to make decisions (via getsockopt)
goal: distributed (n-machine) MAC & protected paths & authenticated communication
protected paths between users (even more than app-to-app) — i.e. can we trust the labels we get?
challenges: user-to-app (X server, WM); app-to-OS (labeled IPSec); OS-to-OS (refmon, labels, remote attestation, secure hardware)
secure coalition system — VMs running within a coalition using MAC & between coalitions
distributed, shared reference monitor: VM hypervisor, labeled IPSec to secure inter-VM communications, all w/ common MAC policy
VMs allow coarser-grained policy & simpler reference monitor
build trust from secure hardware up

Comments are closed.