1 / 20

User-Driven Access Control Rethinking Permission Granting in Modern OSes

User-Driven Access Control Rethinking Permission Granting in Modern OSes. Franziska Roesner , Tadayoshi Kohno University of Washington Alexander Moshchuk , Bryan Parno , Helen J. Wang Microsoft Research Crispin Cowan Microsoft. Modern Client Platforms.

adelle
Télécharger la présentation

User-Driven Access Control Rethinking Permission Granting in Modern OSes

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. User-Driven Access ControlRethinking Permission Granting in Modern OSes Franziska Roesner, Tadayoshi Kohno University of Washington Alexander Moshchuk, Bryan Parno, Helen J. Wang Microsoft Research Crispin Cowan Microsoft

  2. Modern Client Platforms • iOS, Android, WP, Win8, browsers • Applications isolated from one another. • Limited global sharing. • Cannot access user-owned resources by default: • Cross-application data • Devices (camera, GPS, …) • Resources (clipboard, autocomplete data) Challenge: Users are in the loop to grant permissions. Problem: How should platforms grant applications access to user-owned resources? May 21, 2012 Franziska Roesner

  3. State of the Art Prompts (iOS, browsers) Manifests (Android, Windows Phone) Out of context: Checked at time of install, not time of use. Disruptive: In practice, only prompted at first use to avoid prompt-fatigue. Both are not least-privilege: Once granted permissions, apps can use them, even if not necessary for application functionality. May 21, 2012 Franziska Roesner

  4. Permission Granting Goals Let this application access my location now. May 21, 2012 Franziska Roesner • In context • Unlike manifests • Non-disruptive • Unlike prompts • Least privilege • Unlike manifests and prompts

  5. Outline • Motivation and Setup • User-Driven Access Control • via Access Control Gadgets (ACGs) • Capturing Authentic User Intent • Implementation • Evaluation May 21, 2012 Franziska Roesner

  6. User-Driven Access Control • Observation: A user’s natural UI actions in the context of an application carry permission-granting semantics. See also EWS [SVNC ‘04], NitPicker[FH ‘05], CapDesk[M ‘06], Qubes, Polaris [SKYCM ’06], UIBAC [SE ‘08], BLADE [LYPL ‘10]. • Challenge: How can the system understand generalized in-app permission-granting behaviors? May 21, 2012 Franziska Roesner

  7. Access Control Gadgets (ACGs) • Approach: Let the system control these UI elements (ACGs) to capture a user’s permission granting intent. • Challenges: • How can system capture authentic user intent? • How to prevent disruption of applicationcontext? • Can this model support necessaryapp functionality? • …? May 21, 2012 Franziska Roesner

  8. User’s View System’s View Isolation container Photo Editor App Camera Resource Monitor Photo Editor App Policy: Which app can access camera in what fashion <object src= “rm://camera/takePicture”/> Camera ACG ACG 2) Take picture 3) Receive picture 1) User clicks on camera ACG Kernel May 21, 2012 Franziska Roesner

  9. Design Challenges • What are appropriate access semantics? • How to accurately capture user intent? • How can we support: • customized access control gadgets? • ACGs composing multiple resources? • shortcuts and gestures instead of visual gadgets? • How can we generalize to application-controlled resource monitors? • e.g., Facebook contacts, Flickr photos May 21, 2012 Franziska Roesner

  10. Access Semantics One time: UI-coupled Least privilege Session: Scheduled: UI- decoupled Permanent: Permanent Access Few applications (5% of top 100 Android apps) legitimately require permanent access. May 21, 2012 Franziska Roesner

  11. Outline • Motivation and Setup • User-Driven Access Control • via Access Control Gadgets (ACGs) • Capturing Authentic User Intent • Implementation • Evaluation May 21, 2012 Franziska Roesner

  12. Threats by Malicious Applications • Manipulateaccess control gadgetdisplay • Directly or by strategic obstruction • Clickjacking(trick users into clicking on ACG) • Visual or timing-based • Programmatically click on ACG Requirements: 1. ACG  User: Authentic display of ACG to user. 2. User  ACG:Authentic user actions to ACG. May 21, 2012 Franziska Roesner

  13. ACG  User: Display Integrity 73% of top Android apps need only limited customization. (1) Display isolation: Apps can’t set ACG’s pixels. (2) Complete visibility: ACGs are activeonly when completely visible. (3) Sufficient display duration: ACGs activate only after a reaction delay. (4) Limited customization by applications. May 21, 2012 Franziska Roesner

  14. User  ACG: Authentic Input (1) Input event isolation: • Input events dispatched only from user input devices to ACGs. (2) The kernel controls the cursor over ACGs. (3) Handling nested applications • e.g., iGoogle embeds ad which embeds camera ACG • Must grant permissions to correct application. May 21, 2012 Franziska Roesner

  15. Outline • Motivation and Setup • User-Driven Access Control • via Access Control Gadgets (ACGs) • Capturing Authentic User Intent • Implementation • Evaluation May 21, 2012 Franziska Roesner

  16. Implementation • Implemented as part of the ServiceOS system with 2500 lines of C# code. • System support for: • Access control gadgets • Resources: camera, GPS, clipboard, autocomplete • Access semantics: one-time, session • ACG composition: camera+GPS • Input sequences: copy-and-paste, drag-and-drop • Nested applications • Content picking and application-specific ACGs • ACGs in applications: browser and MS Word Our experience shows that the implementation effort is modest for both system developers and application developers. May 21, 2012 Franziska Roesner

  17. Outline • Motivation and Setup • User-Driven Access Control • via Access Control Gadgets (ACGs) • Capturing Authentic User Intent • Implementation • Evaluation May 21, 2012 Franziska Roesner

  18. Discussion: Security Analysis Our User  ACG and ACG  User properties do not prevent applications from gaining unauthorized access by social engineering attacks. • Social engineering risk:moderate • (high effort/risk for attacker) • Usability:high • Least-privilege guarantees:high X X Location access granted May 21, 2012 Franziska Roesner

  19. Evaluation Highlights • Vulnerability Study • User-driven access control addresses most published vulnerabilities related to resource access: 36 of 44 in Chrome (82%), and25 of 26 in Firefox (96%). • User Expectations • Based on survey showing Android screenshots, most users already believe (52% of 186) – and/or desire (68%) – that resource access follows the user-driven access control model. May 21, 2012 Franziska Roesner

  20. Summary • User-driven access control captures a user’s permission-granting intent from natural interactions with the system and applications. • Access control gadgets enable user-driven permission granting. • In-context, non-disruptive, and least-privilege. • ACGs match user expectations. May 21, 2012 Franziska Roesner

More Related