CS111 Scribe Notes Lecture 17
12/02/08
by Xingwei Gong, Jorge Kina, Joel Miller and Jake Walker
NFS (CIFS in Microsoft)
CREATE(dirfh, name, attr) --> fh
LOOKUP(dirfh, name) --> fh
REMOVE(dirfh, name)
READ(fh, offset, nbytes) --> bytes
WRITE(...)
for more detail, look at table 4-1, pg. 4-46 of reader.
NFS Server is stateless
-> no important state info saved in RAM
-> if server crashes, no problem
(other than temporary slowdown)
+ reliable
+ keeps server simple
- performance on writes
locks on files
fcntl(...) advisory --> DOESN'T
WORK (in original NFS v3)
Lost Packet Problem |
| -Retry --> if the client times out, it resends the packet until it gets a response from the server. |
| -Server maintains a chache of recent requests (item-potency cache) and looks for duplicates to avoid executing a lost-packet-command twice |
| NOTE: This is something of a hack. It's definitely not ideal, and not robust enough for our liking. |
Stale File Handel Problem |
| client 1 opens "f" // gets fd # 963 |
| client 2 removes "f" |
| client 1 reads his fd # 963 // gets bad answer! |
| errno == ESTALE // this can't ccur in a regular unix File System, because the OS doesn't reclaim the space until all fd are closed |
| Hack: if the client who removes the file is the same one who is opening it, we can solve this problem. If the client kernel removes a file it still has open, it doesn't actually unlink it, it just renames it to a funky name. This way, the fd is still valid, but it won't be opened if someone tries to open it using its old name. Later, when the proc closes the file, the client kernel removes the file with the funky name. Unfortunately, if our client crashes, we're hosed with this funky named file that will never get removed. | |
The NFS model is a simple stateless server |
| +if a client hangs, no other client will care |
| -client side code is more complicated // often clients will use a large cache for writes before sending them off over the network |
| -NFS does not have write-to-read consistency. This can be caught by extra hand-shaking, but it's so expensive that it is only used for heavyweight, less common system calls like open, close, rename and unlink (but not read/write). This means our system has close-to-open consistency. This also means close() on the client must make sure the cache is written. This means that close() can fail with errno == EIO or errno == ESPACE |
NFS Security
Evil client host that lets users become "root" or any other user
Now you can look at any file you like
quick hack: "root" equals nobody over wire
+ Simple client authentication (based on IP address)
+ Bigger hammer (SSH tunnel, Ipsec, HW assist, otherwise)
This will reduce the performance of the system
Users in NSF are modeled by user ID
(fig1 here)
This means that for the NSF server, user 1000 and 1002 are different and therefore, user 1002 will not be
able to access the file, even though user 1002 is really user 1000
Security
In real world security needs to defend against force and fraud attacks.
In computer fraud attacks is the big problem.
Main form of attacks:
1. Attacks against privacy
2. Attacks against integrity
3. Attacks service (Denial of Service attack)
General goals:
Positive goal : allows authorized access.
Negative goal : disallow unauthorized access
In general, positive goal is easy to test. We can simply prompt some message,
but negative goal is much harder to test because there are so many cases to deal with.
Also, it is hard to meet both goals at the same time.
Threat modeling & Classification:
We have to consider all possible threats for our system, and we have deal with them no matter
if it is computer related or not. Some of the threats are:
1. Insiders.
2. Social Engineering
3. Network Attacks
-- Virus, Drive-by-downloads
-- DoS (Denial of Service attack)
-- Buffer over-run
4. Device attack
-- USB virus
General Mechanisms (for almost any security schemes):
Authentication: verify the users are really who they are.
Integrity: make sure the data is not corrupted by bad guys
Authorization: keep track of who is doing what, and see if the user is allowed to do it.
Auditing: second line of defense. Detect bad things happened and clean up the mess.
we also have to consider efficiency and correctness while we deal with those problems.
Authentication:
-- Prevent masquerading
-- External Authentication (relies on "sentry")
1. passwords (must not be guessable)
2. biometrics (must not be forgeable)
3. secret key (managed by computer)
-- Internal Authentication
Typically recorded in the process descriptor which is maintained by OS
Both external and internal authentication is not perfect, some possible attacks are:
-- shoulder surfing
-- key logging
-- fake wave page
-- man-in-the-middle attacks
-- kernel bugs
while the external authentication can be slow, the internal authentication must be fast.
Cryptographic building blocks for authentication
We can use a cryptographic hash function
h(m) --> v, where m is the message and v is the hash value
given the hash value v, an attacker shouldn't be able to get the message m
For example, the hashing function SHA1(m) (short for secure hash algorithm)will return a 160-bit hash value
For a hash function to be consider good, the following must be true:
given compute difficulty
P, K {p}K easy
{P}K , K P easy
{P}K P hard
P {P}K hard
P , {P}K K hard
This means that if you have the message P and the key K, it should be fairly simple to encrypt the message
using that key. Also if we have the encrypted message and the key used to encrypt it, it should be fairly
easy to decrypt the message.
But if we only have the encrypted message and we try to decrypt it without having the encryption key, this
task should be very hard to accomplish. Similarly it should be hard to get the encrypted message without
having an encryption key.
Finally, it should also be hard to find the encryption key with the knowledge of the original message and
the encrypted message. This has to be true because lets suppose we know that the message always starts with
the current data, and the "bad guys" somehow obtain the encrypted message. They shouldn't be able to compute
the encryption key and decrypt the whole message.
