Analysis of Security Policies

1
Analysis of Security Policies
Scott D. Stoller
2
Where Is Stony Brook University (SBU)?
Hawthorne
SBU
Manhattan
3
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

4
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.

5
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

6
Security-Enhanced Linux (SELinux)

• SELinux Linux plus a kernel module that
  enforces security policies expressed in SELinuxs
  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,

7
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.

8
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.

9
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 XSBs goal-directed evaluation with
  tabling
• Queries on sample policy take a few seconds.
• Diagnostics XSBs justifier helps explain
  result.
• Joint work with Beata Sarna-Starosta.

10
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.

11
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

12
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 OASISs eXtensible
  Access Control Markup Language (XACML).
• XACML Technical Committee members BEA, BMC
  Software, Booz Allen Hamilton, Computer
  Associates, Entrust, IBM, Oracle, Sun.

13
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 gt 16 and
• An XACML policy contains rules and policies and a
  combining algorithm (e.g., deny-overrides) to
  combine their effects.

14
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,

15
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.

16
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.

17
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

18
Analysis of Administrative Policies

• Large organizations have large and complex
  policies.
• A single administrator cant 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.

19
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.

20
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.

21
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.

22
User-Role Reachability
No Restriction
PSPACE-Complete
NP-Complete
NP-hard
R
R, pre ? 1,
pre ? 1
Polynomial
G ? k, pre ? 1
CR, D, EI, pre ? 1
CR, EN, G ? k, ppre ? 1
N
D, R
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 ppre Max number of positive
literals in a precondition
23
Existence of Polynomial-Size Plan (EPP)

• EPP is false (plan generation is intractable) in
  the following cases

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
24
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, ppre ? 1
CR, pre ? 2
D, CR
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
25
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

26
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

27
Information Flow in Programs

• Programs cause information flow.
• y x causes an explicit flow from x to y.
• if (x1) 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.

28
Secure Flow TypesVolpano, Irvine, and Smith,
1996

• Let t range over security classes.
• Each variable x is assigned a type of the form t
  var.
• x stores information with security class t or
  lower.
• Each expression e is assigned a type of the form
  t.
• e evaluates to information with security class t
  or lower.
• Each command c is assigned a type of the form t
  cmd.
• c assigns only to variables with type t or
  higher.
• Subtyping relation ? is based on security class
  ordering .
• Examples unclassified ? secret
• unclassified var ? secret var
• secret cmd ? unclassified cmd // inverted!

29
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.

30
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.

31
Thank You!
32
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

33
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.

34
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 principals policy specifies which sources
  it trusts for which kinds of statements, thereby
  delegating some authority to those sources.

35
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(d
  oc) gt
• HealingHospital.permit(doc, EPR(pat), Read)
• Challenge Policy analysis with partial knowledge
  of other principals policies.

36
XACML Example Rule and Request

• Rule A patient may read his/her own medical
  record.
• Target
• Subject any
• Resource
• namespace med.com/record.xsd
• Action actionID read
• Effect permit
• Condition target.subject.patientNumber
  resource.patient.patientNumber

Request Subject name John Doe
patientNumber 1123 Resource med.com/records/Bart
Simpson.xml Action actionID read This is
shorthand syntax.
37
XACML Architecture
Policy Repository
Resources
PIP provides attribute values
Policy Information Point (PIP)
Policy Enforcement Point (PEP)
Policy Access Point (PAP)
Application
Context Handler
Policy Decision Point (PDP)
Access request and response
Context Handler converts between application
format and XACML
Attribute request and response
38
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.

39
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 e1e2
• 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.

40
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.

41
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.
• 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.

r(X1,X2,Y) - p1(X1,Y), p2(X2,Y). p1(X1,Y) -
...
42
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.