Lecture 17 - Network File System (NFS) Continued and Security

December 8, 2014

Table of Contents

1. Network File System
   1. Some New Problems With NFS
   2. NFS Security: What Can Go Wrong?
2. Security

Author: Amy Drafahl

---

Network File System Continued

Instead of having the client open the file itself to read and write, the kernel uses NFS for the client in order to use files.

Unmodified Client Code:
fd=open("foo", O_RDONLY)
read(fd, buf, sizeof(buf))
write(fd, buf, sizeof(buf))

Some New Problems With NFS

1. Performance
   • There are extra layers before reaching the files because it has to go through the network.
   • The hard disk can take around 20 ms for a write so it is tempting to "cheat" with the client or server by putting the write inside a buffer without writing yet and sending back a response as if it were written.
     • It is normal for the client to "cheat" this way with file systems and it can always use fsync if it needs to clear the buffers.
     • Servers do not hold any information about the client's state because NFS is a stateless protocal. So server crashes and reboots won't effect the client but the buffer holding any writes will be lost. In order to cheat, the server will need flash memory and a log so that it can recover the writes.
   • Peformance benchmark
     • Using SPEC SFS 2014 Benchmark for NFS or CIFS with cluster FS on vanilla hardware. 96 disks with 600 GB at 10 KRPM, infiniband 2.5 GB/port, 26 TB disk and three 54 GiB RAM network.
2. Sending file descriptors without knowing the client state
   • NFS uses a file handle which uniquely identifies the file on the file server and persists across reboot. It is an integer containing the inode number.
   • If there are multiple file systems, the file handle also contains the device number. The server then looks at the mount table to resolve the device number.
   • Note that if you remove a file that is still being read then the file will not show up anymore but it will still exist in the system. NFS renames the file into a ".nfs" file and when the kernel of the client sees that it is done being used, it will unlink the file.
3. Messages lost
   • One example of a lost message is if the server response is lost. In this case the client might resend the request which could result in an error.
     • One solution is to use an idempotent cache. If the same request is sent from the client to the server then the server will resend the same response as previously.
     • client code: if ( (unlink() != 0) && (errno != ENOENF) )
                      error;
   • Another example is if the server reuses inode numbers which is common.
     • One solution is to add a serial number to the file number. Every create file adds one to the serial number so that each file has a different number.
4. Some other client deletes .nfs files
   • If NFS can't find the file for the client trying to access it, it will report an error ESTALE for having a stale file handle.
5. NFS doesn't promise read after write consistency
   • Clock skew also worsens this. This can create an inaccurate timestamp for files because the client and server clocks can be different from each other.
6. NFS clients cache writes
   • Example:
     ssh x create foo
     ssh y use foo
     This last command can't see foo in order to use it correctly.
   • One solution is to have NFS guarentee that when the client closes the file, NFS will flush all the write buffers and make sure it works. Only then will it return to the client. So close() can be slow and can also fail.

NFS Security: What Can Go Wrong?

• The client message specifies the user and group id. These id's are integers and if other clients know these then they can pretend to be them in order to read or write with more permissions.
  • Solution 1: Arrange for client and server to be secure by requiring password, locking it physically or requiring that everyone is trustworthy.
  • Solution 2: Use a secure protocol where clients are authenticated using a method that the server trusts.
• Others can see the data being passed and get the contents of the files and even alter them.
  • Solution 1: Arrange for client and server to be secure by requiring password, locking it physically or requiring that everyone is trustworthy.
  • Solution 2: Use encryption.

Security

• Main Forms of Attack
  • Unauthorized release of data
  • Against integrity (i.e. put bad/tampered data into system)
  • Against service (Denial of Service attacks)
• Goals
  • Allow authorized access -- easy to test, users test all the time
  • Disallow unauthorized access -- hard to test
  • Performance -- easy authorized testing, hard unauthorized testing
    Example 1: 2014-11-28 Sony Hack Attack from North Korea was done by malware
    Example 2: 2012-03-01 DOS attack on BBC by Supreme Council on Virtual Space (Iran)
• Threat Modeling and Classification
  • Insiders -- authorized users might be malevalent
  • Social Engineering -- obtaining authorization by talking/tricking people
  • Network Attacks -- buffer overflow, java script mistakes, drive by downloads
  • Device Attacks -- USB viruses
• General Techniques for Solutions
  • Authentication -- password, public/private keys, biometric recognition
  • Integrity -- checksums
  • Authorization -- permissions
  • Auditing -- logs

---

References

1. Doen et al. Lecture 17 Fall 2010
   This was used to get an idea on how to use HTML for the notes.