Attack Graphs - Pennsylvania State UniversityCurrent Attacks 5 • Attack unprivileged processes...
Transcript of Attack Graphs - Pennsylvania State UniversityCurrent Attacks 5 • Attack unprivileged processes...
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Systems and Internet Infrastructure Security
Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA
1
Attack Graphs
Penn State Systems and Internet Infrastructure Security Lab Page
Outline
• Attack Graphs
• MulVal
• System-wide Info Flow
2
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Systems and Internet Infrastructure Security
Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA
3
Towards System-Wide, Deployment-Specific MAC Policy Generation for Proactive Integrity Mediation
Sandra Rueda, Divya Muthukumaran, Hayawardh Vijayakumar, Trent Jaeger, Swarat Chaudhuri
Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department
Pennsylvania State University
September, 2011
Penn State Systems and Internet Infrastructure Security Lab Page
Talk Outline
4
• Current State of Security
‣ Attack methods are comprehensive
‣ Defenses are ad hoc
• Problem: Generate proactive defense automatically
‣ What do we know how to do already?
‣ Develop a solution method built on such techniques
• How will such a method impact system design/deployment?
‣ Prototype to generate and test system-wide MAC policies
‣ Other talks: (1) integrity measurement protocol that measures such defenses and (2) process firewall that protects system call interface
Penn State Systems and Internet Infrastructure Security Lab Page
Current Attacks
5
• Attack unprivileged processes first
‣ Then, escalate privilege incrementally via local exploits
‣ Leverage (unjustified) trust between processes/hosts to propagate attacks
• Such Attack Paths are ubiquitous in current systems
‣ Processes are tightly interconnected
• Historically, all user processes have same privilege and can utilize system services
‣ Any control flow vulnerability can be leveraged to run any code
• Return-oriented programming
• Claim: Adversaries will use any undefended path
Penn State Systems and Internet Infrastructure Security Lab Page
Current Defenses
6
• We have made progress the last 10 years or so
‣ Vulnerable network services galore hardened, privilege- separated daemons (OpenSSH)
‣ Default-enabled services hardened configurations (IIS)
‣ Root system processes galore Mandatory access control (Linux, BSD)
‣ Application plug-ins in same address space Run application code in separate processes (Chrome, OP browsers)
‣ Email attachments compromise system Prevent downloaded content from modifying system (MIC, antivirus)
‣ A process in one host can easily access another host Limit open ports (host firewalls, labeled networking)
Penn State Systems and Internet Infrastructure Security Lab Page
MAC Operating Systems
• Mandatory Access Control (MAC) operating systems
‣ Define an immutable set of labels and assign them to every subject and object in the system
‣ Define a fixed set of authorized operations based on the labels
• Now available in most commodity operating systems (Trusted Solaris, TrustedBSD, SELinux, AppArmor, Windows MIC*, etc)
7
OS Reference Monitor
Security Server
a
b
q
p
r
Policy
User Space Kernel Space
Penn State Systems and Internet Infrastructure Security Lab Page
MAC Enforcement Everywhere
8
• MAC enforcement in the OS alone is not enough
• Several applications are designed to serve users with multiple security requirements
‣ OS cannot control what these applications do
• OS are not trusted to isolate computing (reference monitor concept)
‣ But virtualization is (for now)
‣ MAC at virtualization layer (VMM, hypervisor) can mediate system comprehensively
• OS MAC does not control operations between hosts
‣ Labeled networking assigns labels to all network data (Labeled IPsec and Secmark Firewall)
Penn State Systems and Internet Infrastructure Security Lab Page
We’ve Created a Monster
• We end up with systems consisting of
‣ Complex programs
‣ Complex program configurations
‣ Complex MAC policies
‣ Systems consisting of many, independent components
• All these are built with a particular threat model in mind
‣ Which is likely different than the actual deployment
• System administrators are left to fix them
9
Penn State Systems and Internet Infrastructure Security Lab Page
Taming a Monster
• Design components to defend threats proactively
‣ Programs: protect at some interfaces; expect high integrity data at others
‣ OS Distros: protect at some ports, files; expect high integrity data at others
‣ Hosts: Ditto
• System administrators create systems from multiple, independent components, connecting them to external resources
‣ They would like to know that the use of these components corresponds to their defenses
• The two tasks are ultimately the same conceptual problem
10
system-wide MAC policies to defend deployments proactively. We need automated tools to generate
Penn State Systems and Internet Infrastructure Security Lab Page
What Do We Know How To Do?
• Compute Attack Paths (from Attack Graphs)
‣ Find the sequence of steps that adversaries can take to compromise a system
• Compute Compliance
‣ Find information flow and permission errors in programs and system MAC policies
• Identify Attack Surfaces
‣ Find how systems and programs are accessible to adversaries
• Attack-Specific Analyses
‣ E.g., input sanitization
11
Penn State Systems and Internet Infrastructure Security Lab Page
What Do We Know How To Do?
• Compute Attack Paths (from Attack Graphs)
‣ Find the sequence of steps that adversaries can take to compromise a system
• Compute Compliance
‣ Find information flow and permission errors in programs and system MAC policies
• Identify Attack Surfaces
‣ Find how systems and programs are accessible to adversaries
• Attack-Specific Analyses
‣ E.g., input sanitization
12
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Problem
• Evaluating whether a policy permits an adversary to have unauthorized access (i.e., contains an error) is a compliance problem:
‣ System Policy: describes a system’s behavior
‣ Goal Policy: describes acceptable behavior
‣ Mapping function: relates elements from the system policy to elements in the goal policy
‣ A compliant system policy is guaranteed to meet the requirements defined by the goal policy
13
Penn State Systems and Internet Infrastructure Security Lab Page
Evaluating OS MAC Policy
• We represent a single MAC policy with an information flow graph
‣ Used in analyses for SELinux by Tresys, Stoller, Li, Jaeger, etc.
14
etc_t var_t sbin_t
installer_t read,write read,write read,write
kernel_t read,write read,write read
ftpd_t read read read
var_t
installer_t
kernel_t
ftpd_t etc_t
sbin_t
read read,write
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Problem
15
• The policy compliance problem for a single policy is set up as follows:
• System policy – The policy that we are analyzing is represented as a graph
var_t
installer_t
kernel_t
ftpd_t etc_t
sbin_t
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Problem
16
• The policy compliance problem for a single policy is set up as follows:
• System policy – The policy that we are analyzing is represented as a graph
• Goal – The security goal is a lattice that defines integrity levels and rules that guarantee the integrity of the system
High
Low
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Problem
17
• The policy compliance problem for a single policy is set up as follows:
• System policy – The policy that we are analyzing is represented as a graph
• Goal – The security goal is a lattice that defines integrity levels and rules that guarantee the integrity of the system
• Mapping - Assigns integrity levels to policy labels
var_t
installer_t
kernel_t
ftpd_t etc_t
sbin_t
High
Low
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Problem
18
• The policy compliance problem for a single policy is set up as follows:
• System policy – The policy that we are analyzing is represented as a graph
• Goal – The security goal is a lattice that defines integrity levels and rules that guarantee the integrity of the system
• Mapping - Assigns integrity levels to policy labels
var_t
installer_t
kernel_t
ftpd_t etc_t
sbin_t High
Low
Do all flows meet the requirements defined by the goal ?
High
Low
Penn State Systems and Internet Infrastructure Security Lab Page
Other Compliance Problems
• Information flow compliance in programs
‣ Data flow is determined by program data flows – security-typed languages, such as Jif, Sif, SELinks, FlowCaml
• Goal policy is not a lattice
‣ Illegal reachability: no path from u G v
‣ Illegal sets of permissions: annotate edges with permissions
• Goals as obligations
‣ The presence of a node, edge, or path is required
‣ These are functional constraints, rather than security
19
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Challenges
20
• Construct Data Flow Graph
‣ Multiple independently-developed policies
• Different policy languages
• Different policy concepts
• Policies may interact in multiple ways
allow httpd_t self:tcp_socket create_stream_socket_perms;allow httpd_t self:udp_socket create_socket_perms;
# Allow httpd_t to put files in /var/cache/httpd etcmanage_dirs_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_lnk_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)
# Allow the httpd_t to read the web servers config filesallow httpd_t httpd_config_t:dir list_dir_perms;
allow httpd_t self:tcp_socket create_stream_socket_perms;allow httpd_t self:udp_socket create_socket_perms;
# Allow httpd_t to put files in /var/cache/httpd etcmanage_dirs_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_lnk_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)
# Allow the httpd_t to read the web servers config filesallow httpd_t httpd_config_t:dir list_dir_perms;
VMM
OS
Net
App App
OS
Net
App
Web Server
VMM
OS
Net
App
DB Server
Penn State Systems and Internet Infrastructure Security Lab Page
Compliance Challenges
21
• Goals and mappings are manually-specified
‣ Lattice policy is not specified
‣ Mapping is not specified
‣ Our experience indicates that the size of the goal increases with the size of the distributed system
‣ Manual specification is prone to error
‣ Then, how do you fix errors?
allow httpd_t self:tcp_socket create_stream_socket_perms;allow httpd_t self:udp_socket create_socket_perms;
# Allow httpd_t to put files in /var/cache/httpd etcmanage_dirs_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_lnk_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)
# Allow the httpd_t to read the web servers config filesallow httpd_t httpd_config_t:dir list_dir_perms;
allow httpd_t self:tcp_socket create_stream_socket_perms;allow httpd_t self:udp_socket create_socket_perms;
# Allow httpd_t to put files in /var/cache/httpd etcmanage_dirs_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)manage_lnk_files_pattern(httpd_t, httpd_cache_t, httpd_cache_t)
# Allow the httpd_t to read the web servers config filesallow httpd_t httpd_config_t:dir list_dir_perms;
VMM
OS
Net
App App
OS
Net
App
Web Server
VMM
OS
Net
App
DB Server
Penn State Systems and Internet Infrastructure Security Lab Page
Attack Surfaces
• Where are ‘vulnerabilities’?
‣ A flaw, accessible to an adversary, with an ability to compromise that flaw
• Program input interfaces (e.g., read system calls) that are accessible to adversaries [Howard of Microsoft]
22
httpd_t Read
line 357
Pread line 421
Read line 256
Readahead line 559
Readv line 987
file
file
Penn State Systems and Internet Infrastructure Security Lab Page
Attack Surface Challenges
• How to identify attack surfaces of individual programs
‣ All interfaces have access to all process permissions
‣ Some interfaces are obvious (network), but others are questionable
• Researchers have used value of data behind interface
‣ But this does not say anything about accessibility
• Difficult to identify attack surfaces from the program alone
‣ Depends on its deployment
• Goal: Use MAC policies to identify attack surfaces – defenses must be placed there
23
Penn State Systems and Internet Infrastructure Security Lab Page
Goal Statement
Generate a compliant, system-wide MAC policy that minimizes the cost of defense (attack surfaces) mostly-automatically for distributed systems consisting of multiple, independent MAC-enforcing components.
24
Penn State Systems and Internet Infrastructure Security Lab Page
Ideally, Approximately
• Solve as an optimization problem
• Find the minimum cost solution that satisfies a goal policy consisting of security and functional constraints (likely, an NP-complete problem)
‣ Compliance was defined in terms of security policies only (lattice)
‣ Also, need to prevent the removal of necessary function
• Could apply SMT solver or greedy algorithm to solve such a problem
• Barrier: While we think that we can predict a meaningful, conservative set of security constraints, little is known about what function is permissible
• Instead: For a particular functional specification, find the minimum cost solution that complies with a goal policy (security only)
25
Penn State Systems and Internet Infrastructure Security Lab Page
Distributed Compliance Evaluation
26
component1
…
1. Evaluate Compliance 2. Resolve Non-Compliant Systems
componentn
Compliant System-Wide MAC Policy
Optional Specification
Penn State Systems and Internet Infrastructure Security Lab Page
Distributed Compliance Evaluation
27
Hierarchical
Data Flow
Graph
Task Two:
Bulld System-Wide Information Flow Model
Task One:
Build System-Wide
Data Flow Graph
Information
Flow Model
Task Three:
GenerateSystem-Wide MAC Policy
System-WIde
MAC Policy
(DIFC-Flume)
MAC
Policies
Integrity
Requirements
+
Syste
m C
om
po
nen
ts
Penn State Systems and Internet Infrastructure Security Lab Page
Example System
28
Server Host
DB
VM
Priv VM
VMMNetwork Servers(DNS, DHCP)
App Client
Web
VM
MAC MAC
MAC
MAC
Penn State Systems and Internet Infrastructure Security Lab Page
System Data Flows?
29
Server
Server VM
Backend VM
httpd
process
app
process
Expr
Host Responsibility(VMM)
Some Responsibility (VM/OS)
Less Responsibility(Process)
Client
Process
Network
Some Responsibility (OS)
Other
External
Penn State Systems and Internet Infrastructure Security Lab Page
1. Construct Data Flow Graph
• We find that MAC-enforcing components in distributed systems are
‣ Encapsulated: data flows are mediated by MAC policy
‣ Hierarchical: each has at most one parent
‣ Reusable: same flows may appear multiple times
• We use an hierarchical graph data structure defined by Alur et al.[Alur2004] to concisely represent data flows
30
component1
…
Construct Data Flow
Graph componentn
Penn State Systems and Internet Infrastructure Security Lab Page
Data Flow Graph Definition
31
Policy Generation Problem
System-Wide Information Flow Policy,
Including Mediation
Test Policy
Goal Policy
Does Test Comply with Goal?
Data Flow Graph: G=(V,E)
Integrity Lattice:
Mapping
Sourcesand
Sinks:M: V L
Compliant Policy
Yes
Compute Near-Minimal Mediation for Compliance
IntegrityErrorsNo
Task 1
Task 2
Task 3
Task 4
Compliance Modelplus Mediators
Compliance Model plus Errors
L = (L,!)
Co
mp
lian
ce M
od
el
Multiple, Independent Components, defined by:
MAC and Network Policies
FunctionalRoles in
Deployment
Figure 3: Proactive Integrity Methodology Tasks
VMM
VMVM
ProcProc
Exp
Full Responsibility(VMM)
Some Responsibility (VM)
Less Responsibility(Process)
No Responsibility(Expression)
Import A
Import B
Figure 4: Systems are encapsulated and hierarchical
data structure are well-known [1].A hierarchical state machine K is a tuple (K1, ...Kn) of
modules, where each module Ki has the following compo-nents:• A finite set Vi of nodes.• A finite set Bi of boxes.• A subset Ii of Vi, called entry nodes.• A subset Oi of Vi, called exit nodes.• An indexing function Yi : Bi → {i + 1, ..., n} that maps
each box of the i-th module to an index greater than i. Thatis, if Yi(b) = j for box b of module Ki, then b can be viewedas a reference to the definition of module Kj .• If b is a box of the module Ki with j = Yi(b), then pairs
of the form (b, u) with u ∈ Ij are the calls of Ki and pairsof the form (b, v) with v ∈ Oj are the returns of Ki.• An edge relation Ei consisting of pairs (u, v), where the
source u is either a node or a return of Ki and v is either anode or a call of Ki.
The key concept in HSM is a module, which representsa single graph of nodes and edges within the HSM. Eachcomponent that enforces its own MAC policy is representedby a module. Components that do not enforce a MAC pol-icy are represented as nodes. The other important featureof the HSM model is its flexible model for expressing dataflows between modules. Boxes describe independent dataflows from a parent node to a child node through calls andreturns. This flexibility is important because data may entera module from multiple sources, and each of these distinctinputs may be represented precisely using the HSM model.Also, a module may receive multiple flows from the samesource with distinct security requirements, but the modelcan be constructed to represent such flows precisely whileeliminating redundant flows.
We find that the HSM model can accurately model thedata flows among components in end-to-end systems, be-cause software layers are arranged hierarchically and com-ponents are encapsulated by the peer layers, as shown inFigure 4. A system is hierarchical in that the responsibilityfor security decisions is monotonically-reduced from the rootto the leaves. For example, a VMM has full access to thephysical resources of the platform, VMs have a distinct sub-sets of these resources (e.g., consider physical memory), andeach VM process may only access a subset of the resourcesavailable to its VM. A system is also encapsulated in that allinteractions between two peer components are implementedby an ancestor layer (usually the parent). For example, anoperating system or VMM provides the only mechanismsavailable for two processes to communicate1.
5.2 Compliance ModelOnce a model of the end-to-end system is constructed,
there are often information flow integrity errors. We wantto produce mediation placements to resolve these errors thatpresent a minimal cost of defending the system. Pike [44]and our prior work [23, 24] independently found that suchmediation placements could be estimated as graph-cuts au-tomatically. In this work, we use the compliance analysismodel defined below:
1. A directed data flow graph G = (V, E) consisting of aset of nodes V connected by edges E.
2. A lattice L= {L,#}. For any two levels li, lj ∈ L,li # lj means that li ‘can flow to’ lj .
3. There is an import mapping function M : V → PL
where PL is the power set of L. i.e., each node ismapped either to a set of levels in L or to ∅.
4. The lattice imposes security constraints on the infor-mation flows enabled by the data flow graph. Eachpair u, v ∈ V s.t. [u ↪→G v ∧ (∃lu ∈ M(u), lv ∈ M(v).lu '#L lv)], where ↪→G means there is a path from u tov in G, represents an information flow error.
It has been shown that programs can be automaticallytranslated into such a model [35], as used by King et al. [24],and we show that a MAC policy can also be translated intothe model automatically, based on previous work [44, 55,50, 8, 21]. In a MAC policy, operations can be classifiedas read-only, write-only, and read-write, between subject la-bels and object labels in the policy. From this classifica-tion, a directed data flow graph can be constructed where1While two processes may setup shared memory to commu-nicate without OS intervention, the OS must authorize suchmemory mappings.
Policy Generation Problem
System-Wide Information Flow Policy,
Including Mediation
Test Policy
Goal Policy
Does Test Comply with Goal?
Data Flow Graph: G=(V,E)
Integrity Lattice:
Mapping
Sourcesand
Sinks:M: V L
Compliant Policy
Yes
Compute Near-Minimal Mediation for Compliance
IntegrityErrorsNo
Task 1
Task 2
Task 3
Task 4
Compliance Modelplus Mediators
Compliance Model plus Errors
L = (L,!)
Co
mp
lian
ce M
od
el
Multiple, Independent Components, defined by:
MAC and Network Policies
FunctionalRoles in
Deployment
Figure 3: Proactive Integrity Methodology Tasks
VMM
VMVM
ProcProc
Exp
Full Responsibility(VMM)
Some Responsibility (VM)
Less Responsibility(Process)
No Responsibility(Expression)
Import A
Import B
Figure 4: Systems are encapsulated and hierarchical
data structure are well-known [1].A hierarchical state machine K is a tuple (K1, ...Kn) of
modules, where each module Ki has the following compo-nents:• A finite set Vi of nodes.• A finite set Bi of boxes.• A subset Ii of Vi, called entry nodes.• A subset Oi of Vi, called exit nodes.• An indexing function Yi : Bi → {i + 1, ..., n} that maps
each box of the i-th module to an index greater than i. Thatis, if Yi(b) = j for box b of module Ki, then b can be viewedas a reference to the definition of module Kj .• If b is a box of the module Ki with j = Yi(b), then pairs
of the form (b, u) with u ∈ Ij are the calls of Ki and pairsof the form (b, v) with v ∈ Oj are the returns of Ki.• An edge relation Ei consisting of pairs (u, v), where the
source u is either a node or a return of Ki and v is either anode or a call of Ki.
The key concept in HSM is a module, which representsa single graph of nodes and edges within the HSM. Eachcomponent that enforces its own MAC policy is representedby a module. Components that do not enforce a MAC pol-icy are represented as nodes. The other important featureof the HSM model is its flexible model for expressing dataflows between modules. Boxes describe independent dataflows from a parent node to a child node through calls andreturns. This flexibility is important because data may entera module from multiple sources, and each of these distinctinputs may be represented precisely using the HSM model.Also, a module may receive multiple flows from the samesource with distinct security requirements, but the modelcan be constructed to represent such flows precisely whileeliminating redundant flows.
We find that the HSM model can accurately model thedata flows among components in end-to-end systems, be-cause software layers are arranged hierarchically and com-ponents are encapsulated by the peer layers, as shown inFigure 4. A system is hierarchical in that the responsibilityfor security decisions is monotonically-reduced from the rootto the leaves. For example, a VMM has full access to thephysical resources of the platform, VMs have a distinct sub-sets of these resources (e.g., consider physical memory), andeach VM process may only access a subset of the resourcesavailable to its VM. A system is also encapsulated in that allinteractions between two peer components are implementedby an ancestor layer (usually the parent). For example, anoperating system or VMM provides the only mechanismsavailable for two processes to communicate1.
5.2 Compliance ModelOnce a model of the end-to-end system is constructed,
there are often information flow integrity errors. We wantto produce mediation placements to resolve these errors thatpresent a minimal cost of defending the system. Pike [44]and our prior work [23, 24] independently found that suchmediation placements could be estimated as graph-cuts au-tomatically. In this work, we use the compliance analysismodel defined below:
1. A directed data flow graph G = (V, E) consisting of aset of nodes V connected by edges E.
2. A lattice L= {L,#}. For any two levels li, lj ∈ L,li # lj means that li ‘can flow to’ lj .
3. There is an import mapping function M : V → PL
where PL is the power set of L. i.e., each node ismapped either to a set of levels in L or to ∅.
4. The lattice imposes security constraints on the infor-mation flows enabled by the data flow graph. Eachpair u, v ∈ V s.t. [u ↪→G v ∧ (∃lu ∈ M(u), lv ∈ M(v).lu '#L lv)], where ↪→G means there is a path from u tov in G, represents an information flow error.
It has been shown that programs can be automaticallytranslated into such a model [35], as used by King et al. [24],and we show that a MAC policy can also be translated intothe model automatically, based on previous work [44, 55,50, 8, 21]. In a MAC policy, operations can be classifiedas read-only, write-only, and read-write, between subject la-bels and object labels in the policy. From this classifica-tion, a directed data flow graph can be constructed where1While two processes may setup shared memory to commu-nicate without OS intervention, the OS must authorize suchmemory mappings.
Penn State Systems and Internet Infrastructure Security Lab Page
Policies to Data Flow Graph
32
Secmark Host Firewall Policies: Web VM: iptables -t mangle -A OUTPUT -p tcp --dport 3306 -s <srcIP> -d <tgtIP> -j SECMARK --selctx system_u:object_r:db_client_port_t:s0 DB VM: iptables -t mangle -A INPUT -p tcp --dport 3306 -s <srcIP> -d <tgtIP> -j SECMARK --selctx system_u:object_r:db_server_port_t:s0
apache_t
Web VM
mysqld_t
...
Web VM DB VM
db_ client_port
VMM
db_server_ port
DB VM
SELinux OS MAC Policies
Xen Security Modules Flask/sHype Policies
Penn State Systems and Internet Infrastructure Security Lab Page
Information Flow Model
33
System policy: Goal: Mapping function: Compliance:
Information Flow Errors:
k-db
...
...
u
v
...
...
...
ext
k-web k-db
k-dom0
VMM
ext
db web
G = (V,E)L = (L,!)map : V ′ → L, V ′ ⊆ V
∃u, v ∈ V. u ↪→G v ∧map(u) %↪→L map(v)
∀u, v ∈ V. (u ↪→G v) → (map(u) ↪→L map(v))
Penn State Systems and Internet Infrastructure Security Lab Page
2. Build the Info Flow Model
• Problem: No explicit security constraint information
• Problem: Distributed systems are too large to annotate manually
• Insight: It’s all around
34
Penn State Systems and Internet Infrastructure Security Lab Page
Identify Integrity Levels
• Problem: No explicit security constraint information
• Problem: Distributed systems are too large to annotate manually
• Insight: It’s all around
• (1) Trusted Computing Bases: (OS) modify kernel objects and (VMM) modify VMM objects
• (2) Application Data: Deploy VMs with a particular application in mind
• (3) Apps trust TCB
• (4) Some Apps Depend on Others: E.g., Web applications depend on DB
35
k-web k-db
k-dom0
VMM
ext
db web
Penn State Systems and Internet Infrastructure Security Lab Page
Identify Integrity Levels
• Problem: No explicit security constraint information
• Problem: Distributed systems are too large to annotate manually
• Insight: It’s all around
• (1) Trusted Computing Bases: (OS) modify kernel objects and (VMM) modify VMM objects
• (2) Application Data: Deploy VMs with a particular application in mind
• (3) Apps trust TCB
• (4) Some Apps Depend on Others: E.g., Web applications depend on DB
36
k-web k-db
k-dom0
VMM
ext
db web
Penn State Systems and Internet Infrastructure Security Lab Page
Relate Integrity Levels
• Problem: No explicit security constraint information
• Problem: Distributed systems are too large to annotate manually
• Insight: It’s all around
• (1) Trusted Computing Bases: (OS) modify kernel objects and (VMM) modify VMM objects
• (2) Application Data: Deploy VMs with a particular application in mind
• (3) Apps trust TCB
• (4) Some Apps Depend on Others: E.g., Web applications depend on DB
37
k-web k-db
k-dom0
VMM
ext
db web
Penn State Systems and Internet Infrastructure Security Lab Page
Relate Integrity Levels
• Problem: No explicit security constraint information
• Problem: Distributed systems are too large to annotate manually
• Insight: It’s all around
• (1) Trusted Computing Bases: (OS) modify kernel objects and (VMM) modify VMM objects
• (2) Application Data: Deploy VMs with a particular application in mind
• (3) Apps trust TCB
• (4) Some Apps Depend on Others: E.g., Web applications depend on DB
38
k-web k-db
k-dom0
VMM
ext
db web
Penn State Systems and Internet Infrastructure Security Lab Page
Expert Knowledge
39
Examples
Level/Mapping inference: - Resources to protect : map(VM, boot_t,ID),ID=‘k-’+VM map(webvm,boot_t,k-webvm)
Lattice inference: - Order: VMs depend on the underlying VMM flow(H,L):- component(L,H,_) flow(VMM,k-webvm)
• Level/Mapping inference
• Lattice inference
Integrity Goal
ext ext
k-webvm
apache_t
webvm
db_client_ port
http_server_port
boot_t
bootloader_t
dns_ port
apache_ config_t web
VMM
k-webvm
ext
web
Mapping
Order
Penn State Systems and Internet Infrastructure Security Lab Page
Resolve by Mediation
40
• We resolve a information flow errors by suggesting mediators
‣ A mediator is a program expected to implement procedures to sanitize inputs so the integrity of the data raises (endorsement)
k-web k-db
k-dom0
VMM
db web
ext
db
k-db
k-dom0
m1
...
...
...
...
...
m2
ext
mediators
k-db
k-dom0
Penn State Systems and Internet Infrastructure Security Lab Page 41
3a. Place Mediators
• [McCamant and Ernst PLDI 2008]: Solve max flow problem to quantify information leakage. Inspired us to look into min-cut.
• View information flow constraints as a graph between incomparable security labels.
• A cut of the graph should correspond to places in the code where mediation statements should be placed such that all information flow errors are resolved.
Penn State Systems and Internet Infrastructure Security Lab Page
Multicut Problem
42
• Finding a minimum cost set of mediation points for an arbitrary lattice is a multicut problem for directed graphs which is NP-hard
k-web k-db
k-dom0
VMM
ext
db web
db
k-db
k-dom0
m1
...
...
...
...
...
m2
ext
mediators
Penn State Systems and Internet Infrastructure Security Lab Page
Mediation Dominance
43
• Greedy approach: cut per sink and unions solutions
• We take advantage of the lattice ordering
‣ if then solving a cut problem in graph G for label li solves any overlapping cut problem for a label lj
db
k-db
k-dom0
s
...
...
...
...
...
...
ext k-web k-db
k-dom0
VMM
ext
db web k-dom0
Penn State Systems and Internet Infrastructure Security Lab Page
Mediation Constraints
• Not all nodes can mediate for all sinks
‣ We compute mediation constraints based on the hierarchical structure of the components
44
db
k-db
k-dom0
s
...
...
...
...
r
...
ext
k-dom0
^[k-db]
Root
VMM
VM
App
k-web k-db
k-dom0
VMM
ext
db web
Penn State Systems and Internet Infrastructure Security Lab Page
Mediation Resolution
• Result
‣ Set of mediators that resolve all information flow errors
45
cutset(k-dom0) = {s} cutset(k-db)={}
db
k-db
k-dom0
s
...
...
...
...
...
...
ext
k-dom0
Penn State Systems and Internet Infrastructure Security Lab Page
Mediators to System-Wide Policy
• After resolution we have:
‣ An integrity lattice and the corresponding mapping to MAC policies
‣ A set of mediators
• Since we do not have functional requirements we do not modify the original policies (future work)
‣ Use subset of operations (see Evaluation)
• We generate a system-wide MAC policy capable of expressing mediation
‣ Recent “practical integrity” models – We chose the Flume policy
‣ We automate generation of Flume integrity policy for a deployment
46
Penn State Systems and Internet Infrastructure Security Lab Page
Flume
• Lattice-based integrity policy
‣ Label: set of integrity tags, L = {kernel,appx}
‣ Ordered under the subset relation
• Each process, p, has an integrity label Ip
‣ For every id t in Ip, p has endorsed every input to satisfy t
‣ Communication: sender’s integrity must be higher than receiver’s integrity
‣ Some processes have capabilities so they can change their labels (add/remove tags)
47
{kernel,appx}
{appx}
Client Ic={appx}
Server Is={serverx,appx}
Ds={serverx}
{appx} {serverx,appx} ⊆request
answer
request: answer:
Penn State Systems and Internet Infrastructure Security Lab Page
3b. Generating Flume Policy
• Processes with capabilities correspond to our mediators
• We want to generate Flume labels and capabilities
‣ Mediator m:
• Lm: GLB of the integrity levels that reach the node
• Dm: integrity levels that may reach m
‣ Non-mediator n:
• Ln: GLB of the integrity levels that reach the node
• Dn: {}
• Convert from levels to Flume tags
‣ Flume label == levels dominated
48
Ls=k-dom0 Ds={k-dom0,db,ext }
db
k-db
k-dom0
s
...
...
...
...
...
...
ext
k-dom0
Penn State Systems and Internet Infrastructure Security Lab Page
Modeling Mediation Cost
• We want to minimize the cost of mediation
‣ The cost of mediators making information flow decisions correctly
• How is this determined?
‣ Cuts identify the set of programs that must enforce information flow requirements
• What is mediation in programs?
49
Penn State Systems and Internet Infrastructure Security Lab Page
Mediation Cost Options
• Per program
‣ The mediation requirements of each program are the same
• Implies reusing same programs in multiple mediation cases
• Per level transformation
‣ Each mediation decision is the same
• Implies that the number of Flume capabilities is the cost (default solution for multicut)
• Per program entry point
‣ Adversaries may access the program in multiple ways (attack surface)
• Implies program has subset of interfaces that may require mediation
• How do we know which interfaces are accessible?
50
Penn State Systems and Internet Infrastructure Security Lab Page
Attack Surface Cost
• Minimize attack surface size per cut problem
‣ Result is the number of security decisions X number of entry points accessible to adversaries
‣ Reuse same interfaces in subsequent cuts (may require multiple mediations at same interface)
‣ Estimate from runtime analysis (like MAC policies themselves)
51
k-db
k-dom0
s
...
...
...
...
...
k-dom0
db
ext
Read line 56
Pread line 216
Read line 296
Readv line 456
Read line 897
Penn State Systems and Internet Infrastructure Security Lab Page
The Goal
• How should systems be built and deployed to achieve compliance?
• Build Software
‣ Define mediated interfaces for programs
‣ Which system calls are allowed to receive adversary data?
• Build OS Distributions
‣ Create OS distribution deployment by specifying: (1) packages and network/VMM policies; (2) MAC policy; and (3) information flow model (semi-automated)
‣ Generate MAC policy for deployment that complies with information flow model using program mediation (or revise model or MAC policy)
• Deploy Systems
‣ Select OS distributions, choose program configurations, define network policy
‣ Verify automatically that the deployment satisfies information flow model – can use in remote attestations also (for tomorrow’s talk)
52
Penn State Systems and Internet Infrastructure Security Lab Page
Experimental Testbed
• Distributed system with
‣ XSM/Flask at the VMM layer
‣ SELinux in the guest VMs
‣ iptables with the Secmark extension governing network communications
• We customized the SELinux policies according to the applications the VMs would run:
‣ Dom0
‣ Database server
‣ Web server
‣ User VM
53
VMM
OS
Net
App App
OS
Net
App
Web Server
OS
Net
App
DB server
Penn State Systems and Internet Infrastructure Security Lab Page
Questions
• We use our tool to explore different configurations for a distributed system
1. How many interfaces do developers need to mediate to make this deployment compliant ?
2. How do changes to functional requirements affect the mediation results ?
54
Penn State Systems and Internet Infrastructure Security Lab Page
Question 1
1. How many interfaces do developers need to adjust to make this deployment compliant ?
‣ Summarizing mediators (cut set)
‣ Unique subjects: some subjects are repeatedly picked as mediators across different VMs (insmod_t for kernel_dom0, kernel_dbsrv, etc.)
‣ The size of the cut represents the effort to implement filtering interfaces where needed
55
Sub Int
32 1069
0 0
3 91
6 469
3 288
6 101
50 2018
Sink
Kernel-dom0
Kernel-dbsrv
dbdata
Kernel-uservm
Kernel-websrv
webdata
Total
Static
Big Effort! • Sub: Subjects • Int: Interfaces
TCB subjects
APP subjects
Penn State Systems and Internet Infrastructure Security Lab Page
Question 2
2. How do changes to functional requirements affect the mediation results ?
‣ Runtime: permissions that are actually exercised at run time
‣ The main difference between static and runtime data is caused by definition of attributes in the MAC policy
56
Sub Int Sub Int
32 1069 23 197
0 0 0 0
3 91 2 22
6 469 7 138
3 288 2 104
6 101 1 37
50 2018 35 498
Sink
Kernel-dom0
Kernel-dbsrv
dbdata
Kernel-uservm
Kernel-websrv
webdata
Total
Static policy Runtime data
Reduction. Runtime could guide policy tightening!
Penn State Systems and Internet Infrastructure Security Lab Page
Execution Time
57
HSM GCM Cut DIFC
18.7 1.0 32.6 8.2
18.7 0.8 13.7 4.9
• HSM: Parse policies and generate HSM model • GCM: Generate graph-cut model • Cuts: Compute system-wide cuts • DIFC: Generate DIFC policy
VMs nodes edges
Q1 4 8905 77091
Q2 4 8610 35105
System Configurations Time (sec)
Penn State Systems and Internet Infrastructure Security Lab Page
Project Tasks
• Collect and represent policies in OpenStack cloud system
‣ Can we generate data flow graphs and compliance models for MAC and other relevant policies in OpenStack cloud system?
• Formalize definitions for cut problem, including cost functions and solution composition, for cloud systems
‣ Can we resolve realistic system-wide compliance problems with minimum cost (approximately)?
• Explore methods to produce reasonable functional options to explore
‣ Can we generate options/constraints for the policy designer that enables them to determine which permissions to authorize?
• Extend the research system to support solving such problems and testing on real cloud deployments
‣ Can we produce cloud deployments that proactively protect themselves?
58
Penn State Systems and Internet Infrastructure Security Lab Page
Summary
• We have made a lot of progress improve host security over the last ten years, but we are still reactive
• To defend systems proactively, we must design security defenses for the deployment
• We define a methodology to generate system-wide MAC policies that comply with information flow requirements automatically
• Such a methodology enables OS distributors to create compliant systems that system administrators and remote parties can verify automatically – proactive evaluation end-to-end
59
Hierarchical
Data Flow
Graph
Task Two:
Bulld System-Wide Information Flow Model
Task One:
Build System-Wide
Data Flow Graph
Information
Flow Model
Task Three:
GenerateSystem-Wide MAC Policy
System-WIde
MAC Policy
(DIFC-Flume)
MAC
Policies
Integrity
Requirements
+
Syste
m C
om
po
nen
ts
Penn State Systems and Internet Infrastructure Security Lab Page
Questions
60