Software Security II

1
Software Security II

• Karl Lieberherr

2
What is Security

• Enforcing a policy that describes rules for
  accessing resources.
• Policy may be explicit or implicit. Better to use
  explicit policy.

3
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?

4
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.

5
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.

6
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.

7
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.

8
A Logical Framework for Reasoning about Access
Control

• Elisa Bertino

9
Logical framework

• Models
• Role-based access control
• Reduction to C-Datalog

10
Basic components

• Subjects
• User
• Process execution of a program on behalf of user
• Group partial order
• Role partial order

11
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

12
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.

13
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

14
Formal Representation

• C-Datalog
• Object-oriented extension of Datalog

15
Brief introduction to C-Datalog
16
Extra slides
17
Java Security at IBM Research(Larry Koved
manager)

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

18
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?

19
LoD and security
20
(No Transcript)