Software Security II

Karl Lieberherr

What is Security

• Enforcing a policy that describes rules for accessing resources.

• Policy may be explicit or implicit. Better to use explicit policy.

Security Goals

• Authentication– Who is it that is trying to do something to the

what we want to protect.– URL authentication: is yourFriendlyBank.com

really a friendly bank?

Security Criteria

• SALTZER, J. H., AND SCHROEDER, M. D. The protection of information in computer systems. Proceedings of the IEEE 63, 9 (Sept. 1975), 1278-1308.

Security Criteria derived from Saltzer/Schroeder

• Economy of mechanism Designs which are smaller and simpler are easier to inspect

and trust.

• Fail-safe defaults By default, access should be denied unless it is explicitly

granted.

• Complete mediation Every access to every object should be checked.

• Least privilege Every program should operate with the minimum set of

privileges necessary to do its job. This prevents accidental mistakes becoming security problems.

Security Criteria derived from Saltzer/Schroeder

• Least common mechanism Anything which is shared among different programs can

be a path for communication and a potential security hole, so as little data as possible should be shared. (LoD)

• Accountability The system should be able to accurately record ``who''

is responsible for using a particular privilege.

• Psychological acceptability The system should not place an undue burden on its

users.

Security criteria

• Performance • We must consider how our designs constrain system performance.

Security checks which must be performed at run-time will have performance costs.

• Compatibility • We must consider the number and depth of changes necessary to

integrate the security system with the existing Java virtual machine and standard libraries. Some changes may be impractical.

• Remote calls • If the security system can be extended cleanly to remote method

invocation, that would be a benefit for building secure, distributed systems.

A Logical Framework for Reasoning about Access Control

• Elisa Bertino

Logical framework

• Models– Role-based access control

• Reduction to C-Datalog

Basic components

• Subjects– User– Process: execution of a program on behalf of

user– Group: partial order– Role: partial order

Basic components

• Objects– Resources to be protected: partial order (has-a

relationships)

• Privileges– Access modes subjects can exercise on objects.– Partial order expressing strength between

privileges

Basic components

• Sessions– An instance of a connection of a user to a

system.

• Authorization rules– Exploit subjects, objects, privileges and session

attributes. Positive and negative.

Basic components

• Constraint rules– Cannot be violated by components of the

system.• Static

– Without taking into account the execution state

• Dynamic– Taking into account the execution state

Formal Representation

• C-Datalog

• Object-oriented extension of Datalog

Brief introduction to C-Datalog

• C-Datalog data model– Class and relation names– Class Schema– Inheritance– Object identifiers– Instances

Security Policies

• Sigma: set of access events.

• A policy is a set P subset Sigma* of finite sequences of access events.

• prefix(w) = set of all prefixes of w ={u in Sigma* s.t. uv = w}

• A policy is prefix closed: For all W in Sigma*: if w in P then prefix(w) subset P

Security Automaton

• Need to implement a security automaton (SA): Sigma (access events), Q (states), q0 (initial state), delta (transition function), delta: Q x Sigma -> Q

• An access event sequence is accepted if by an SA if a transition is defined for every event in the sequence.

Expressiveness

• The class of prefix closed security policies coincides with the set of security policies accepted by a security automaton.

Chinese Wall Policy

• Avoid conflict that may arise due to the unchecked flow of information across data sets belonging to competing parties

• O: set of data objects

• S: set of subjects

• G: set of data sets

• T: set of conflict of interest classes

Chinese Wall Policy

• Assign group(o) in G to every object in O

• Assign type(g) in G to each dataset g in G

• A subject s may access a data object o only if one of the following holds:– s has already accessed another object o’:

group(o) = group(o’)– Every object o’ that s has accessed:

type(group(o))!=type(group(o’))

Chinese Wall Policy

• Conflict set 1 oil companies: Oil company A (one group A1, A2, …) , Oil company B (another group B1, B2, … )

• Conflict set 2 banks: Bank UBS (one group UBS1, UBS2, … )

• (u,A1) ok; (u,A2) ok (same group); (u, UBS1) ok (different group and different type); B1 NOT OK (different group and same type)

Implement

• AspectJ

Extra slides

Java Security at IBM Research(Larry Koved: manager)

• Automating Security Analysis of Java Components and Programs– Invocation graphs

LoD and Security

• Can execute software only if secret is known.

• Secret consists of set of keys, one per class.• What is security policy? Each object only

gets keys of its authenticated friends (who share the same concerns???).

• What are the benefits of such a security policy? Compartmentalize?

LoD and security