CSE 127: Lecture 4


The topics covered in this lecture are cost-benefits analysis, user authentication, Unix Access Control, NTFS Access Control, Discretionary and Mandatory Access Control, Trusted Computing Base, and a reading assignment.

Cost-Benefits Analysis

Security is never free. Implementing security mechanisms requires coding effort, increases system complexity, and probably makes the system harder to use. An important part of the security analysis is to analyse the risks involved in a system design and to look at what security mechanisms might be used to mitigate these risks. For the various candidate security mechanisms, what are the costs of implementing them? how will using the security schemes impact the users of the system? how will it slow them down or make it more difficult for them to achieve their goals?

The most secure system is one that is powered off and disconnected from the network. However, such a system will not help you ship code: security by turning off the computer has a very high cost -- it eliminates all of the benefits of having the computer in the first place!

User Authentication

The first thing that you'd have to do when you sit down in front of a computer is to log in. Logging in authenticates you to the machine -- but not vice versa. User authentication is enabling -- and critical -- for achieving our security goals of confidentiality, integrity, availability, and accountability/non-repudiation.

Once the operating system know who you are, your identity is used to key into the operating system's access control and resource control mechanisms. What files you can read or write is based on who you are. How much of the system's resources you can use, e.g., CPU time, number of open files, how much memory your programs can use, etc, are also based on identity. Different operating systems provide difference access and resource control mechanisms, but the underlying goals are the same.

Unix Filesystem Access Control

In Unix, the chmod command is used to set the access control bits. This is one access control mechanism used to achieve our security goals. Confidentiality and integrity correspond to (roughly) read and write accesses to files. We will explore more access control mechanisms later (setuid).

The access control bits are grouped into 3 groups of 3 bits: user, group, and "other" groups, where each group contains a read, write, and execute bit. This is a relatively coarse-grained mechanism, since each file has only one user and group owner, so making the access control bits implement exactly what you want can be difficult.

NTFS Access Control

In NTFS, you can have an access control list (ACL) on a file. In the ACL you can name arbitrary users and specify each of these users' access rights. This is a finer-grained access control mechanism, though obviously its implementation is more expensive than that of the simple access control bits of the Unix filesystem.

Newer Unix filesystems can also have ACLs. Notably the AFS and NFS filesystems have ACLs.

Discretionary and Mandatory Access Control

The standard Unix filesystem implements Discretionary Access Control (DAC). This means that there is no system-wide access control policy -- access control decisions (as implemented by the access control mechanism) are made by the users. For example, in every computer course you are asked to ensure that your files are not readable by other students -- to discourage non-collaborative cheating, so an innocent student wouldn't get his/her homework files copied, and when the cheating is detected, be accused as a collaborator.

One might imagine that instead of requiring users to take care of themselves, the computer system could make some access control decisions mandatory. This is exactly what Mandatory Access Control (MAC) systems do. Computer systems that have MAC are often used in the military or government, where sensitive data is handled. Data that is labelled to be Top Secret cannot be read by users who do not have the neccessary clearance. Even the owner of the file cannot declassify it -- a special System Security Officer is the only entity who can declassify data.

Trusted Computing Base

The Trusted Computing Base (TCB) is the hardware and software that is -- more accurately, must be -- trusted to implement the system's security mechanisms.

TCB includes the login program, operating system kernel (which includes device drivers, filesystem code, etc), and network daemons (e.g., ftpd, httpd, sendmail) that might run with high privileges. (N.B., some web servers do not require extra privileges.) A compiler may or may not be part of the TCB -- it depends on how the system is used. For example, a simple installation of Win2K from CD (with windows security updates via the Internet) or a simple installation of Linux from RedHat rpms from their CDs / web site would not require that we trust the compiler. On the other hand, a system where the system administrators install system software from source code would have to include the compilers, editors, linkers, etc as part of the TCB.

Reading Assignment

Read Ken Thompson's Turing Award lecture.

Coming next

To be covered Wednesday: expectation values. Somebody remind me!
[ search CSE | CSE | bsy's home page | links | webster | MRQE | google | yahoo | citeseer | certserver ]
picture of bsy

bsy+cse127w02@cs.ucsd.edu, last updated Mon Mar 25 15:22:10 PST 2002. Copyright 2002 Bennet Yee.
email bsy.


Don't make me hand over my privacy keys!