Analysis of Security Policies
Scott D. Stoller
November 2006 1
Where Is Stony Brook University (SBU)?
Hawthorne
SBU
Manhattan
November 2006 2
Overview of My Research
Concurrency
Optimistic partial-order reductions
Inference of race-free types and atomicity types
Run-time detection of potential data races, deadlocks,
and atomicity violations
Incremental Computation
Incrementalization of functional, imperative, and OO
programs. Efficient implementation of Datalog.
Security
Verification of cryptographic protocols
Analysis of security policies
November 2006 3
Motivation for Security Policy Analysis
Problem: Security policies are often enforced by
Humans (slow, subject to social engineering, etc.)
Application code in Java, C++, etc. (hard to
understand, analyze, and maintain)
Goal: Express security policies in policy languages.
Easier to read, analyze (validate), and maintain
Enforced efficiently and automatically (except for
occasional manual override)
Example: Course grades
My research on policies: design of policy frameworks,
algorithms for analysis and enforcement of policies.
November 2006 4
Outline
Analysis of Security-Enhanced Linux (SELinux) Policies
Analysis methods: rules, deductive spreadsheets
Analysis of Attribute-Based Access Control (ABAC) and
Trust Management Policies
Lack of external data. Bounded / unbounded analysis.
Analysis of Administrative Policies
Relation to planning. Algorithms for tractable cases.
Information Flow Analysis
Efficient inference of flow types
November 2006 5
Security-Enhanced Linux (SELinux)
SELinux = Linux plus a kernel module that enforces
security policies expressed in SELinux’s policy language.
Implements mandatory access control: security
administrator imposes access-control policy that other
users cannot modify. More secure than traditional DAC.
Example: Apache config file can be modified only by
Apache executables executed by the user Apache Admin.
Example: fingerd can modify only a specified log file.
Integrated into mainline 2.6 Linux kernel in 2003.
In Fedora Core, RHEL, Hardened Gentoo, Debian, …
November 2006 6
SELinux Policies
Run-time overhead of policy enforcement is low.
Policy development is difficult.
SELinux developers created an example policy.
It is large (~ ten thousand lines) and low level.
It is being modularized (“targeted policy”).
Users will need to combine and customize policies for
different applications and services.
Determining whether an SELinux policy meets high-level
security goals is hard.
Security context of a resource is a tuple [type, role, user].
These are the security-critical attributes in SELinux.
November 2006 7
Sample Analysis Queries
Find all security contexts from which information can flow
into shadow_t (which contains sensitive information).
Does all information flow from a normal user's security
context to fixed_disk_device_t (raw disk access) pass
through fsadm_t (the filesystem administrator type)?
Check integrity of a proposed Trusted Computing Base
(TCB) for SELinux.
Automatically find all information flows into TCB.
Manually check whether each one is safe.
Find all file types for which some daemon type has a
write-like permission and execute permission.
Such types are vulnerable to RootKit attacks.
November 2006 8
Rule-Based Analysis
Automatically translate policy into logic program in XSB.
Use simple logic programs to query (ask questions about)
the policy.
Novices use a library of query templates.
Experts create new queries quickly in high-level lang.
Benefits:
Flexibility: full power of logic program for queries
Efficiency: XSB’s goal-directed evaluation with tabling
Queries on sample policy take a few seconds.
Diagnostics: XSB’s justifier helps explain result.
Joint work with Beata Sarna-Starosta.
November 2006 9
Analysis with Deductive Spreadsheets (DSS)
How to make the power of rules more widely accessible?
Deductive Spreadsheets extend the popular spreadsheet
paradigm with rules (logic programs).
A cell may contain a set (relation), number, string, …
Cell content may be defined by a rule, formula, …
Rules may be defined graphically (click-and-drag, …)
Developing prototypes based on Excel and OpenOffice.
Security Applications: SELinux policy analysis,
configuration vulnerability analysis (firewall policies, …).
Joint work with C.R. Ramakrishnan, I.V. Ramakrishnan,
and David Warren.
November 2006 10
Outline
Analysis of Security-Enhanced Linux (SELinux) Policies
Analysis methods: rules, deductive spreadsheets
Analysis of Attribute-Based Access Control (ABAC) and
Trust Management Policies
Lack of external data. Bounded / unbounded analysis.
Analysis of Administrative Policies
Relation to planning. Algorithms for tractable cases.
Information Flow Analysis
Efficient inference of flow types
November 2006 11
Attribute-Based Access Control (ABAC)
ABAC policy grants permission if some condition on
attributes of subject and resource hold.
Example: Course registration. Course grades.
Our ABAC policy language is based on first-order logic.
It also supports trust management (decentralized ABAC).
We have a translator from OASIS’s eXtensible Access
Control Markup Language (XACML).
XACML Technical Committee members: BEA, BMC
Software, Booz Allen Hamilton, Computer Associates,
Entrust, IBM, Oracle, Sun.
November 2006 12
XACML Rules and Policies
XACML defines XML formats for requests, responses
(e.g., permit, deny), rules, and policies.
An XACML rule contains:
Target: values of selected attributes of subject, resource,
action, and environment
Effect: permit or deny
Condition: a Boolean expression using the attributes
Example: subject.age > 16 and …
An XACML policy contains rules and policies and a
combining algorithm (e.g., deny-overrides) to combine
their effects.
November 2006 13
Sample Analysis Goals
Check consistency of permit and deny rules.
Check consistency (compare strictness) of policies.
Example: Each department can have its own policy, but
it must be at least as strict as the company-wide policy.
Check application-specific requirements, e.g., only users in
Dept. D with rank at least Y can access resource X.
Change impact analysis, e.g., if rule R1 is replaced with
rule R2, find all users that gain access to resource X.
In general ABAC languages, rules may define any relation
(not just permit/deny), and answers may depend on chains
of inferences involving attributes, delegations, …
November 2006 14
External Data; Bounded Analysis
Main challenge: Objects (employees, health records, bank
accounts, course rosters, …) and their attributes may be in
databases (XML, relational, …) that are non-existent or
unavailable.
Policy analysis should consider all possible values for this
external data.
Bounded Analysis:
Impose a bound on the size of the external data.
Convert the analysis problem to a Boolean formula
Use a SAT solver to find one (or more) answers.
November 2006 15
Unbounded Analysis
Convert the analysis problem to a first-order logical
formula with equality, uninterpreted types, and
uninterpreted functions.
Use a Satisfiability Modulo Theories (SMT) solver (CVC
Lite, BarceLogic, Yices, …) to find one or more answers.
We are investigating how to efficiently find and concisely
present all answers to a query: all inconsistencies, all
effects of a change, all violations of a requirement, etc.
Also underway: policy language and analysis support for
trust management for service-oriented architectures.
November 2006 16
Outline
Analysis of Security-Enhanced Linux (SELinux) Policies
Analysis methods: rules, deductive spreadsheets
Analysis of Attribute-Based Access Control (ABAC) and
Trust Management Policies
Lack of external data. Bounded / unbounded analysis.
Analysis of Administrative Policies
Relation to planning. Algorithms for tractable cases.
Information Flow Analysis
Efficient inference of flow types
November 2006 17
Analysis of Administrative Policies
Large organizations have large and complex policies.
A single administrator can’t manage the entire policy.
The primary administrator delegates partial control over
the policy to secondary administrators.
Examples: administrator for each department,
administrator for personnel records, …
Administrative policy: security policy that controls
changes to the security policy. It limits the changes that
each secondary administrator can make.
Analysis goal: Understand the power of groups of
(secondary) administrators, who may be less trusted than
the primary administrator.
November 2006 18
Analysis of Administrative Policies
Sample analysis goal: Can administrators X and Y together
modify the policy so that user U has permission P?
Analysis of administrative policies is hard, because it must
consider all policies reachable via allowed changes.
We studied administrative policy analysis for RBAC.
Role-Based Access Control (RBAC) in a nutshell:
Users are assigned to roles, e.g., doctor, nurse, patient.
Permissions are associated with roles.
A user has a permission if he is a member of some role
with that permission.
November 2006 19
Administrative Policies for RBAC
Administrative RBAC (ARBAC) [Sandhu+ 1997] involves
Administrative roles (in addition to regular roles), e.g.,
project admin, department admin, senior admin
Administrative permissions for adding and removing
users and permissions from regular roles, etc., provided
the pre-condition holds.
Separation of duty constraints: specified roles must be
disjoint.
Example: A member of ProjectLeader can add a user to
ProjectMember if the user is a member of Employee and is
not a member of Auditor.
November 2006 20
Analysis of Administrative Policies for RBAC
Typical Analysis Problem: Can user u be assigned to role r
by administrators in administrative roles ar1,…arn?
This problem is PSPACE-complete. It and variants are
NP-hard even with significant restrictions on the policy.
We identify some restrictions that make the problem
solvable in polynomial time, and give algorithms.
Several results were obtained by relating policy analysis to
the planning problem in Artificial Intelligence.
Future work: Develop general algorithms that scale well in
practice, by exploiting typical structure of policies.
Joint work with Amit Sasturkar, Ping Yang, and C.R.
Ramakrishnan.
November 2006 21
User-Role Reachability
No Restriction PSPACE-Complete
NP-Complete
NP-hard
|pre| 1 R R, |pre| 1,
Polynomial
|G| k, CR, D, EI, CR, EN, |G| k,
N D, R
|pre| 1 |pre| 1 |ppre| 1
N: No negation D: No disjunction R: No role revocation
|G|: Number of goals |pre|: Max number of literals in a precondition
CR: Users can be revoked unconditionally from all roles
EN: Negation used only in sep. of duty constraints EI: Empty initial policy
November 2006 22
|ppre|: Max number of positive literals in a precondition
Existence of Polynomial-Size Plan (EPP)
EPP is false (plan generation is intractable) in the following cases:
No restriction
D |ppre| 1 |G| 1 CR, D, EN,
|SMER(r)| 1
D, |ppre| 1, |G| 1
D: No disjunction |G|: Number of goals
|ppre|: Max number of positive literals in a precondition
|SMER(r)|: Max number of separation-of-duty constraints a role is in
CR: Users can be revoked unconditionally from all roles
EN: Negation used only in sep. of duty constraints
November 2006 23
Bounded Reachability (BRE)
BRE: Reachability by plans of length at most k, where k is part of the input.
Lemma: BRE is at least as hard as RE, for every problem class.
BRE is NP-hard in the following cases:
D, CR D, |ppre| 1 CR, |pre| 2
D, CR, |ppre| 2
D: No Disjunction |pre|: Number of literals in the preconditions
CR: Users can be revoked unconditionally from all roles
|ppre|: Number of positive literals in the preconditions
November 2006 24
Outline
Analysis of Security-Enhanced Linux (SELinux) Policies
Analysis methods: rules, deductive spreadsheets
Analysis of Attribute-Based Access Control (ABAC) and
Trust Management Policies
Lack of external data. Bounded / unbounded analysis.
Analysis of Administrative Policies
Relation to planning. Algorithms for tractable cases.
Information Flow Analysis
Efficient inference of flow types
November 2006 25
Information Flow
A security class indicates the level of secrecy and/or the
level of integrity of information.
Security classes ordered by ≤ form a lattice.
Flow is permitted from lower classes to higher classes.
Example: unclassified ≤ classified ≤ secret ≤ top secret
Example: highIntegrity ≤ lowIntegrity
November 2006 26
Information Flow in Programs
Programs cause information flow.
y := x causes an explicit flow from x to y.
if (x=1) then y := 1 else y := 0 causes an implicit flow
from x to y.
Each global variable is assigned a security class, reflecting
the kind of information that may be stored there.
Flow from x to y is permissible if
securityClass(x) ≤ securityClass(y).
Type systems can statically guarantee that all possible
flows in a program are permissible.
November 2006 27
Secure Flow Types
[Volpano, Irvine, and Smith, 1996]
Let τ range over security classes.
Each variable x is assigned a type of the form τ var.
x stores information with security class τ or lower.
Each expression e is assigned a type of the form τ.
e evaluates to information with security class τ or lower.
Each command c is assigned a type of the form τ cmd.
c assigns only to variables with type τ or higher.
Subtyping relation is based on security class ordering ≤.
Examples: unclassified secret
unclassified var secret var
secret cmd unclassified cmd // inverted!
November 2006 28
Information Flow Analysis as Type Inference
Input: program p, and type environment λ for selected
global variables.
Output: A typing for the program if one exists, otherwise
an informative error message.
Our Approach:
Express type inference as extended Datalog rules.
Compile the rules into efficient implementations, using
our general method [Liu & Stoller 2003]. The method
also generates formulas for time and space complexity.
Main ideas: Analyze rules to determine indices needed
for efficient inference. Generate code to incrementally
maintain indices. Data structures: nested arrays & lists.
November 2006 29
Results
Prototype generates 900 lines of Python from 27 rules.
Automated complexity analysis shows running time is
linear in program size.
Previous algorithm [Deng and Smith, 2006] is quadratic.
November 2006 30
Thank You!
November 2006 31
Outline
Analysis of Security-Enhanced Linux (SELinux) Policies
Analysis methods: rules, deductive spreadsheets
Analysis of Attribute-Based Access Control (ABAC) and
Trust Management Policies
Lack of external data. Bounded / unbounded analysis.
Analysis of Administrative Policies
Relation to planning. Algorithms for tractable cases.
Information Flow Analysis
Efficient inference of flow types
November 2006 32
Security Contexts and Information Flow
Resource: file, process, socket, …
Security context: security-relevant attributes of a resource,
namely, [Type, Role, User].
Sample types: fixed_disk_device_t, fs_adm_t, sshd_t,
httpd_sys_script_t, …
Information flow from security context c1 to security
context c2 is possible if
a process in c2 can read a resource in c1, or
a process in c1 can write a resource in c2.
November 2006 33
Trust Management
These analysis methods also provide a basis for analysis of
trust management policies.
Trust management is a framework for decentralized
management of security policies in large enterprises,
coalitions, and other organizations that lack globally
trusted administrators.
Essential features:
Each statement is associated with a principal, called its
source or issuer.
Each principal’s policy specifies which sources it trusts
for which kinds of statements, thereby delegating some
authority to those sources.
November 2006 34
Analysis of Trust Management Policies
Statements may express authorization decisions or provide
information (e.g., object attributes) needed to make those
decisions (e.g., membership of a task force, location of a
mobile device, …).
Example: Healing Hospital says “doc can access pat's
medical record if AMA says doc is a licensed doctor and
pat consents to treatment by doc."
AMA.doctor(doc) pat.consentToTreatment(doc) =>
HealingHospital.permit(doc, EPR(pat), Read)
Challenge: Policy analysis with partial knowledge of other
principals’ policies.
November 2006 35
XACML: Example Rule and Request
Rule: A patient may read his/her Request:
own medical record. Subject:
Target name: John Doe
Subject: any patientNumber: 1123
Resource:
Resource: med.com/records/Bart
namespace: med.com/record.xsd Simpson.xml
Action: actionID: read Action:
actionID: read
Effect: permit
Condition:
target.subject.patientNumber = This is shorthand syntax.
resource.patient.patientNumber
November 2006 36
XACML Architecture
Resources Policy
PIP provides Repository
attribute values
Policy
Policy
Information Policy
Enforce
Application Point Access
ment
(PIP) Point (PAP)
Point
(PEP)
Access request Policy
Context Handler Context and response Decision
Handler Point
converts between Attribute request
(PDP)
application format and response
and XACML
November 2006 37
Related Work for ARBAC Policy Analysis
Analysis of a fixed policy: many papers
Analysis of a single change to a policy: [JR04, FKMT05]
Analysis of sequences of changes to a policy:
Harrison et. al, presented an access control model based on
access matrices, and showed that the safety analysis problem
is undecidable for that model.
A number of access control systems were designed in which
safety analysis is more tractable, e.g. [LS77, Sandhu88,
Sandhu92typed].
[Li+ 2004] give polynomial analysis algorithms for two
restricted versions of ARBAC97, but do not consider
negative preconditions or SMER constraints.
November 2006 38
Expressing Type Inference in Rules
The type inference rules define two relations:
type(p,t): phrase p (expression or command) has type t.
error(loc): illegal information flow into location loc
The rules use several relations that represent the abstract
syntax tree of the program.
The rules propagate types bottom-up through expressions.
Example: e is e1+e2:
arith(e, e1, e2), type(e1, t1), type(e2, t2) → type(e, t1 t2)
The rules propagate types top-down through commands.
Care is needed to ensure we get the “best” (smallest) type
for each phrase. Details omitted.
November 2006 39
Other Inference Algorithms for Flow Types
[Deng and Smith, 2006] present a similar type inference
algorithm for a similar type system. Imperative style.
Time complexity is quadratic in size of program.
Our use of a higher-level language and a systematic
implementation method leads to a faster algorithm.
Type inference algorithms have been developed for other
secure flow type systems, under a variety of assumptions
and supporting a variety of language features.
Little info about worst-case or typical time complexity.
We plan to apply our method to type inference for richer
languages.
November 2006 40
From Rules to Efficient Algorithms
We developed a method to compile rules into specialized,
efficient algorithms and implementations. The method
also generates formulas for time and space complexity.
Optimal asymptotic time complexity for the given rules.
r(X1,X2,Y) :- p1(X1,Y), p2(X2,Y).
p1(X1,Y) :- ...
When second rule adds a fact (a,b) to p1, we need to find
the matching tuples (X2,b) in p2, in order to update r.
Introduce an index: i(Y) = { X2 | (X2,Y) in p2 }
Generate code to incrementally maintain indices.
November 2006 41
From Rules to Efficient Algorithms (2)
Select an appropriate data structure for each set and map.
Use nested structures, with nesting depth = arity of tuples.
To support associative access (membership test, image
computation), use nested arrays, allocated on demand.
To support iteration, use nested queues.
To support both, use nested arrays with queues linking
non-empty elements.
November 2006 42