Computer security
Goal: prevent bad things from happening
PLDI’06 Tutorial T1: Clients not paying for services Enforcing and Expressing Security Critical service unavailable with Programming Languages Confidential information leaked Important information damaged
System used to violate laws (e.g., copyright) Andrew Myers Conventional security mechanisms aren’t Cornell University up to the challenge http://www.cs.cornell.edu/andru
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 2
Harder & more important Language-based security
In the ’70s, computing systems were isolated. Conventional security: program is black box
software updates done infrequently by an experienced Encryption administrator. Firewalls you trusted the (few) programs you ran. System calls/privileged mode physical access was required. Process-level privilege and permissions-based access control crashes and outages didn’t cost billions. The Internet has changed all of this. Prevents addressing important security issues: Downloaded and mobile code we depend upon the infrastructure for everyday services you have no idea what programs do. Buffer overruns and other safety problems
software is constantly updated – sometimes without your knowledge Extensible systems or consent. Application-level security policies a hacker in the Philippines is as close as your neighbor. System-level security validation everything is executable (e.g., web pages, email). Languages and compilers to the rescue!
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 3 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 4
Outline
The need for language-based security Security principles Security principles Security properties Memory and type safety Encapsulation and access control Certifying compilation and verification Security types and information flow
Handouts: copy of slides Web site: updated slides, bibliography www.cs.cornell.edu/andru/pldi06-tutorial
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 5
1 Conventional OS security Access control model
Model: program is black box The classic way to prevent “bad things” Program talks to OS via protected from happening interface (system calls) Requests to access resources (objects) Multiplex hardware are made by principals Isolate processes from each other Restrict access to persistent data (files) Reference monitor (e.g., kernel) permits or + Language-independent, simple, limited denies request User-level Program Hardware request Reference Object memory Principal Monitor (Resource) Operating System protection Kernel
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 7 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 8
Authentication vs. Authorization 1st guideline for security
Abstraction of a principal divides Principle of complete mediation: enforcement into two parts Every access to every object must be checked by
Authentication: who is making the request the reference monitor
Authorization: is this principal allowed to make this request? Problem: OS-level security does not support complete mediation
request Reference Object Principal Monitor (Resource)
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 9 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 10
OS: Coarse-grained control Need: fine-grained control
Operating system enforces security at Modern programs make security decisions system call layer with respect to application abstractions UI: access control at window level Hard to control application when it is not making system calls mobile code: no network send after file read E-commerce: no goods until payment Security enforcement decisions made with intellectual property rights management regard to large-granularity objects Need extensible, reusable mechanism for Files, sockets, processes enforcing security policies Coarse notion of principal: Language-based security can support an extensible protected interface, e.g., Java security If you run an untrusted program, should the authorizing principal be “you”?
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 11 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 12
2 2nd guideline for secure design Least privilege problems
Principle of Least Privilege: each principal OS privilege is coarse-grained: user/group is given the minimum access needed to Applications need finer granularity Web applications: principals unrelated to OS principals accomplish its task. [Saltzer & Schroeder Who is the “real” principal? ‘75] Trusted program? Full power of the user principal Examples: Untrusted? Something less Trusted program with untrusted extension: ? + Administrators don’t run day-to-day tasks as root. So Untrusted program accessing secure trusted subsystem: ? “rm –rf /” won’t wipe the disk. Requests may filter through a chain of programs - fingerd runs as root so it can access different users’ or hosts .plan files. But then it can also Loss of information is typical “rm –rf /”. E.g., client browser → web server → web app → database
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 13 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 14
3rd guideline: Small TCB Small TCB and LBS
Trusted Computing Base (TCB) : Conventional wisdom (c. 1975): components whose failure compromises “operating system is small and simple, compiler is the security of a system large and complex” OS is a small TCB, compiler a large one Example: TCB of operating system includes kernel, memory protection system, disk image c. 2003: OS (Win2k) = 50M lines code, compiler ~ 100K lines Small/simple TCB: code ⇒ TCB correctness can be checked/tested/reasoned about more easily ⇒ more likely to work Hard to show OS implemented correctly Many authors (untrustworthy: device drivers) Large/complex TCB: Implementation bugs often create security holes ⇒ TCB contains bugs enabling security violations Problem: modern OS is huge, impossible to verify Can now prove compilation, type checking correct Easier than OS: smaller, functional, not concurrent
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 15 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 16
The Gold Standard [Lampson] When to enforce security
Authenticate Possible times to respond to security Every access/request associated with correct principal violations: Authorize Before execution: Complete mediation of accesses analyze, reject, rewrite Audit During execution: Recorded authorization decisions enable after-the-fact monitor, log, halt, change enforcement, identification of problems After execution: roll back, restore, audit, sue, call police Language-based techniques can help
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 17 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 18
3 Language-based techniques Maturity of language tools A complementary tool in the arsenal: programs don’t have Some things have been learned in the last 25 to be black boxes! Options: years… How to build a sound, expressive type system 1. Analyze programs at compile time or load time to that provably enforces run-time type safety ensure that they are secure ⇒ protected interfaces 2. Check analyses at load time to reduce TCB Type systems that are expressive enough to 3. Transform programs at compile/load/run time so that encode multiple high-level languages they can’t violate security, or to log actions for auditing. ⇒ language independence How to build fast garbage collectors ⇒ trustworthy pointers On-the-fly code generation and optimization ⇒ high performance
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 19 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 20
Caveat: assumptions and abstraction
Arguments for security always rest on assumptions: “the attacker does not have physical access to the hardware” “the code of the program cannot be modified during execution” A sampler of attacks “No one is monitoring the EM output of the computer” Assumptions are vulnerabilities Sometimes known, sometimes not Assumptions arise from abstraction security analysis only tractable on a simplification (abstraction) of actual system Abstraction hides details (assumption: unimportant)
Caveat: language-based methods often abstract aspects of computer systems Need other runtime, hardware enforcement mechanisms to ensure language abstraction isn’t violated—a separation of concerns
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 21
Attack: buffer overruns Execute-only bit? Payload Stack smashing executes code on stack -- mark char buf[100]; Return address stack non-executable? … gets(buf); Return-to-libc attack defeats this: void system(char * arg) { buf ... Program r0 = arg; execl(r0, ...); // “return” here with r0 set sp Stack ... } Attacker gives long input that overwrites function return address, local variables Not all dangerous code lives in the code segment… More attacks: pointer subterfuge (function- and “Return” from function transfers control to payload code data-pointer clobbering), heap smashing, overwriting security-critical variables… Moral: SEGVs can be turned into attacks
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 23 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 24
4 Attack: format strings Attack: SQL injection
fgets(sock, s, n); Web applications typically construct SQL … database queries.
fprintf(output, s); In PHP: $rows=mysql query("UPDATE users SET pass=‘$pass’ WHERE userid=‘$userid’”); Attack: pass string s containing a %n Attacker uses userid of ‘ OR ‘1’ = ‘1’. Effect: qualifier (writes length of formatted input UPDATE users SET pass=
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 25 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 26
Using system subversion 1988: Morris Worm
Assume attacker can run arbitrary code Penetrated an estimated 5 to 10 percent of (possibly with dangerous privileges) the 6,000 machines on the internet. Initial foothold on target system enables Used a number of clever methods to gain additional attacks (using other holes) access to a host. brute force password guessing Worms: programs that autonomously bug in default sendmail configuration attack computers and inject their own code X windows vulnerabilities, rlogin, etc. into the computer buffer overrun in fingerd Remarks: Distributed denial of service: many System diversity helped to limit the spread. infected computers saturate target network “root kits” for cracking modern systems are easily available and largely use the same techniques.
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 27 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 28
1999: Love Bug & Melissa Why did it succeed?
Both email-based viruses that exploited: Visual Basic scripts invoked transparently upon a common mail client (MS Outlook) opening trusting (i.e., uneducated) users Run with full privileges of the user VB scripting extensions within messages to: lookup addresses in the contacts database Kernel doesn’t know about fine-grained send a copy of the message to those contacts application abstractions or related security Melissa: hit an estimated 1.2 million machines. issues: mail messages, contacts database, etc.
Love Bug: caused estimated $10B in damage. Recipients trusted the sender – after all, they Remarks: know them no passwords or crypto involved Interactions of a complex system were unanticipated
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 29 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 30
5 A solution for Melissa? 2002: MS-SQL Slammer worm
Turn off all executable content? Jan. 25, 2002: SQL and MSDE servers on
no problem when email was just text. Internet turned into worm broadcasters
but executable content is genuinely useful. Buffer-overrun vulnerability
ex: automated meeting planner agent, postscript, Mpeg4 codecs, Spread to most vulnerable servers client-side forms, etc. on the Internet in less than 10 min!
US DoD tried to do this : revolt Denial of Service attack Fundamental tension: Affected databases unavailable modern software wants to be open and extensible. Full-bandwidth network load ⇒ widespread service outage
programmable components are ultimately flexible. “Worst attack ever” – brought down many sites, not Internet Postscript, Emacs, Java[script], VB, Jini, ActiveX, plug-n-play... Can’t rely on patching! security wants things to be closed: least privilege. Infected SQL servers at Microsoft itself turning off extensibility is a denial-of-service attack. Owners of most MSDE systems didn’t know they were running it…extensibility again
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 31 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 32
Virus scanning?
Scan for suspicious code e.g., McAfee, Norton, etc. Security Properties based largely on a lexical signature.
the most effective commercial tool
but only works for things you’ve seen Melissa spread in a matter of hours
virus kits make it easy to disguise a virus “polymorphic” viruses Doesn’t help with worms
Unless you can generate a filter automatically…
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 33
Security properties Security policies
Execution (trace) of a program is a sequence of states s1s2s3… encountered during execution Program has a set of possible executions T Security = “bad things don’t happen” A generic formalization: security policy is a predicate P on sets of executions Program satisfies policy if P(T) What kinds of properties Examples: should computing systems satisfy? P(T) if no null pointer is deferenced in any trace in T P(T) if every pair of traces in T with the same initial value for x have the same final value for y
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 35 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 36
6 Safety properties Liveness properties
“Nothing bad ever happens” “Something good eventually happens” A property is a policy that can be enforced using If P’(t) does not hold, every finite sequence t can be individual traces extended to satisfy P’ P(T) ⇔ ∀t∈T. P’(t) where P’ is some predicate on traces Example: nontermination Safety property can be enforced using only “The email server will not stop running” history of program Violated by denial of service attacks If P’(t) does not hold, then all extensions of t are also bad Amenable to run-time enforcement: don’t need to know future Can’t enforce purely at run time Examples: Interesting properties often involve both access control (e.g. checking file permissions on file open) safety and liveness memory safety (process does not read/write outside its own memory space) Every property is the intersection of a safety property type safety (data accessed in accordance with type) and a liveness property [Alpern & Schneider]
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 37 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 38
Memory safety and isolation Control-flow integrity
Process isolation: running process cannot Actual control flow must conform to a “legal access memory that does not belong to it execution”
Usually enforced by hardware TLB Code injection attacks violate CFI. TLB caches virtualphysical address mappings Invalid virtual addresses (other processes) cause kernel trap Weak: control can only be transferred to legal Cross-domain procedure calls/interprocess communication program code points (RPC/IPC) expensive (TLB misses) Rules out classic buffer overrun attacks Memory safety: running process does not Not provided by C: attempt to dereference addresses that are not int (*x)() = (int(*)()) 0xdeadbeef; (*x)(); valid allocated pointers Stronger: control must agree with a DFA or CFG
No read from or write to dangling pointers capturing all legal executions Not provided by C, C++ : Can be enforced cheaply by dynamic binary int *x = (int *)0x14953300; *x = 0x0badfeed; rewriting as in DynamoRIO [Kiriansky et al., 2002]
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 39 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 40
Type safety Access control
Values manipulated by program are used in Access control decision: accordance with their types principal × request × object → boolean Stronger than memory safety! Access control matrix [Lampson]: Can be enforced at run-time (Scheme), compile- objects time (ML), mix (Java) principals file1 file2 file3 user1 r rw rx Abstract data types: data types that can only be accessed through a limited interface user2 r r user3 rw r can protect their internal storage (private data) Allowed requests Kernel = ADT with interface = system calls, Columns of matrix: access control lists (ACLs) abstraction barrier enforced at run time by Correct enforcement is a safety property
hardware Safety can be generalized to take into account denial of access, corrective action by reference monitor [Hamlen][Ligatti][Viswanathan]
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 41 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 42
7 Information security Information security: confidentiality
Sometimes computer security is an aspect Confidentiality: valuable information should not of physical security be leaked by computation.
Make sure attackers cannot take over electric power distribution grid, military command-and-control, etc.
Can use type safety, access control to enforce rules Also known as secrecy, though sometimes a What we’re trying to protect can also be distinction is made: the information on the computer: Secrecy: information itself is not leaked information security Confidentiality: nothing can be learned about information
Memory safety, type safety don’t directly help Simple (access control) version: Only authorized processes can read from a file But… when should a process be “authorized” ?
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 43 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 44
Confidentiality: a Trojan horse End-to-end confidentiality
Access control controls release of data Access control does not help after access but does not control propagation control check is done End-to-end confidentiality: Security violation even ? Information should not be improperly released A B with “safe” operations ... by a computation no matter how it is used
personal.txt Enforcement requires tracking information flow % ls -l personal.txt Encryption provides end-to-end secrecy—but prevents most computation rw------personal.txt more % more personal.txt ... output device
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 45 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 46
Information security: integrity Privacy and Anonymity
Integrity: valuable information should not be Anonymity: damaged by computation individuals (principals) and their actions cannot be Simple (access control) version: linked by an observer Only authorized processes can write to a file alt: identity of participating principals cannot be But… when should a process be “authorized” determined even if actions are known End-to-end version: Information should not be updated on the basis of less Privacy: encompasses aspects of trustworthy information confidentiality, secrecy, anonymity Requires tracking information flow in system Information flow is not a property [McLean94] No information flow from x to y: ⇔ P(T) if every pair of traces in T with the same initial value for x always have the same value for y
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 47 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 48
8 Availability
System is responsive to requests DoS attacks: attempts to destroy availability Enforcing safety properties (perhaps by cutting off network access)
Fault tolerance: system can recover from faults (failures), remain available, reliable
Benign faults: not directed by an adversary
Usual province of fault tolerance work
Malicious or Byzantine faults: adversary can choose time and nature of fault
Byzantine faults are attempted security violations
usually limited by not knowing some secret keys
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 49
Reference Monitor Requirements for a Monitor
Observes the execution of a program and Must have (reliable) access to information halts the program if it’s going to violate the about security-relevant actions of the program security policy. e.g., what instruction is it about to execute? Must have the ability to “stop” the program
Common Examples: can’t stop a program running on a different machine
memory protection … or transition to a “good” state.
access control checks Must protect the monitor’s state and code routers from tampering. firewalls key reason why a kernel’s data structures and code aren’t accessible by user code Most current enforcement mechanisms are low overhead in practice reference monitors
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 51 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 52
Pervasive mediation What policies? Reference monitor Interpreter Program instrumentation Reference monitors can only see the past EM Extension Extension Extension EM They can enforce safety properties but not liveness properties EM Base system Base system Base system Assumptions: monitor can have access to entire state of computation.
OS Reference monitor: won’t capture all events monitor can have arbitrarily large state Wrapper/interpreter: performance overhead safety properties enforced are modulo computational Instrumentation: merge monitor into program power of monitor different security policies ⇒ different merged-in code But: monitor can’t guess the future – the predicate it simulation does not affect program uses to determine whether to halt a program must be pay only for what you use computable.
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 53 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 54
9 Software Fault Isolation (SFI) One way to SFI: Interpreter
Wahbe et al. (SOSP’93) void interp(int pc, reg[], mem[], code[], memsz, codesz) { while (true) { Goal is process isolation: keep software components in if (pc >= codesz) exit(1); same hardware-based address space, provide int inst = code[pc], rd = RD(inst), rs1 = RS1(inst), Idea: application can use untrusted code without memory protection rs2 = RS2(inst), immed = IMMED(inst); overhead switch (opcode(inst)) { Software-based reference monitor isolates components case ADD: reg[rd] = reg[rs1] + reg[rs2]; break; into logical address spaces. case LD: int addr = reg[rs1] + immed; if (addr >= memsz) exit(1); conceptually: check each read, write, & jump to make sure it’s within the reg[rd] = mem[addr]; component’s logical address space. break; hope: communication as cheap as procedure call. case JMP: pc = reg[rd]; continue; worry: overheads of checking will swamp the benefits of communication. ... } 0: add r1,r2,r3 Only provides memory isolation, doesn’t deal with other pc++; 1: ld r4,r3(12) security properties: confidentiality, availability,… }} 2: jmp r4
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 55 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 56
Interpreter pros and cons Partial Evaluation (PE) Pros: A technique for speeding up interpreters.
easy to implement (small TCB.) we know what the code is.
works with binaries (high-level language-independent.) specialize the interpreter to the code.
easy to enforce other aspects of OS policy unroll the main interpreter loop – one copy for each instruction Cons: specialize the switch to the instruction: pick out that case
terrible execution overhead (25x? 70x?) compile the resulting code It’s a start. Can do at run time with dynamic binary rewriting (e.g., DynamoRIO)
Keep code cache of specialized code
Reduce load time, code footprint
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 57 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 58
Example PE Sandboxing Interpreter Original Binary: SFI code rewriting is “sandboxing”
0: add r1,r2,r3 case LD: int addr = reg[rs1] + immed; Requires code and data for a security domain 1: ld r4,r3(12) if (addr >= memsz) exit(1); are in one contiguous segment 2: jmp r4 reg[rd] = mem[addr]; upper bits are all the same and form a segment id. ... break; separate code space to ensure code is not modified.
Inserts code to ensure load and stores are in the Resulting Code Specialized interpreter: logical address space reg[1] = reg[2] + reg[3]; 0: add r1,r2,r3 force the upper bits in the address to be the segment id addr = reg[3] + 12; 1: addi r5,r3,12 no branch penalty – just mask the address if (addr >= memsz) exit(1); 2: subi r6,r5,memsz reg[4] = mem[addr]; 3: jab _exit re-allocate registers and adjust PC-relative offsets in code. pc = reg[4] 4: ld r4,r5(0) simple analysis used to eliminate some masks …
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 59 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 60
10 Jumps More SFI Details
Inserts code to ensure jump is to a valid Protection vs. Sandboxing: target Protection is fail-stop: stronger security guarantees (e.g., reads) must be in the code segment for the domain required 5 dedicated registers, 4 instruction sequence must be the beginning of the translation of a source 20% overhead on 1993 RISC machines instruction (tricky for variable-length instructions) Sandboxing covers only stores requires only 2 registers, 2 instruction sequence PC-relative jumps are easy: 5% overhead just adjust to the new instruction’s offset. Remote (cross-domain) Procedure Call: Computed jumps are not: 10x cost of a procedure call 10x faster than a really good OS RPC must ensure code doesn’t jump into or around a check or else that it’s safe for code to do the jump. Sequoia DB benchmarks: 2-7% overhead for SFI compared to 18-40% overhead for OS.
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 61 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 62
Limitations of SFI Inlined reference monitors (IRMs)
Only enforces process isolation SASI [Schneider & Erlingsson 1999], Variable-length instructions are tricky Naccio [Evans & Twyman 1999] But provably correct SFI is possible for x86 SFI inlines a particular safety policy into [McCamant & Morrisett] untrusted code Sometimes want to enforce more complex Idea: embed an arbitrary safety policy into rules on untrusted code untrusted code at load time Example: downloaded applet can either read local files Policy may be application-specific, even user-specific or send to network, but not both Low execution overhead Can we do more by code rewriting?
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 63 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 64
Security automata Example: JVM code in SASI (Also implemented for x86 machine code) not read not send … ldc 1 // new automaton state on stack putstatic SASI/stateClass/state // cause automaton state change invokevirtual java/io/FileInputStream/read()I // read integer from file … read getstatic SASI/stateClass/state // automaton state onto stack ifeq SUCCEED // if stacktop=0 goto succeed invokestatic SASI/stateClass/FAIL()V // else security violation SUCCEED: Every safety property enforceable by security automaton invokevirtual java/net/SocketOutputStream/write(I)V // send message [Schneider ‘98] ... System execution produces sequence of events … … automaton reads and accepts/rejects sequence not read not send Need pervasive mediation to allow policies independent 0 1 of code being checked read
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 65 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 66
11 PSLang: specifying policies
State diagrams (SASI) are inconvenient -- how to specify a reference monitor? Type Safety and Security Policy Specification Language (PSLang)
same expressive power, more convenient
event-driven programming model maps program actions (events) to automaton state updates
specification expressible in terms of application abstractions Has been used to specify, enforce Java stack inspection security model (!) with good performance But..hard to apply complex policies to low-level code
STATE { boolean did_read = false; } EVENT methodCall FileInputStream.read { did_read = true; } EVENT methodCall Network.send CONDITION did_read { FAIL; }
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 67
Type-safe languages Java
Software-engineering benefits of type safety: Java is a type-safe language in which type memory safety safety is security-critical no buffer overruns (array subscript a[i] only Memory safety: programs cannot fabricate defined when i is in range for the array a.) pointers to memory
no worries about self-modifying code, wild Type safety: must use objects at correct jumps, etc. types Encapsulation: private fields, methods of Type safety can be used to construct a protected objects cannot be accessed from outside interface (e.g., system call interface) that applies Bytecode verifier ensures compiled access rules to requests bytecode is type-safe
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 69 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 70
Java: objects as capabilities Problems with capabilities
Single Java VM may contain processes Original 1.0 security model: use type with different levels of privilege (e.g. safety, encapsulation to prevent untrusted different applets) applets from accessing capabilities in Some objects are capabilities to perform same VM security-relevant operations: Problem: tricky to prevent capabilities from FileReader f = new leaking (downcasts, reflection, …) FileReader(“/etc/passwd”); One approach: confined types [Vitek&Bokowski] // now use “f” to read password file Difficult to revoke capabilities esp. in // …but don’t lose track of it! distributed environment
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 71 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 72
12 Java Stack Inspection Security operations
Added to Java to deal with capability Each method has an associated protection domain model shortcomings e.g., applet or local doPrivileged(P){S}: Dynamic authorization mechanism fails if method's domain does not have priv. P.
close (in spirit) to Unix effective UID switches from the caller's domain to the method's while executing statement S (think setuid). attenuation and amplification of privilege checkPermission(P) walks up stack S doing: Richer notion of context for (f := pop(S); !empty(S) ; f := pop(S)) { if domain(f) does not have priv. P then error; operation can be good in one context and bad in if f is a doPrivileged frame then break; another } E.g: local file access Very operational description! But ensures integrity of may want to block applets from doing this control flow leading to a security-critical operation but what about accessing a font to display something?
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 73 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 74
Example Some pros and cons? Applet Font Library: ... stack frames Pros: doPrivileged(ReadFiles) { Font library load("Courier"); rich, dynamic notion of context that tracks some of } load the history of the computation. ... … this could stop Melissa, Love Bug, etc. low overhead, no real state needed. FileIO: read ... Cons: checkPermission(ReadFiles); read(); implementation-driven (walking up stacks) ... Could be checked statically [Wallach] policy is smeared over program Requires: possible to code around the limited history • Privilege enabled by some caller (applet can’t do this!) e.g., by having applets return objects that are invoked after the applet's frames are popped. • All code between enabling and operation is trustworthy danger of over/under amplification
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 75 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 76
Require type safety? Cyclone
Write all security-critical programs in type-safe A type-safe dialect of C high-level language? (e.g., Java) Goals: Problem 1: legacy code written in C, C++ Solution: type-safe, backwards compatible C Memory and type safety (fail-stop behavior) Problem 2: sometimes need control over (relatively) painless porting from C memory management writing new code pleasant Solution: type-safe memory management Low-level control: data representations, memory Can we have compatibility, type safety and low- management, ability to interface to the outside world, level control? Can get 2 out of 3: performance, etc. CCured [Necula et al. 2002] Has been used to implement low-level, Emphasis on compatibility, memory safety Cyclone [Jim et al. 2002] code safely, e.g. device drivers Emphasis on low-level control, type safety
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 77 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 78
13 Hello World The trouble with pointers #include "stdio.h" Pointer arithmetic: The stack: int *f(int *a) { int x; int main(int argc, char ??argv) { return a + 10; scanf(“%d”, &x); } if (argc < 1) { fprintf(stderr,"usage: %s
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 79 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 80
Pointers Compatibility Three kinds: fat, thin-null, thin-not-null Porting most C code is fairly You pay for what you get… straightforward: char ? : arbitrary pointer arithmetic, might be null, mostly, convert t* to t? where necessary 3 words of storage, bounds checked use advanced type features (polymorphism, tagged char * : no real arithmetic, might be null, unions, existential types) to replace unsafe casts with 1 word of storage type-safe operations char @ : same as above, but never null put in initializers (only top-level, interprocedural)
char *{42} : same, but points to (at least) 42 chars put in fallthru's (very rare) char * == char *{1} char @{n+m} ≤ char @{n} ≤ char *{n} ≤ char ?
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 81 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 82
CCured [Necula, 2002] Different pointer classes
DYNAMIC : no info, slow, all accesses checked
SAFE: a memory- and type-safe pointer (or null) Certifying compilation
SEQ: pointer to an array of data (like Cyclone fat)
Type-safe world Memory-safe world
DYNAMIC SAFE,SEQ DYNAMIC Nonmodular but fast C→CCured converter using BANE constraint solving framework (worst case: DYNAMIC) 10-50% Performance penalty More safe C impls: [Jones&Kelly], [Ruwase&Lam]
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 83
14 Code certification mechanisms Type-Based Protection (JVM)
Problem: can you trust the code you run?
Code signing using digital signatures JVM verifier System Too many signers Interface If you can’t trust Microsoft,… Idea: self-certifying code JVM Code consumer can check the code itself to ensure it’s safe Java Source Code includes annotations to make this feasible Interpreter javac Checking annotations easier than producing them JIT compiler Certifying compiler generates self-certifying code JVM bytecodes Java/JVM: first real demonstration of idea System Binary Binary
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 85 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 86
Bytecode verification Type-checking JVM
Java compiler is a certifying compiler that compiles to Calls can be type-checked once actual argument Java Virtual Machine code types are known Generates enough type information in target code to check that code is type-safe Java Virtual Machine stores data in locals (used
Same thing could be done with other source languages for variables) and stack locations (used for
Microsoft CLR is similar arguments, temporaries) Verifier first checks structure (syntax) of bytecode Types of both can change at every program point, not included in bytecode format Branches checked to ensure they address valid target instructions (control safety) Verification uses dataflow analysis to determine types of every local/stack locn at every program Methods (functions) and class fields are annotated with point complete type signatures (argument and result types) Use argument types and method result types to Method calls are explicit in JVM -- can look up signatures directly get analysis started
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 87 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 88
Completing analysis Compiling to the JVM
Local 2 : C1 Local 2 : C2 The JVM type-system isn’t all that different C3 from Java’s compiling other languages Control-flow to JVM doesn’t work that well. graph C1 C2 Local 2: C3 e.g., no tail-calls in the JVM so Scheme and ML are Class hierarchy hosed... (MS fixed this in CLR) no parametric polymorphism, no F-bounded subtyping, limited modules, etc. Merge type information on different paths by finding least common ancestor (C3) Operations of the JVM are relatively high- If no least common ancestor mark type as level, CISC-like. unusable (local 2: ?) method call/return are primitives Little control over indirection Report success if all method calls, bytecode operations type-check, otherwise reject program interpreter or JIT is necessary
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 89 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 90
15 Ideally: Typed Assembly Language [Morrisett, 1998]
Your favorite verifier System language Interface Two goals:
Get rid of the need for a trusted interpreter or JIT Low-Level IL System compiler (SSA) “Kernel” Binary type-check the actual code that will run.
try not to interfere with traditional optimizations. optimizer Provide generic type constructors for encoding Smaller TCB, language many high-level language type systems.
independence. reasonable target for compiling many languages machine code a more “RISC” philosophy at the type-level
better understanding of inter-language relationships.
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 91 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 92
TAL contributions TAL (simplified) Theory: Registers: r ∈ {r1,r2,r3,...} simple MIPS-like assembly language Labels: L ∈ Identifier compiler from ML-like language to TAL Integer: n ∈ [-2k-1..2k-1) soundness and preservation theorems Blocks: B ::= jmp v | ι ; B Practice: Instrs: ι ::= aop rd,rs,v | bop r,v | mov r,v most of IA32 (32-bit Intel x86) Operands: v ::= r | n | L more type constructors (array,+,µ,modules)
prototype Scheme, Safe-C compilers Arithmetic Ops: aop ::= add | sub | mul | ... Branch Ops: bop ::= beq | bne | bgt | bge | ...
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 93 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 94
Simple program Basic type structure ; fact(n,a) = if (n <= 0) then a else fact(n-1,a*n) type ::= int | Γ ; r1 holds n, r2 holds a, r31 holds return address where Γ = { r1:t1, r2:t2, r3:t3, ...} ; which expects the result in r1 fact: sub r3,r1,1 ; r3 := n-1 A value with type { r1 : t1, r2 : t2, r3 : t3, ...} is a code ble r3,L2 ; if n < 1 goto L2 label, which when you jump to it, expects you to at least have values of the appropriate types in mul r2,r2,r1 ; a := a*n the corresponding registers. ; n := n-1 mov r1,r3 You can think of a label as a function that takes a jmp fact ; goto fact record of arguments L2: mov r1,r2 ; result := a the function never returns – it always jumps off we assume record subtyping – we can pass a label more jmp r31 ; jump to return address arguments than it needs
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 95 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 96
16 Simple program with types Badly typed program fact:{r1:int,r2:int,r31:{r1:int}} fact:{r1:int,r31:{r1:int}} ; r1 = n, r2 = accum, r31 = return address ; r1 = n, r2 = accum, r31 = return address sub r3, r1, 1 ; {r1:int,r2:int,r31:{r1:int},r3:int} sub r3, r1, 1 ; {r1:int,r31:{r1:int},r3:int} ble r3, L2 bge r1, L2 mul r2, r2, r1 mul r2, r2, r1 ; ERROR! r2 doesn’t mov r1, r3 have a type jmp fact mov r1, r3 L2:{r2:int, r31:{r1:int}} jmp L1 mov r1, r2 L2:{r2:int, r31:{r1:int}} jmp r31 mov r1, r2 jmp r1 ; ERROR! r1 isn’t a valid label
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 97 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 98
TAL vs JVM, CLR Ideally:
The principles behind TAL and the JVM trusted computing base
(or Microsoft’s CLR) aren’t too different: Your favorite verifier Security compiler generates enough type language Policy annotations to check target code System Binary Low-Level IL TAL concentrates on orthogonal, expressive typing components (more general target lang) optimizer JVM (and CLR) focus on OO-based
languages with predefined implementation machine code strategies.
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 99 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 100
Idea #1: Theorem Prover! Unfortunately... trusted computing base trusted computing base Theorem Security Your favorite Prover language Policy System Binary Low-Level IL Theorem optimizer Prover
Warning: components not drawn machine code to scale!
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 101 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 102
17 Observation PCC:
trusted computing base
Finding a proof is hard, but verifying a proof is easy. optimizer verifier Security Policy System Binary machine code could be you prover
“certified binary”
code invariants proof
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 103 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 104
Making “Proof” Rigorous: Proof-carrying code
Specify machine-code semantics and security policy using axiomatic semantics. {Pre} ld r2,r1(i) {Post} Given: Code producer Safety Code consumer security policy (i.e., axiomatic semantics and associated logic for policy assertions) Verification Target safety untrusted code, annotated with (loop) invariants condition code condition generator it’s possible to calculate a verification condition: Safety an assertion A such that Proof
if A is true then the code respects the policy. Proof checker
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 105 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 106
Code consumer side Advantages of PCC Verifier (~5 pages of C code): A generic architecture for providing and checking safety properties takes code, loop invariants, and policy In Principle: calculates the verification condition A. • Simple, small, and fast TCB. checks that the proof is a valid proof of A: • No external authentication or cryptography. fails if some step doesn’t follow from an axiom or inference rule • No additional run-time checks. fails if the proof is valid, but not a proof of A • “Tamper-proof”. • Precise and expressive specification of code safety policies in- In Practice: code invariants proof variants • Still hard to generate proofs for properties stronger than “certified binary” type safety. Need certifying compiler…
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 107 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 108
18 End-to-end security
Near-term problem: ensuring programs are Security types memory-safe, type-safe so fine-grained access control policies can be enforced
and information flow Long-term problem: ensuring that complex (distributed) computing systems enforce system- wide information security policies
Confidentiality
Integrity
Availability Confidentiality, integrity: end-to-end security described by information-flow policies that control information dependency
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 110
Policies vs. mechanisms Problems
? A B U Complex policies no generally accepted policy language I weak validation techniques Problem: policy/mechanism mismatch Information flows hard to find Reference monitors (e.g., access control): control whether A is allowed to transmit to B (covert channels) Confidentiality policy: information I can only be obtained by users U (no matter how it is Heterogeneous, changing trust transformed) – not a safety policy! Host machines may be How to map policy onto a mechanism? (we already do this by hand!) compromised
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 111 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 112
Information leaks Standard mechanisms Discretionary access control: no control of Programs can leak inputs propagation ? A B ... Bob Mandatory access control: expensive, restrictive Tax Data Input ? A B Spreadsheet top secret L L secret classified unclassified Bill network Database Java stack inspection: integrity, not confidentiality Can’t enforce information flow policies
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 113 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 114
19 Static information flow Noninterference [Denning & Denning, 1977] "Low-security behavior of the program is not Programs are annotated Source Code Policy affected by any high-security data." with information flow Goguen & Meseguer 1982 policies for confidentiality, integrity H L H L 1 ≈L 2 Compiler checks, possibly Target Code Policy transforms program to ensure that all executions obey rules H1 L ≈ H2 L System L Loader, run-time validates Policy program policy against Confidentiality: high = confidential, low = public system policies Executable code Integrity: low = trusted, high = untrusted
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 115 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 116
Security types Lattices and security
Idea: add information flow policies as type Denning, 1976. annotations (labels) Information flow policies (security policies in Simplest policy language: H = confidential, general) are naturally partial orders
L = public. L →H ok, H→L bad If policy P2 is stronger than P1, write P1 P2 P1 = “smoking is forbidden in restaurants” P2 = “smoking is forbidden in public places” int{H} x; // confidential integer Some policies are incomparable: P P and P P int{L} y; // public integer 1 / 2 2 / 1 String{L} z; // public string P2 = “keep off the grass” If there is always a least restrictive policy as x = y; // OK least as strong as any two policies, policies form y = x; // BAD lattice. P1 P2 = “join” of P1, P2 x = z.size(); // OK P1 P2 = “smoking forbidden in restaurants and keep off the grass” z = Integer.toString(x) // BAD H ⊔ H = H, L ⊔ L = L, L ⊔ H = H
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 117 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 118
Checking computation Implicit Flows
Combining values with different x = 0; information flow policies? if (b) { x = a; Conservatively, } Label of result should be a policy at least as strong as the labels of all inputs. Final value of x may reveal values of a, b Write x for “label of x” Conservative: label of x protects Label of y+z is y ⊔ z both a and b a x & b x
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 119 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 120
20 Static Assignment Rule Run-time Checking?
Program-counter label pc captures x = 0; implicit flows if (b) { if, while, switch statements x = a; a x & b x ? bump up pc (temporarily) }
Run-time check Compile-time x = 0; if b is false, x=0, but no check is performed checking: if (b) { if check fails, b is also leaked! x = a; pc = b a ⊑ x Static checking not just an optimization! } pc ⊑ x
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 121 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 122
Proving noninterference Jif: Java + Information Flow
Volpano et al., 1996 [Myers, 1999] Can show that any type-safe program with information- Annotate (Java) programs with labels from flow security types must satisfy noninterference decentralized label model Strategy: show that each step of execution preserves Variables have type + label. Labels contain low-observable equivalence: policies in terms of principals. int {Alice→Bob} x; P1 ≈L P2 Information flow control and access control
float {x} cos (float x) { P1 ≈L P2 float {x} y = x — 2*PI*(int)(x/(2*PI)); return 1 — y*y/2 + ...; … … }
Language with functions, state: Zdancewic, Myers ‘01 Available for download: Core ML: Pottier, 2002 http://www.cs.cornell.edu/jif
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 123 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 124
Confidentiality policies as types Intentional leaks
Confidentiality labels: int{Alice→} a; “a is Alice's private int” Bob Spreadsheet Integrity labels: int{Alice←} a; “a is trusted by Alice” Tax Data Combined labels: Final Tax Form int{Alice→ ; Alice←} a; (Both) explicit release WebTax // Insecure // Secure int{Alice→} a1, a2; b = a1; a1 = a2; int{Bob←} b; b = c; a1 = b; Proprietary int{Bob←Alice} c; a1 = c; Preparer Database “Bob believes Alice can affect c” c = b;
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 125 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 126
21 Selective Declassification Information flow and dependency
[Myers, 1997] Checking whether information flows from x An escape hatch from noninterference to y is just a dependency analysis A principal can rewrite its part of the label Dependency is crucial to security! {O1→R1, R2; O2→R2} Many other applications of language- O2 based dependency analysis… {O1→R1, R2} {O1→R1, R2; O2→R2, R3} Other owners’ policies still respected Must test authority of running process Potentially dangerous: explicit operation Jif 3.0: declassification mediated by integrity checks: “robustness” [Chong&Myers]
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 127 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 128
Catching bad format strings SQL injection vulnerabilities
[Shankar et al., 2001] WebSSARI system [Huang et al.], [Xie & Aiken]: Idea: should not use untrustworthy (H) analyze dependencies in PHP scripts to discover data as format string, else attacker can SQL queries built from untrusted information $rows=mysql query("UPDATE users SET pass=‘$pass’ gain control of system WHERE userid=‘$userid’”); Security type: $userid, $pass must be trusted information
int printf(char *L fmt, …) Sanitization functions convert untrusted to Give network buffer type char *H : trusted after checking for metacharacters etc. information flow analysis prevents buffer Doesn’t worry about implicit flows -- attacker can data from affecting format string affect SQL queries but probably difficult to problem: false positives synthesize attacks… Probably useful for less direct attacks too
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 129 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 130
Detecting worms Vigilante
Vigilante system [Costa et al.] uses dynamic Idea: labels on data are sets of bytes from and static dependency analysis to network messages where is ⊆ Detect worm attacks Run app with dynamic binary rewriting, Automatically generate filters computing labels for data Generalize filters so they catch larger class of related attacks At invalid step (e.g., jumping to payload), label No false positives on step says which message bytes matter!
Filters can be distributed by peer-to-peer Generate filter from them. system in 2.5 min. (a solution to Slammer!)
PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 131 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 132
22 Other work and future challenges The End
Thank you for your participation! Security types for secrecy in network See website for bibliography, more tutorial protocols information: www.cs.cornell.edu/andru/pldi06-tutorial Self-certifying low-level code for object- oriented languages Applying interesting policies to PCC/IRM Secure information flow in concurrent systems Enforcing availability policies Acknowledgements: Greg Morrisett, Fred Schneider, Steve Zdancewic, George Necula, Peter Lee PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 133 PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 134
23