Today's plan

Distributed File System

remotely access files as if they were on a local disk
allows file sharing among computers
NFS, SMB, etc
a server stores the files, provides them on demand, allows contents to be replaced, provides security
a client sends requests to the server, and provides the appearance of a mounted file system
the Minix File Server (FS) is a local file server, the system call mechanism is the client
clients might be very thin, but are almost always in the kernel, and may provide substantial caching and buffering
a diskless client with a network interface can be booted over the network, might use most of the same OS code as a disk-based boot
servers may run in user space, as long as they have access to all the files they must serve and the security information they need

NFS developed as part of BSD circa 1980, spawned Sun Microsystems
observation that reads and writes could be repeated as long as they are to the same disk block: such operations are idempotent, i.e. have the same effect whether executed once or many times.
NFS was designed to use only idempotent operations, so it would not need (expensive, complex) reliable transmission -- instead, each operation is repeated until it is acknowledged (or it fails) and is sent over UDP (which is simple, fast, and unreliable)
client requests read or write for a given volume (NFS mount), inode, and position within file, e.g. write these 1024 bytes at position 8192 of inode 1234 on volume 7.
because only idempotent operations are used, both the client and the server are stateless -- neither needs to remember any state (e.g. open files) for the other
therefore the server may reboot, with only delay seen at the client
different clients may write the same block -- the latest write is the one that is successful (but there is no way for the server to tell clients to flush their caches)
NFS security originally relied on IP numbers and trusting the remote machine, is now considerably more secure and involved, based on the NIS distributed database

(partly from http://nfs.sourceforge.net/)
must have an nfs server daemon on the server machine, and nfs file system support on the client kernel
edit /etc/exports (exports(5)) on server to specify which volumes should be exported how and to whom
arrange to start nfs server daemon automatically on boot
create the mount points on the client
add the mount points and remote mount points in /etc/fstab on the client
mount -a -t nfs on the client
can change the last two if mounting as user

many issues, including technical issues, but also legal, political, ethical (if someone breaks into your computer but does not damage anything, are they doing something wrong?)
security includes good backups, perhaps offsite
some intruders might have more resources than you do -- and how do you know who to trust? (even the government makes mistakes in deciding who to trust)
should my private information be available to others?

network attacks, often via some form of buffer overflow, but also denial of service (DoS, or DDos, distributed denial of service), spam, and password guessing
allowing access to uninitialized storage
illegal (undocumented, test-based) system calls, parameters (e.g. data structures in user space), or user-interface operations, exploiting programming errors or giving access to backdoors
giving unexpected input to the security mechanism
social engineering, try to convince someone to do something that will reveal their secret passwords or execute your code (e.g. send an email that says "log into your account at this URL", or "you have a virus", when the email actually contains the virus)

publicize your design. Security by obscurity works somewhat, but fails against a determined attack, so gives a false sense of security
default to denying access, since overly strict denial will be reported more effectivly than overly permissive policies
check the current situation, not what the user did earlier (e.g. the user got a cookie an hour ago, but someone else is using their browser now...)
only give processes the privilege they actually need
make sure the entire system is secure and supports security throughout
ideally, the user interface should be such that it is easy to be secure, harder to be insecure
encrypt all passwords using a salting scheme to make dictionary attacks harder
a honey pot (a system that appears to be valuable, but can be lost or damaged without any real harm) can be used to see if any attacks are going on
you cannot rely on users being perfect or making no mistakes. People will make mistakes

a reference monitor is a (possibly hypothetical) program that checks every access to a resource based on its policy table
an object is a resource, a right is permission to perform a certain operation on an object, and a domain is a set of pairs of objects and rights (e.g. permission to write to /dev/kmem, permission to read /dev/mem)
a Unix protection domain corresponds to the process's UID and GID, and corresponding permissions in the file system and in the kernel
when a Unix process makes a system call, it switches to a new domain
an exec on a setuid (setgid) file changes the protection domain

protection domains can be seen as a matrix of objects (columns) and rows (domains), with the entries being specific rights
if the matrix is maintained by row (by domain), the sets of rights that each domain has is a set of capabilities that the process has
Capabilities may include the capability to pass a given capability on to another process
if the matrix is maintained by column (by object), the sets of domains that have rights for each object is an access control list, similar to file permissions but much more general (e.g. grant all access to this file to users X and Y, no access to user Z, read+execute access to user W, and execute-only access to all others)
a covert channel is a way of transmitting information by causing observable (but apparently innocent) side effects, without trying to access prohibited resources
e.g. a spy inside a building can turn his light on and off at 5 minutes past the hour to signal yes, and 10 minutes past the hour to signal no -- any other time has no meaning
e.g. a computer or network can be kept busy to indicate a 1, and idle to indicate a zero -- over time, many bits can be sent, and error correction can be used to compensate for uncertainty