News: Intensia: public URL, earnings report
MS: ruling released early
Mistake: put something on web with "hard to guess" URL. This is not protection.
Least priviledge: give minimum priv needed to do job. Problems often happen b/c of misuse of priv. Minimize damage.
Simplicity: simple designs more likely to be right.
- easier to understand, find flaws, easier implementation
- bugs: certain number per x lines of code. Less code = less bugs.
Trusted computing base (TCB): set of things that must work correctly for system to be secure (examples: compiler, libraries... even A/C in room for computer to work reliably).
- malicious vs. "innocent" bugs
Access control: deciding which function calls are allowed. Says "yes" or "no" to each attempted call. Usually OS tells callee who caller is, and callee's code makes access control decision.
( ) ( )
\ /
\ /
[OS Kernel] (this is a small peice of Windows, Linux)
|
|
[ HW ]
Two styles
- access control matrix (centralized bookkeeping)
- capabilities (decentralized)
Objects (things you can operate on)
S [ ]
u [ ]
b [ ]
j [ ]
e [ ]
c [ ]
t [ ]
s [ . ]
^
|
|-- Each cell: list of operations
Subject wants to do operation on object.
Two issues
- Matrix is big, unweildly
- Policy: who decides how matrix filled in?
Security labels: names/keys/markers for subjects and objects. Example: label process based on user.
- pro: reduces matrix size, simplifies policy setting
- con: oversimplifying?
- don't base process priviledge on pid.
Example: labeling process with a userID. Suppose Alice runs program that Bob wrote.
- treat as Alice: Bob's code can steal Alice's data
- treat as Bob: Alice can't use program on her own data, but she can get at Bob's data
- ideal: give it subset of Alice's priviledges (chosen by Alice) + some subset of Bob's privs (chosen by Bob). (Access the one file Alice wanted, that is all).
Another try: Some combination-type subject ("Bob's code on behalf of Alice")
- in practice: Bob chooses whether program runs as Alice or Bob (Alice sees decision)
- virus problems: code written by someone else running as you
- can lead to problems, but necessary to be practical
Can use labels to give single name to set of subjects/objects (group)
- As a matrix (almost never done): lots of redundancy that can ben compressed
- "Profiles" for each subject, keep list of what subject can do (like row of matrix). List of non-empty elements
- "Access control lists" (ACL): for each object, keep list of who can do what (like storing column)
Usually, use ACL (because # objects much greater than # of subjects). Often very small in practice.
Who sets policy?
Centralized policy
- pro: done by well-trained person
- con: inflexible
Decentralized policy - "owner" of object sets ACL
- pro: matches intuition, flexible
- con: burden on users, more mistakes, hard to comply with external requirements. (i.e., in hospital, hippocratic law; rules about patient's private data. Can't let users set policy).
ACL model: like having guard at door, he checks list
Capabilities model: as long as have ticket, get in.
Mandatory policy: imposed constraints from above. Often have mix of mandatory and discretionary rules.
Define set of subjects and treat it as an individual (makes ACL shorter)
Define by set of members or by set operations (union, intersection) on other groups
Joining/leaving group changes many permissions at once.
Often have facility for person to assume role, de-assume role.
Definition: data structure or reference saying "the bearer may do operation O on object X"
Implementation
- cryptographic: unguessable secret (digital sig). Can tell it to anyone.
- OS tracking: OS keeps track of your capabilities (name & capability index). Can't name capability you don't have, because not in data structure.
- drawback: no revoking capability
Crypto model: ofen no record kept of who has what priv.
Hybrid ACL/capabilities
bootstrapping: need way to get first capabilities.
Closed system: ACL
Open: capabilities
