1 / 27

From Trusted to Secure: Building and Executing Applications that Enforce System Security

From Trusted to Secure: Building and Executing Applications that Enforce System Security. Boniface Hicks, Sandra Rueda, Trent Jaeger, and Patrick McDaniel present by: panmeng. Outline. Background & Problem Architecture Implementation. Current security OS.

talli
Download Presentation

From Trusted to Secure: Building and Executing Applications that Enforce System Security

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. From Trusted to Secure:Building and Executing Applications that Enforce System Security Boniface Hicks, Sandra Rueda, Trent Jaeger, and Patrick McDaniel present by: panmeng

  2. Outline • Background & Problem • Architecture • Implementation

  3. Current security OS • Security Enhanced (SE)Linux,Trusted Solaris and TrustedBSD • Mandatory access controls (MAC) • multi-level security (MLS)

  4. MAC+MLS no read-up Flow permitted no write-down

  5. Label • OS resource----Object (file, socket, etc.) • Application----Subject Label: [user: role: type: MLS level range]

  6. Example-Logrotate • File labeled: system_u : object_r : user_t : s4 • Logrotate labeled: system_u : system_r : logrotate_t : s0-s1 • If logrotate accesses this file, LSM will stop it.

  7. File:s4 LSM access Stop Logrotate:s0

  8. log_file labeled: system_u : object_r : var_log_t : s1 • config_file labeled: system_u : object_r : config_t : s0 • Logrotate labeled: system_u : system_r : logrotate_t : s0-s1 • Now if logrotate read log file(s1), write configuration file(s0), system will not stop it. • But this really leak secrets stored in the log file to the publicly readable configuration file.

  9. Virtual write flow Violate Log File:s1 Config File:s0 LSM permit permit read write Logrotate:s0-s1

  10. Reason • The MAC OS just handles the security police outside the application, not within the application. • Enforce security only at the granularity of application inputs and outputs.

  11. motivation • Let the application to handle the labels internal. • Give the application not only the MSL range, but also the sensibility to the flow direction.

  12. Outline • Background & Problem • Architecture • Implementation

  13. Two requirement • Need a way to get/put labels from the OS to the application. • Need a mechanism to make sure the policy of the application is compliance with that of the OS.

  14. How can we pass operating system resources along with their labels into an application? • How can we pass application data along with their labels out into the operating system? • How can we be sure that the application will faithfully enforce the operating system’s policy on these labels?

  15. solution • 1. Extend OS API to export resource labels. • 2. Use security-typed language (Jif). Extend its runtime class to get labels from OS, and set its own labels in the application. • 3.security-typed language’s automated type analysis can ensure no leakage can occur through implicit or explicit flows when compiling. • 4. A compliance analyzer to check whether the policy in the application does not violate that in the OS.

  16. Process steps 0) Initial state The OS must have a MAC policy implementing some information flow security goals. 1) Program secure application An application developer provides the bytecode for a security-typed application along with a policy template that can be specialized by the user for a particular operating system configuration. (Jif/Pol). 2) Specialize application policy customized for different users running on different systems. 3) Invoke service invoke an operating system service to check the application for compliance with operating system security goals before running the application.

  17. Outline • Background & Problem • Architecture • Implementation

  18. SELinux • Jif/Pol • SIESTA(The Service for Inspecting and Executing Security-Typed Applications)

  19. First, extend the Runtime infrastructure of the Jif compiler with an interface to SELinux kernel 2.6.16 for getting and setting SELinux security contexts on network sockets and files.

  20. Second, constructed the Service for Inspecting and Executing Security-Typed Applications (SIESTA). This includes a system daemon along with an interface that can be run by the user; both were written in C. It also includes a policy compliance checker which was written written in XSB Prolog.

  21. Thirdly, utilize this infrastructure to build and test two demonstrative applications: • logrotate and JPmail.

  22. All possible flow for logrotate var_log_t:s2 var_log_t:s1 xserver_log_t:s1 logP Flow allowed configP config_t:s0

  23. Conclusion • Provide a way to monitor flow within application. • Security typed language is not mature. • For each application, there is a flow policy.—heavy work.

  24. Thanks

More Related