Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Enforcing Security for Desktop Clients using Authority Aspects

Enforcing Security for Desktop Clients using Authority Aspects

AOSD 2009

E8600d16ba667cc8d7f00ddc9f254340?s=128

Brett Cannon

March 06, 2009
Tweet

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.