confined types encapsulation and modularity seminar november, 2005 presented by: guy gueta
Post on 19-Dec-2015
226 views
TRANSCRIPT
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
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
Other Aspects
• Protection domain ≠ package
• Generics– Reduce the need for reference widening– Less code (public-key example)
• Software Engineering– “strong private”
• Optimizations