Transcript security.ppt

Information Flow, Security and
Programming Languages
Steve Zdancewic
What is Security?
• Resources?
• Protection?
• Trust & Integrity?
• Policy?
• Principals?
• Threats?
Information Flow
• Resource = Data
• Protection = Access Control
• Threat = Malicious Programs
– "leak" private information
• Policy? Principals? Trust?
Why Do We Want It?
• Untrusted code
– Applets/Plugins/Extensible
Systems
• E-Commerce & Privacy
• Shared Resources
– Files on a network
– Access Control (i.e. Unix
permissions) not enough
Outline
• Lattice-model
– Non-interference
• SLam
– Modeling
Dependency
– Extensions
• JFlow & Other
Approaches
• Conclusions
Principals & Privileges
• Associate security levels
with data
– Specifies who can "see" the data
• What happens when data is
merged? x = a +b
The Lattice Model
• Elements represent
levels of privilege
H
k4
k5
k6
k1
k2
k3
L
• k  k' is ordering
• k  k' is join
• Bell & LaPadula '75
Denning'75,'76,'77
Non-Interference
• Low security data can't
depend on high security data.
• No information flows from
high security values to low
security ones.
Explicit vs. Implicit
low := hi
if hi then
low := true
else
low := false
SLam
• Heintze & Riecke POPL '98
• Lambda Calculus
• Security annotations on types
• Well-typed programs have noninterference property
– Proof uses logical relations
Types
k  Security Lattice
t ::= b | s  s
s ::= (t, k)
Subtyping
k  k'
(b, k)  (b, k')
s3  s1 s2  s4 k  k'
(s1  s2, k)  (s3  s4, k')
SLam Expressions
bv ::= #t | #f | (lx:s. e)
v ::= bvk
e ::= x | v | (e e) | (protk e)
| (if e then e else e)
Typing Rules
G  #tk : (b, k)
G, x:s1  e : s2
G (lx:s1. e)k : (s1  s2, k)
Typing Rules II
(t, k')  k = (t, k'  k)
G e1 : (s1  s2, k)
G e2 : s1
G (e1 e2) : s2  k
Typing Rules III
G e : (b, k)
G ei : s
G if e then e1 else e2 : s  k
G e : s1
s1  s2
G e : s2
Typing Rules IV
G e : s
G protk e : s  k
Example
#tH : (b, H)
#fL : (b, L)
#tL : (b, L)
if #tH then #tL else #fL : (b, L)H
(b, L)H = (b, L  H) = (b, H)
Operational Semantics
((lx:s1. e)k e')  protk e[e'/x]
(if #tk then e1 else e2)  protk e1
protk bvk'  bvk  k'
Proving Non-interference?
• Suppose lattice is L  H
• Functions of the type:
(bH  bL bL)L
“look” like
a. a  b  b
Modeling “Views”
• Give a denotational semantics
for Slam
• Instead of just CPO’s, also
include binary relations to
capture the “view”
• Functions must preserve the
“view”
Binary Relations as Views
Concrete View
Abstract View
C #t
#t 1 0
#f 0 1
A #t
#t 1 1
#f 1 1
#f
#f
If (x,y)R then x and y
"look the same".
Semantics of Types
(b, k) = {#t, #f}
(s1 
s2, k) = s1 p s2
R(s, k) = "view of s at level k"
R(s, k)  s  s
View Relations
• Abstract View:
s = (t, k')
k'  k
R(s, k) = s  s
• Concrete View (bool):
k'  k
R((b,k'), k) = C
View Relations II
•Concrete view (functions)
k'  k
R((s1  s2, k'), k) =
{(f,g) | (x,y)R(s1,k).
(f(x),g(y)) R(s2  k',k)}
Adequacy
• Theorem (Plotkin):
If  e : s then  e : sh
is defined iff e *v.
Related Environments
• G = x1:s1, x2:s2, ... , xn:sn
G = s1  s2 ...  sn
• Theorem: Suppose G e : s and
h, h' G are related
environments at k, then
(G  e : s h, G  e : s h') R(s,k)
Contexts & Equivalence
• C[ ] is a context
(expression with hole)
• Write e  e' if whenever
e *v and e' *v'
it is the case that v=v'
• C[e]  C[e']
Non-interference
• Theorem:
Suppose   e1, e2 : (t, k) and
  C[e1] : (b,k') where k  k'
then C[e1]  C[e2].
let
s = (t,k)
Proof I
• Consider open term:
y:s  C[y] : (b,k')
• di =   ei : s()
• Lemma: Since k  k'
(d1, d2)  R(s, k')
Proof: R(s,k') is abstract.
Proof II
• fi = y:s  C[y] : (b,k') di
• By Related Environments
theorem, we have:
(f1, f2)  R((b,k'), k') = C
• Thus, f1= f2, easy to show that
fi =   v : (b,k') ()
since v v,we're done.
Recursion
• Need to show that R's are
"directed complete"
• Need to finesse termination
issues in contexts
– y:units  C[y ()] : (b,k')
• CBN vs. CBV
– Strong vs. Weak non-interference
Extending SLam
• Products, Sums, Recursive
Types (Pitts '96)
• State
– “No read up, no write down”
– Globally track dependency
• Integrity
– The more people who touch data,
the less trustworthy it is.
Core Calculus of Dependency
• Abadi, Banerjee, Heintze,
Riecke (POPL '99)
• Use type constructors Tk
• Can translate SLam, Bindingtime calculi, Smith&Volpano's
calculi, etc., into DCC.
Recap
• SLam provides language based
information-flow protection
• Non-interference proved by
logical relations
• ...but you wouldn't want to
program in it.
JFlow
• Myers (POPL ‘99)
• Emphasis on usable language
– Java extension
• Decentralized label model
– Very large, fine grained lattice
• Security level polymorphism
• First class labels,
principals
Threads & Concurrency
• Smith & Volpano (POPL '98)
– Simple, imperative language with
threads
– Can't loop on high-variables
– Assumes non-deterministic thread
scheduling
– Clock is high-security
– Subject to Probabilistic attacks
Non-Interference?
• Too strong:
– No encryption
– No password lookup
• Need declassification
– Everything ends up at H
• Hard to define in concurrent
setting
Alternatives?
• What you really care about is
leakage of "useful"
information?
...or...
• What you care about is the
rate of leakage of
information?
Problems
• Compilation in informationflow setting:
– Compiler should preserve flow
properties
– CPS translation/code-motion not
valid:
– f (if x then y else z) =
(if x then f(y) else f(z))
Covert Channels
• Threads/Concurrency
• Timing attacks
• Probabilistic attacks
• "Semantic" channels - i.e.
order of initialization,
aliasing
• and more...
Conclusions (Security)
• Information flow is a useful
tool for security.
• Non-interference is a strong
policy (too strong?)
• Programming language
technology can help
• Lots left to be done...
Conclusions (PL)
• Non-interference expressed in
terms of dependency
– Polymorphism, Binding Time
Analysis, Slicing
• Denotational techniques
useful
• Still lots to be done...