Скачать презентацию Analysis of Security Policies Scott D Stoller November Скачать презентацию Analysis of Security Policies Scott D Stoller November

596fed658503bba28c8b5fc33875edeb.ppt

  • Количество слайдов: 42

Analysis of Security Policies Scott D. Stoller November 2006 Analysis of Security Policies Scott D. Stoller November 2006

Where Is Stony Brook University (SBU)? Hawthorne SBU Manhattan November 2006 Where Is Stony Brook University (SBU)? Hawthorne SBU Manhattan November 2006

Overview of My Research Concurrency Optimistic partial-order reductions Inference of race-free types and atomicity 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

Motivation for Security Policy Analysis Problem: Security policies are often enforced by Humans (slow, 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

Outline Analysis of Security-Enhanced Linux (SELinux) Policies Analysis methods: rules, deductive spreadsheets Analysis of 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

Security-Enhanced Linux (SELinux) SELinux = Linux plus a kernel module that enforces security policies 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

SELinux Policies Run-time overhead of policy enforcement is low. Policy development is difficult. SELinux 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

Sample Analysis Queries Find all security contexts from which information can flow into shadow_t 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 writelike permission and execute permission. Such types are vulnerable to Root. Kit attacks. November 2006

Rule-Based Analysis Automatically translate policy into logic program in XSB. Use simple logic programs 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

Analysis with Deductive Spreadsheets (DSS) How to make the power of rules more widely 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 Open. Office. Security Applications: SELinux policy analysis, configuration vulnerability analysis (firewall policies, …). Joint work with C. R. Ramakrishnan, I. V. Ramakrishnan, and David Warren. November 2006

Outline Analysis of Security-Enhanced Linux (SELinux) Policies Analysis methods: rules, deductive spreadsheets Analysis of 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

Attribute-Based Access Control (ABAC) ABAC policy grants permission if some condition on attributes of 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 e. Xtensible Access Control Markup Language (XACML). XACML Technical Committee members: BEA, BMC Software, Booz Allen Hamilton, Computer Associates, Entrust, IBM, Oracle, Sun. November 2006

XACML Rules and Policies XACML defines XML formats for requests, responses (e. g. , 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

Sample Analysis Goals Check consistency of permit and deny rules. Check consistency (compare strictness) 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 R 1 is replaced with rule R 2, 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

External Data; Bounded Analysis Main challenge: Objects (employees, health records, bank accounts, course rosters, 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

Unbounded Analysis Convert the analysis problem to a first-order logical formula with equality, uninterpreted 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, Barce. Logic, 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

Outline Analysis of Security-Enhanced Linux (SELinux) Policies Analysis methods: rules, deductive spreadsheets Analysis of 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

Analysis of Administrative Policies Large organizations have large and complex policies. A single administrator 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

Analysis of Administrative Policies Sample analysis goal: Can administrators X and Y together modify 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

Administrative Policies for RBAC Administrative RBAC (ARBAC) [Sandhu+ 1997] involves Administrative roles (in addition 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 Project. Leader can add a user to Project. Member if the user is a member of Employee and is not a member of Auditor. November 2006

Analysis of Administrative Policies for RBAC Typical Analysis Problem: Can user u be assigned Analysis of Administrative Policies for RBAC Typical Analysis Problem: Can user u be assigned to role r by administrators in administrative roles ar 1, …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

User-Role Reachability No Restriction PSPACE-Complete NP-hard |pre| 1 R, |pre| 1, R Polynomial N User-Role Reachability No Restriction PSPACE-Complete NP-hard |pre| 1 R, |pre| 1, R Polynomial N |G| k, |pre| 1 CR, D, EI, |pre| 1 D, R CR, EN, |G| k, |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 |ppre|: Max number of positive literals in a precondition

Existence of Polynomial-Size Plan (EPP) EPP is false (plan generation is intractable) in the Existence of Polynomial-Size Plan (EPP) EPP is false (plan generation is intractable) in the following cases: No restriction |ppre| 1 D |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

Bounded Reachability (BRE) BRE: Reachability by plans of length at most k, where k 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

Outline Analysis of Security-Enhanced Linux (SELinux) Policies Analysis methods: rules, deductive spreadsheets Analysis of 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

Information Flow A security class indicates the level of secrecy and/or the level of 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 ≤ secret ≤ top secret Example: high. Integrity ≤ low. Integrity November 2006

Information Flow in Programs cause information flow. y : = x causes an explicit Information Flow in 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 security. Class(x) ≤ security. Class(y). Type systems can statically guarantee that all possible flows in a program are permissible. November 2006

Secure Flow Types [Volpano, Irvine, and Smith, 1996] Let τ range over security classes. 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

Information Flow Analysis as Type Inference Input: program p, and type environment λ for 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

Results Prototype generates 900 lines of Python from 27 rules. Automated complexity analysis shows 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

Thank You! November 2006 Thank You! November 2006

Outline Analysis of Security-Enhanced Linux (SELinux) Policies Analysis methods: rules, deductive spreadsheets Analysis of 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

Security Contexts and Information Flow Resource: file, process, socket, … Security context: security-relevant attributes 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 c 1 to security context c 2 is possible if a process in c 2 can read a resource in c 1, or a process in c 1 can write a resource in c 2. November 2006

Trust Management These analysis methods also provide a basis for analysis of trust management 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

Analysis of Trust Management Policies Statements may express authorization decisions or provide information (e. 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. consent. To. Treatment(doc) => Healing. Hospital. permit(doc, EPR(pat), Read) Challenge: Policy analysis with partial knowledge of other principals’ policies. November 2006

XACML: Example Rule and Request Rule: A patient may read his/her own medical record. 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: action. ID: read Effect: permit Condition: target. subject. patient. Number = resource. patient. Number November 2006 Request: Subject: name: John Doe patient. Number: 1123 Resource: med. com/records/Bart Simpson. xml Action: action. ID: read This is shorthand syntax.

XACML Architecture Resources Application Policy Enforce ment Point (PEP) Context Handler converts between application XACML Architecture Resources Application Policy Enforce ment Point (PEP) Context Handler converts between application format and XACML November 2006 PIP provides attribute values Policy Information Point (PIP) Context Handler Policy Repository Policy Access Point (PAP) Access request and response Attribute request and response Policy Decision Point (PDP)

Related Work for ARBAC Policy Analysis of a fixed policy: many papers Analysis of Related Work for ARBAC Policy Analysis of a fixed policy: many papers Analysis of a single change to a policy: [JR 04, FKMT 05] 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. [LS 77, Sandhu 88, Sandhu 92 typed]. [Li+ 2004] give polynomial analysis algorithms for two restricted versions of ARBAC 97, but do not consider negative preconditions or SMER constraints. November 2006

Expressing Type Inference in Rules The type inference rules define two relations: type(p, t): 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 e 1+e 2: arith(e, e 1, e 2), type(e 1, t 1), type(e 2, t 2) → type(e, t 1 t 2) 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

Other Inference Algorithms for Flow Types [Deng and Smith, 2006] present a similar type 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

From Rules to Efficient Algorithms We developed a method to compile rules into specialized, 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(X 1, X 2, Y) : - p 1(X 1, Y), p 2(X 2, Y). p 1(X 1, Y) : -. . . When second rule adds a fact (a, b) to p 1, we need to find the matching tuples (X 2, b) in p 2, in order to update r. Introduce an index: i(Y) = { X 2 | (X 2, Y) in p 2 } Generate code to incrementally maintain indices. November 2006

From Rules to Efficient Algorithms (2) Select an appropriate data structure for each set 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