La lecture à portée de main
Description
Informations
Publié par | Chiwyog |
Nombre de lectures | 10 |
Langue | English |
Extrait
Computer security
Goal: prevent bad things from happening
PLDI’06 Tutorial T1: Clients not paying for services
Critical service unavailableEnforcing and Expressing Security
Confidential information leakedwith Programming Languages
Important information damaged
System used to violate laws (e.g., copyright)
Andrew Myers Conventional security mechanisms aren’t
up to the challengeCornell University
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.
Prevents addressing important security issues:The Internet has changed all of this.
Downloaded and mobile code
we depend upon the infrastructure for everyday services
Buffer overruns and other safety problems you have no idea what programs do.
Extensible systems software is constantly updated – sometimes without your knowledge
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
1Conventional 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
Reference monitor (e.g., kernel) permits or Restrict access to persistent data (files)
denies request+ Language-independent, simple, limited
User-level Program
Hardware request Reference Object
Principalmemory 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
st Authentication vs. Authorization 1 guideline for security
Principle of complete mediation: Abstraction of a principal divides
enforcement into two parts Every access to every object must be checked by
the reference monitor
Authentication: who is making the request
Authorization: is this principal allowed to make
Problem: OS-level security does not supportthis request?
complete mediation
request ObjectReferencePrincipal 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
Modern programs make security decisions Operating system enforces security at
with respect to application abstractionssystem call layer
UI: access control at window level
Hard to control application when it is not making
mobile code: no network send after file readsystem calls
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
2nd2 guideline for secure design Least privilege problems
OS privilege is coarse-grained: user/groupPrinciple of Least Privilege: each principal
Applications need finer granularityis given the minimum access needed to
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
Untrusted? Something lessExamples:
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
rd3 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
large and complex”the security of a system
OS is a small TCB, compiler a large one
Example: TCB of operating system includes
c. 2003:kernel, memory protection system, disk image
OS (Win2k) = 50M lines code, compiler ~ 100K lines
Small/simple TCB:
code
⇒ TCB correctness can be checked/tested/reasoned about more
Hard to show OS implemented correctlyeasily ⇒ more likely to work
Many authors (untrustworthy: device drivers) Large/complex TCB:
Implementation bugs often create security holes
⇒ TCB contains bugs enabling security violations
Can now prove compilation, type checking correctProblem: modern OS is huge, impossible to verify
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
3Language-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