1. Towards Remote Policy Enforcement for Runtime Protection of Mobile Code Using Trusted Computing Xinwen Zhang Francesco Parisi-Presicce Ravi Sandhu www.list.gmu.edu George Mason University IWSEC 2006

2. Mobile Codes and Agents programs that migrate and execute at remote hosts, so that the execution environments are different for different instances –Downloaded executables, –Downloaded executables, Java applet, ActiveX components, Servlet/EJB components, etc. Two types of security problems: – –Type I: Protect a local host (where a mobile code is executing) resources to prevent malicious access from mobile code Protect hosts files/dirs, sockets, memory space, etc. – –Type II: Protect mobile applications from malicious hosts Sensitive information/functions with mobile codes

3. Security in Type I Runtime policy enforcement on local host Runtime policy enforcement on local host –Common Language Runtime (CLR) and Java Runtime Environment (JRE) –Policies are based on attributes of codes and users JDK1.0/1.1: code-identity based model JDK1.0/1.1: code-identity based model –Simple sandbox model –Sandboxing based on code sources, URL (where the code is downloaded, signature, etc. JDK1.2: user & code attribute based model JDK1.2: user & code attribute based model –User attributesJava Authentication and Authorization services Identity-based, role-based, group-based, general certificate-based, etc. Identity-based, role-based, group-based, general certificate-based, etc. –Augmented with local operating systems access control policies

4. Java Security Sample policies: granting permissions based on: Sample policies: granting permissions based on: –Code URL –Code signature –Solaris authenticated principal name –Kerberos authenticated Principal name

5. Mechanism Initial steps for security check in JVM: Initial steps for security check in JVM: –Type safety checks for language by Verifier –Classloader loads bytecode and check signatures and code source –Construct security policy in terms of protection domain –Class is defined and public available to run in JRE Every time the class tries to access a system resources, its permissions are checked by security manager (or access controller). Every time the class tries to access a system resources, its permissions are checked by security manager (or access controller). Stack inspection mechanism is used in access controller to enforce security policy Stack inspection mechanism is used in access controller to enforce security policy –Rights of a piece of code is a function of the state of the execution stack. Same mechanism is applied in.Net (stack walk) Same mechanism is applied in.Net (stack walk)

6. Motivations for Mobile Policy for Type II Security Enforce code originators policies when the code is remotely executing: – –a shopping application carrying users sensitive information while running in a remote site. The code originator may require that the code can only run in a specific protected domain, and the user who runs this code must have a specific role in an organization, or some other credentials. Enforce enterprise-wide security policies for codes deployed in many platforms within an enterprise Enforce enterprise-wide security policies for codes deployed in many platforms within an enterprise –Extensible and scalable policy definition Policies can be reused, revoked and updated Policies can be reused, revoked and updated –Flexible policy management Centralized or decentralize Centralized or decentralize –Fine-grained policy specification based on users, target services, and system conditions

7. Challenges and Solutions Challenges: Challenges: –Need trusted runtime environment to Enforce Mobile Policies trusted by policy stakeholder (e.g., mobile code originator/owner) trusted by policy stakeholder (e.g., mobile code originator/owner) –Need policy enforcement mechanism with minimum changes in existing security architecture Solutions: Solutions: –Trusted computing enabled runtime environment –Leveraging stack-based security check by dynamically loading external policy file Viable with the separation of policy definition and enforcement in JVM Viable with the separation of policy definition and enforcement in JVM

8. Trusted Runtime Environment (TRE) Trust Model: Integrity measurement and secure boot Trust Model: Integrity measurement and secure boot –TPM -> Secure Kernel -> JVM -> Mobile code & policy Primitive functions of TRE: Primitive functions of TRE: –Integrity measurement and attestation response of mobile code & policy from code originator –Integrity measurement and attestation of security components: JAAS for trusted user authentication JAAS for trusted user authentication PDP for trusted access control enforcement PDP for trusted access control enforcement

9. Mobile Policy Specification Logically, each code is associated with one policy file Logically, each code is associated with one policy file XACML policy specification: XACML policy specification: –Extensible policy specification language –Support policy composing and derivation <Policy PolicyId="(policy-name)" PolicyCombinationAlg="rule-combining-algorithm:permit-overrides"> (predicates over subject attributes) (predicates over object attributes) (predicates over access rights such as read and write) (Specification that this policy is positive) (Specification of attribute-update actions)

10. Policy Model Subject attributes: Subject attributes: –Identity, role, Group, Clearance level –General credentials Objects Objects –Sensitive information presented and accessed by mobile code Components, classes, methods, variables Components, classes, methods, variables permissions permissions –Initialization components and classes –invoke methods –Access (read/write) variables

11. Policy Enforcement Suns XACML library Suns XACML library PDP module PDP module –Evaluated XACML policy file with XMLPolicy class –Loading XACML policy file need local privilege in JVM Access control algorithm Access control algorithm –Stack-inspection mechanism <Policy PolicyId="makeorder-policy" … OU=Org1 … PurchaseManager... … creditPermission … GET

12. Revocation Revocation because of Revocation because of –Policy revocation –Trust revocation of a component in JVM E.g., JAAS, access controller, XACML PDP E.g., JAAS, access controller, XACML PDP –Trust revocation of a TRE –Trust revocation of a platform Two approaches: Two approaches: –Push: code owner sends updated policy to client side –Pull: client side checks policy update whenever loads a code –Both may have delayed revocation –Instant revocation needs centralized policy server

13. Related Work Protection of local host against malicious code Protection of local host against malicious code –Safe Interpreters Saft-Tcl (J.K.Ousterhout et al 97) Saft-Tcl (J.K.Ousterhout et al 97) Telescript/Odyssey (J.Tardo et al 96) Telescript/Odyssey (J.Tardo et al 96) –Runtime environment security Code-signing Code-signing Sandbox (JDK 1.0) Sandbox (JDK 1.0) Extended sandbox(JDK1.1, 1.2) Extended sandbox(JDK1.1, 1.2).Net CLR security.Net CLR security –Proof-carry (P.Lee et al 97) Protection of mobile code against malicious host Protection of mobile code against malicious host –Secure coprocessor (B.Yee, 1994) –Encrypted function. (J. Algesheimer et al 01) Trusted JVM (Halder et al 04) Trusted JVM (Halder et al 04)

14. Conclusions & Future Work A mobile policy framework to protect mobile code from execution host A mobile policy framework to protect mobile code from execution host –A policy model –A trusted runtime environment –Policy enforcement mechanisms with XACML and Sun PDP module Future Work Future Work –Runtime policy analysis engine Dynamically derive policy info from multiple policy files Dynamically derive policy info from multiple policy files For decentralized policy definition and management For decentralized policy definition and management –A comprehensive policy model