Scribe Notes
CS 235A
01 October 2007

Most of the lessons of the assigned reading for this lecture are still
applicable. When discussing them, we will use modern examples.

What are some principles of security?

1. Principle of least privileges - only give programs the privileges
necessary to do their jobs. How can we discover what is necessary?

  (a) Code inspection -- only works for small programs

  (b) Enumerate use cases, then attempt them with no privileges
  available. Add privileges as necessary. We may end up missing a use
  case or misunderstanding a user's system setup

  (c) Divide privileges up into a small number of sets of
  privileges. These might be easier to reason about.

2. Complete mediation - check whether access is allowed each time a
resource is used. This security issue is sometimes called Time Of
Check To Time Of Use - TOCTTOU.

Example code

1> stat(filename,&st,...);
2> if (st.user == user) {
3>   open(filename);

What if, between lines 2 and 3, the a malicious user changes the
filename to be a symbolic link to /etc/passwd?

Possible solutions: 
1. don't open with the filename, open with the inode
2. Make the read atomic
3. Delegate the task to the kernel by doing the open after "su $USER"

Unix file system operations do not use complete mediation. Of "open",
"read", "write", and "close", only "open" checks file permissions.

3. Open design -- This is the opposite of Security through
Obscurity. One argument for open design is that secrets leak, and they
do so without notifying the owner. A better argument is that peer
review actually improves security.

4. Fail-safe defaults. Example: we should ship systems with services
(HTTP server, for example) turned off. The rationale is that if we
ship with them off, users who need them will turn them on. If we ship
with services on, users who do not need the services will simply
ignore them and leave them on.

5. Psychological acceptability -- ease of use.

Examples:
  * SSL is a simple-to-use secure HTTP replacement.
  * SSH has a similar relation to telnet

Both of these are easier for users to understand given their previous
experience.

6. Economy of mechanism -- simpler is often more secure. Smaller does
not imply simpler (see: perl line noise), but larger  often implies
more complex.

7. Least common mechanism
8. Separation of privilege

----------------------------------------------------------------

Examples:

Firewalls' last rule (the default) is to deny any packets not
explicitly allowed.

Least privilege example: Sandboxing: keep a program running in an
inescapable filesystem via chroot, do the same for system calls via
strace