confined types encapsulation and modularity seminar november, 2005 presented by: guy gueta

29
Confined Types Encapsulation and modularity Seminar November, 2005 presented by: Guy Gueta

Post on 19-Dec-2015

226 views

Category:

Documents


4 download

TRANSCRIPT

Confined Types

Encapsulation and modularity Seminar November, 2005

presented by: Guy Gueta

Writing secure code

• Difficult task – A lot of security problems

• Software systems that permit untrusted and trusted code together – Loadable components

Object-oriented

• An objects can be pointed by many other objects

• Every method can be called by an adversary

• Defensive style – dynamic security checks– Performance problem– Bugs

• Protection domains

Protection domains

• Internal (without security checks) and external objects (with security checks)– The core code can be written without security checks

– Easier for security analysis (programmer, automatic)

• No means to enforce such a distinction– Access modifiers (visibility of methods and fields,

scope of types)

– Reference to sensitive objects may leak to other protection domains

Confined Types

• Prevent escaping of internal objects

• T is confined in D iff all references to instances of T are in D

• Enforce static scoping of dynamic object references– stronger than “private type”

Achieving confinement

• Static constraints on the definition and use of objects• Compile time (better performance, compilation errors)• Java

– Two additional modifiers (confined, anon)– Restrictions on programs

• Certain programming tasks may be clumsier

– Package = protection domain– Don’t affect the program semantics !– Modular (dynamic loading is possible)– Simple implementation

Security breach in JDK 1.1.1• Untrusted code can acquire extended access

rights

class java.lang.Class {

private Identity[] signers ;

public Identity[] getSigners()

{ return signers ; }

}

java.security.IdentityScope.IdentityScope.identities() = an enumeration of all identities known to the local system

• Simple fix: return a copy of the internal array

• Nothing guarantees that similar defects are not present in other parts of the package

• The attack doesn’t interact with Identity (‘private’ can’t help use)

• Confined types: References to identity objects will never escape from the java.security package

Anonymous Methods

• Do not depend on the identity of the current instance

• Behavior is determined by: arguments and fields

• Essential to allow confined types to inherit methods from unconfined parents

Anonymous Methods in Java

• anon

• Anonymous method does not invoke a non-anonymous method of the same object

Potential callers can rely on anonymity

Constructors are a special case of instance methodsConstructors may be declared anonymousExplicit and implicit calls are made only to anonymous constructorsThe Object constructor is anonymous by definition

Anonymous methods in existing code

Confined Types

Confinement in declarations

•C1 – confined types have private or package-local access

•The unnamed global package is open to extension

•All subtypes of a confined type are confined

Reference widening

• Each instance object can be stored in a object variable (java.lang.Object is not confined)

• Reference widening from a confined type to an unconfined supertype shouldn’t be allowed

// package oneclass A { …. }

// package two

confined class B extends A { ….}

A a = (A)(new B()); // a can leak out of package two

Reference widening

assignmentvar = expdec_type(var) > static_type(exp)

method callvoid method(A a)

method(exp)

A > static_type(exp)

returnA method () { ....

; return exp;}

A > static_type(exp)

cast (A)(new B)A > B

Collections

• Confined objects should not be stored in unconfined collections– For arrays:

if T is confined then T[] is confined– For the other collections: can’t cast to

java.lang.object

• Use confined collections

• Generics

Hidden Wideningclass A { protected void foo() { // store this }}

confined class B extends A{ public void boo() { foo(); ….; }}

• this can escape from the package• Solution: confined classed are not allowed

to inherit from non-trivial unconfined class• Better solution with anonymous methods....

class A { public void anon foo() { // …… }}

confined class B extends A{ public void boo() { foo(); }}

can be checked in the defining package

Preventing transfer from the outside

Can be omitted !?

Example: Public-Key Cryptography

Other Aspects

• Protection domain ≠ package

• Generics– Reduce the need for reference widening– Less code (public-key example)

• Software Engineering– “strong private”

• Optimizations

Summary

• We saw two new language mechanisms– Confined types– Anonymous methods

• Enforced by a set of simple syntactic constraints which can be verified statically

• Can be used for controlling the dissemination of object reference