1 / 14

Towards Remote Policy Enforcement for Runtime Protection of Mobile Code Using Trusted Computing

This paper explores the use of trusted computing to enforce policies for runtime protection of mobile code, addressing the security challenges and solutions for both Type I and Type II security problems.

mariaphillips
Download Presentation

Towards Remote Policy Enforcement for Runtime Protection of Mobile Code Using Trusted Computing

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. Towards Remote Policy Enforcement for Runtime Protection of Mobile CodeUsing 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, 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 host’s 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 • 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 • Simple sandbox model • Sandboxing based on code sources, URL (where the code is downloaded, signature, etc. • JDK1.2: user & code attribute based model • User attributes—Java Authentication and Authorization services • Identity-based, role-based, group-based, general certificate-based, etc. • Augmented with local operating system’s access control policies

  4. Java Security • 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: • 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). • 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)

  6. Motivations for Mobile Policy for Type II Security • Enforce code originator’s policies when the code is remotely executing: • a shopping application carrying user’s 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 • Extensible and scalable policy definition • Policies can be reused, revoked and updated • Flexible policy management • Centralized or decentralize • Fine-grained policy specification based on users, target services, and system conditions

  7. Challenges and Solutions • Challenges: • Need trusted runtime environment to Enforce Mobile Policies • trusted by policy stakeholder (e.g., mobile code originator/owner) • Need policy enforcement mechanism with minimum changes in existing security architecture • 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

  8. Trusted Runtime Environment (TRE) • Trust Model: Integrity measurement and secure boot • TPM -> Secure Kernel -> JVM -> Mobile code & policy • 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 • PDP for trusted access control enforcement

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

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

  11. Policy Enforcement • Sun’s XACML library • PDP module • Evaluated XACML policy file with XMLPolicy class • Loading XACML policy file need local privilege in JVM • Access control algorithm • Stack-inspection mechanism <Policy PolicyId="makeorder-policy" <Subjects>… <AttributeValue DataType="string">OU=Org1</AttributeValue> <SubjectAttributeDesignator AttributeId="subject-id“ DataType="x500Name"/>… <AttributeValue DataType="string">PurchaseManager</AttributeValue> <SubjectAttributeDesignator AttributeId="subject-rolename" DataType="string"/>... </Subjects> <Resources>… <AttributeValue DataType="string">creditPermission</AttributeValue> <ResourceAttributeDesignator AttributeId="permission-name" DataType="string"/>… </Resources> <Actions> <Action>GET</Action><!-- "GET" represents the read privilege. --> </Actions> <Rule effect="permit"/> </Policy>

  12. Revocation • Revocation because of • Policy revocation • Trust revocation of a component in JVM • E.g., JAAS, access controller, XACML PDP • Trust revocation of a TRE • Trust revocation of a platform • 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 • Safe Interpreters • Saft-Tcl (J.K.Ousterhout et al ‘97) • Telescript/Odyssey (J.Tardo et al ‘96) • Runtime environment security • Code-signing • Sandbox (JDK 1.0) • Extended sandbox(JDK1.1, 1.2) • .Net CLR security • Proof-carry (P.Lee et al ‘97) • 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)

  14. Conclusions & Future Work • 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 • Runtime policy analysis engine • Dynamically derive policy info from multiple policy files • For decentralized policy definition and management • A comprehensive policy model

More Related