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.
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!
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.
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.
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.
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.
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
]
bsy+cse127w02@cs.ucsd.edu, last updated Mon Mar 25 15:22:10 PST 2002. Copyright 2002 Bennet Yee.
email bsy.
