CS 111: Scribe Notes for 12/02/2008

by Sahil Amoli, Max Chang, Sheng Lu, Sharon Tang

NFS protocol

• used to communicate between NFS client and server (CIFS in Microsoft)
• Looks similar to Unix system calls

For Example:

• CREATE(dirfh, name, attr) -> fh
  • dirfh – directory file handle
  • name – name of file to create
  • attr – attribute of file
• LOOKUP(dirfh, name) -> fh
• REMOVE(dirfh, name)
• READ(fh, offset, nbytes) ->bytes read
• WRITE

*Can be found in Table 4-1, page 4-46*

NFS file handle – unique ID for the file in that NFS server

• Similar to file descriptor; however one level down (in the kernel)
• (like dev + mode pair in Unix)
  • filesystem + inode # of file

Important Design Criteria of original NFS

• NFS server is “stateless”
• No important state in RAM on server – all important state information on disk
  • If NFS server crashes, no problem other than performance
    • Advantages
      • reliability
      • simplicity in server
    • Disadvantages
      • performance, particularly on writes (states written to disk)

Caching could help performance but at the expense of losing simplicity

Problems with NFS

1. Locks on files
   • fcntl() advisory locks
     • doesn't work in original NFS v3
     • NFS v4
       • “statefull”
       • locks
2. Packet loss
   • Client to Server
     • if client issues a packet à times out à RETRY
       • NFS method issues at least one retry
     • Client issues REMOVE à server removes à sends packet back à packet loss
       • Would the retry be appropriate? NO, file already removed
       • Workaround: Item Potency Cache
         • server maintains cache of recent requests allowing a duplicate response to be sent in the case of receiving a duplicate request
         • Not truly stateless

3. Stale file handle problem
   • Scenario
     1. Client 1 opens “f”
     2. Receives file handle – 963 (usually a much larger number)
     3. Client 2 removes “f”
     4. Client 1 performs read of 963
     5. errno == ESTALE (obtained because server does not know open files of each client)
   
   
   • Hack: client kernel, when told to unlink an open file, instead renames it to “.nfs196”
     • Same file handle, although under different name
     • On last close, client kernel unlinks “.nfs196”
     • Issues?
       • Only works if same machine performs operations on the same file (client 1 = client 2)
       • Client crash before final unlink will result in file with cryptic name
   
   
   • In Unix
     • No clean up is done until last file descriptor is closed
     • NFS is “stateless” and does not know what is open, so it removes when asked

NFS model

• Advantage
  • simple stateless server
  • A client that hangs will not affect other clients
• Disadvantages
  • Client side that is a bit more complicated (client-side cache)

NFS does not have write-to-read consistency

• Can be caught by extra handshaking – in practice, too expensive to be practical
• Simply do not assume that there is consistency
• However it is OK to slow down less commonly used system calls
  • Open/Close – Close-to-open consistency does work; close() on client will make sure cached data are sent to server
    • interesting consequence is that close() can fail with errno == EIO, ESPACE, which is not possible in Linux filesystem
  • Rename
  • Unlink

NFS Security

·         Evil client host that lets users become “root”, or any other user

§  You can look at any file you like (Quick hack: “root” = “nobody” over wire)

+ Simple client authentication:

·         based on IP address – ideal for local networks

·         We can also use SSH, IPSec, and hardware assisted security while losing performance

Users in NFS are modeled by UIDs (user ID)

 If user “Eggert” has two different UIDs on system A and B, the NFS will recognize Eggert-A and Eggert-B as two different users. One way to solve this issue is by using an authentication system, such as Kerberos.

 

Security

·         Real world security - defend against force & fraud attacks

o   Main forms of attacks:

                                                                                - against privacy

                                                                                - against integrity

                                                                                - against service (commonly seen as DoS)

·         General goals:

·         Allow authorized access (a positive goal)

·         Disallow unauthorized access (a negative goal)

o   Harder to test – attackers never file bug reports

 

·         Threat modeling + classification

o   Insiders

o   Social engineering

o   Network attacks:

- virus, drive-by downloads (phishing)

- DoS (Denial of Service)

- Buffer overruns

o   Device attacks:

- USB virus

General mechanisms for any security scheme:

• Authentication – people can prove who they really are
• Integrity – don’t let people mess with the system
• Authorization – keep track of who is allowed to do what
• Auditing – logging user actions
• All of these things need correctness and efficiency

Authentication

• Prevents masquerading
• Based on what you know, what you have, who you are
• Can be external or internal
• External authentication is like having a sentry determine who can and cannot enter the fortress – must not be forgeable/guessable
  • Passwords
  • Biometrics (fingerprints, retinas, etc.)
  • Secret keys (managed by computers)
• Internal authentication is like having guards in the fortress checking on your identity every time you try to do something – typically recorded in process descriptors and maintined by the OS
• Possible attacks:
  • Shoulder surfing – record over your shoulder to get your info
  • Key logging – record all of your keystrokes to get your info
  • Phishing/fake websites – pretend to be some trusted site to get your info
  • Man-in-the-middle attacks –pretend to be the server to get your info

Cryptographic building blocks for authentication - hash functions

• H(M) ==> V
• With a hash function H, take a message M and make a unique hash value V
• Example: SHA1 – takes a message M and gives back a 160-bit hash value H
• We don’t want:
  • To be able to construct an M to have a given H
  • To be able to modify M without getting a different H
  • To have two different M’s get the same H
• Tricky to come up with good hash functions that meet our needs

Symmetric encryption

• DES – data encryption standard
• 3DES – triple DES – formed by using DES three times
• We have:
  • P is the unencrypted message
  • K is the key
  • {P}^K is the encrypted message
• We need:
  • Given P and K, getting {P}^K MUST BE EASY!
  • Given {P}^K and K, getting P MUST BE EASY!
  • Given {P}^K, getting P MUST BE HARD!
  • Given P, getting {P}^K MUST BE HARD!
  • Given P and {P}^K, getting K MUST BE HARD!

Bottom Line: encryption and decryption must be hard if we don’t have the required information