Enforcing Security for Desktop Clients using Authority Aspects

AOSD 2009

Transcript

1. Enforcing Security for Desktop Clients using Authority Aspects Brett Cannon & Eric Wohlstadter (drifty|wohlstad)@cs.ubc.ca Software Practices Lab University of British Columbia
2. What is Authority? • “... the set of actions a process can cause to happen.” -- Stiegler04 • Goal is to protect the user from malicious or poorly implemented clients. • Static authority specified before application launch. • Dynamic authority granted during application execution.
3. Principle of Least Authority Static Authority Dynamically Needed Too Much Authority Dynamically Needed Static Authority Too Little Authority
4. What Could Go Wrong • Too much authority ... • Virus/worm/trojan opens a back-channel to report usage habits. • Accidental file deletion. • Too little authority ... • Application does not function as the user expects.
5. Principle of Explicit Authorization >> cp file1.txt file2.txt file1.txt file2.txt file3.txt file4.txt file5.txt file6.txt file7.txt file8.txt file9.txt fileA.txt
6. VM Security Now • Static policy file • Statically lists authority to grant. • permission java.io.FilePermission "img/-", "read"; • Security Manager • Mediator for all security-related accesses.
7. Typical Scenario Application Network or File System Security Manager Application Streams End User Application GUI Widgets Code Access Policy Add Permissions GUI Streams
8. Intuitive Idea: Authorizing Contexts >> cp file1.txt file2.txt execution(void main(String[])) && !cflow(call(* *.*(..))) && args(cmdArgs)
9. Research Problem • Do authorizing contexts cover all cases for dynamic authority? • Can the approach be generic enough to be reusable across disparate applications? • Cannot simply trust app developers to provide authorizing contexts on their own.
10. Example: RSSOwl Atom/RSS reader Written in Java + SWT 46,000 NCLOC http://www.rssowl.org/ Focus on Desktop Clients
11. Authorizing Context Examples for RSSOwl • Downloading feeds already subscribed to. •Read from configuration file. • Exporting feeds to a file. •File chooser in the GUI. • Clicking on a feed in a list. •Mouse input through the GUI.
12. What Can We Naively Add to the Security System?
13. Incessant Prompting Application Network or File System Security Manager Application Streams End User Application GUI Widgets Code Access Policy Add Permissions User Prompting Add Permissions g Add Per
14. Authority Aspects • Aspect security library that grants authority. • Capture URIs as they flow through the application. • Do not handle other cases/types. • Multi-prong approach to cover different types of I/O for an application. • Separates dynamic authorization from application implementation.
15. Technical Details • Authority aspects distributed as a jar that the user downloads. • User weaves aspect library with application to secure the application. • Application starts with no authority. • Authority derived at run-time from: • HTML, RSS, Atom, XML • HTTP, local disk • SWT, Swing
16. Types of I/O Handled • Disk & network • Ex: downloading feeds subscribed to. • GUI text • Ex: exporting feeds to a file. • Mouse input • Ex: clicking on a feed in a list.
17. Disk & Network I/O • Authorizing contexts • Reading a file from disk. • Downloading a file from a server. • Use a policy file specifying rules to apply to input for granting authority. • Separates concern of parsing I/O from disk or network for driving security decisions.
18. Dynamic Policy File Example document(configFile)/rssowl/favorites//link <rssowl><favorites><category> <category> <link> http://www.microsite.reuters.com/rss/topNews </link> </category></category><favorites></rssowl>
19. Adding Disk & Net I/O Application Network or File System Security Manager Application Streams End User Application GUI Widgets Aspects Add Permissions XPath Policy Code Access Policy Add Permissions User Prompting
20. Consequences of Approach • It’s safe because the policy file is readable by the user for auditing. • Authority is dynamically granted based on content of the input. • Common formats are handled generically. • Generically weave into application to handle disk and network I/O.
21. GUI Text I/O • Authorizing context when user specifies a resource as text through the GUI. • Clearly separates security from GUI.
22. Application Network or File System Security Manager Application Streams End User Application GUI Widgets Code Access Policy Add Permissions Aspects XPath Policy Aspects User Prompting Add Permissions Adding GUI Text Monitoring
23. Mouse Input • Clicking grants authority. • Hovering tells what authority will be granted by clicking. • Further separates security from GUI code.
24. Application Network or File System Security Manager Application Streams End User Application GUI Widgets Status Bar Aspects Aspects XPath Policy Code Access Policy Add Permissions User Prompting Add Permissions Adding Mouse Support End User Status Bar Add Permissions
25. Consequences of Approach • Text entered by user could be considered a URI to grant authority to access. • App Developer is untrusted. • Only provides mapping of mouse clicks to URIs. • User can hover to see what consequences their actions will have when clicking through status bar.
26. Our Contribution
27. Case Study • Do authorizing contexts cover all cases for dynamic authority? • Can the approach be generic enough to be reusable across disparate applications? • Color-coded results: • Generic approach. • App-specific solution. • Prompting required.
28. RSSOwl Case Study Authority Generic App- specific Unsupported Static 1 instance File/Net RSS, Atom RSSOwl GUI text FileChooser, Text Mouse Table Prompt 1 instance
29. Lobo Web browser Written in Java + Swing 61,000 NLOC http://www.lobobrowser.org/
30. Lobo Case Study Authority Generic App-specific Unsupported Static 5 instances File/Net HTML GUI text JFileChooser, JTextField Mouse HTMLLink, JMenuItem Prompt
31. Case Study Conclusions • Roughly half the cases were handled generically by our aspect library on its own. • Other half required input from app developer, which can be audited. • Only 1 instance found where our approach could not be applied, requiring prompting.
32. Related Work • Separate access control concern through AOP [DeWin01] • Add security to BPEL workflows [Charfi05] • Transform security DSL into Aspects [Mourad07] • Security vulnerability discovery [Haley04]
33. Conclusions • Principle of Least Authority can be added to an application. • Authorizing contexts capture join points where authority flows through an app. • Authority aspects capture authorizing contexts. • For two real-world applications, only one instance existed where dynamic authority could not be captured.