1. Implementing Network File System Policies with FileWall Stephen Smaldone, Aniruddha Bohra, and Liviu Iftode {smaldone,bohra,iftode}@cs.rutgers.edu Department of Computer Science Rutgers University

2. 2 File System Evolution Single user (desktop) FS to shared infrastructures –Centrally managed –24/7 –Shared access –High maintenance requirements –Interoperability: standards Unprecedented growth –Size of storage infrastructures Today - Tera Tomorrow - Peta, Exa, ??? User density: user consolidation Data sources –File sharing, document management, email, IM, VOIP

3. 3 File System Management Problems Monitoring: –Minimal built-in support for statistical monitoring (e.g., nfsstat) –Administrators required to gather data from many sources Access control: –Access control maintained per file at the discretion of the owner –Administrators must enforce access control to shared resources despite ignorant non-malicious users Maintenance: –Patching newly exposed bugs in the file system –Debugging, testing, and deployment of new code –Administrator error impact much larger Evolution: –New functionality cannot be introduced without code extensions

4. 4 File System Management Problems Monitoring: –Minimal built-in support for statistical monitoring (e.g., nfsstat) –Administrators required to gather data from many sources Access control: –Access control maintained per file at the discretion of the owner –Administrators must enforce access control to shared resources despite ignorant non-malicious users Maintenance: –Patching newly exposed bugs in the file system –Debugging, testing, and deployment of new code –Administrator error impact much larger Evolution: –New functionality cannot be introduced without code extensions Management tools have not evolved to match administrator needs

5. 5 Policy vs. Data Access Data Access: –Evolves independently –Performance enhancement –Protocol optimization –Acceptable to most Policy: –Evolves due to functionality requirements –Difficult to specify and reason about –Administration requirements differ between installations and must be implemented independent of user requirements

6. 6 Policy vs. Data Access Data Access: –Evolves independently –Performance enhancement –Protocol optimization –Acceptable to most Policy: –Evolves due to functionality requirements –Difficult to specify and reason about –Administration requirements differ between installations and must be implemented independent of user requirements File systems implement a minimal set of management functionality

7. 7 Monitoring Policy : Example

8. 8

9. 9

10. 10 Monitoring Policy : Example

11. 11 Monitoring Policy : Example

12. 12 Our Goal We propose a novel approach to implement network file system policies externally, without modifying the client or server, by transforming messages flowing between them.

13. 13 Network File Systems FS_OP NFS_REQ() NFS_REQ RPC Transport read() NFS_OP() NFS_RSP RPC Transport

14. 14 Observations All file system access are performed through messages –Message transformations can be used to enforce policies –File system state can be constructed using information contained in messages All state relevant to file system accesses is available in messages –Policies can use file attributes contained in messages in policy evaluation –Statistical information can also be used

15. 15 FileWall Model FS_OP NFS_READ() NFS_REQ RPC Transport FS_OP NFS_READ() NFS_RSP RPC Transport NFS_REQ RPC Transport NFS_RSP RPC Transport

16. 16 Monitoring Policy: Revisited

17. 17 Monitoring Policy: Revisited

18. 18 Monitoring Policy: Revisited

19. 19 Monitoring Policy: Revisited FileWall enables the separation of concerns of network aware policy enforcement and the file systems

20. 20 Outline Motivation Design Implementation Evaluation Related Work Conclusions

21. 21 Design Guidelines Specification –Ease of specify and reason about policies Protocol semantics –Message reordering and aggregation –Retransmissions and lost bytes Performance –In critical path  cannot have large delays Fault tolerance and availability –Cannot maintain “hard-state” –Limited access to stable storage

22. 22 FileWall Design Overview Specification –Policies specified using macro-like language –Message transformation State Maintenance (Access Context) –Local policy state and global environment –Read-only state specified by the administrator –State generated and stored by policies during execution –Time, available disk space, CPU load, etc. Execution –Policy scheduling and execution –Logging and debugging

23. 23 FileWall Architecture FS Client File Server FileWall Engine Access Context Policies FileWall M M’ RR’

24. 24 FileWall Policies Transform messages (requests and replies) –REQ handler –RSP handler Use: –File attributes contained in messages –Access context

25. 25 FileWall Policy Example Policy: “Show files accessed today” For each client-visible file: –Access Time = TODAY Transform directory listing messages –READDIR and READDIRPLUS

26. 26 FileWall Policy Example FileWall Engine Access Context Policies FileWall

27. 27 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIR

28. 28 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIR

29. 29 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIR

30. 30 FileWall Policy Example READDIRPLUS FileWall Engine Access Context Policies FileWall READDIR

31. 31 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIRPLUS

32. 32 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIRPLUS

33. 33 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIRPLUS

34. 34 FileWall Policy Example FileWall Engine Access Context Policies FileWall READDIRPLUSREADDIR

35. 35 Policy Chains Defined by administrator –Lists policies in order of request processing Scheduler –Determines policy execution schedule Fowarder –Forwards messages between policies –Determines next policy in chain as a message flows along the policy chain –Discards messages Default Policies –RECV Policy (start), SEND Policy (end)

36. 36 Policy Chains

37. 37 Outline Motivation Design Implementation Evaluation Related Work Conclusions

38. 38 Implementation FileWall –Click Modular Router –NFS over UDP Unmodified Linux NFS client and server Policies –Statistics monitoring policy –Temporal Access Control –File Handle Security –Client Transparent Failover

39. 39 Outline Motivation Design Implementation Evaluation Related Work Conclusions

40. 40 Fstress Performance (2.4 GHz Server)

41. 41 Interposition Overheads

42. 42 Varying Network Delay

43. 43 Fstress Performance (Overloaded Server)

44. 44 Scalability

45. 45 Related Work Distributed and Extensible File Systems: –FiST [Zadok ’00] –Interposed Request Routing [Anderson ’02] –SFS [Mazieres ’99] Extensible Policies: –SPIN [Sirer ’95] –VINO [Seltzer ’96] –Exokernel [Engler ’95] –Infokernel [Arpaci-Dusseau ’03] –LGI [Minsky ’00], [He ’05] Composable Network Processing: –Packet filters [Bos ’04] –x-kernel [Hutchinson ’91] –Scout [Montz ’94] –Click [Kohler ’00]

46. 46 Future Work High-Level Policy language –Constraints –Debugging and logging

47. 47 Future Work High-Level Policy language –Constraints –Debugging and logging User study –Real deployment –Behavior models

48. 48 Future Work High-Level Policy language –Constraints –Debugging and logging User study –Real deployment –Behavior models Data transformations –Censorship –Protocol translations NFS -> CIFS Recipe-based file system (CASPER) IP -> RDMA –Video encoding –Content adaptation

49. 49 Conclusions FileWall –Architecture, Design, and Implementation Policy enforcement through message transformation Implementation of four real-world policies Policy implementations are portable Interposition overheads are low Given sufficient resources, relative to an NFS server, FileWall imposes minimal overheads

50. 50 Acknowlegements Fabio Picconi (Universite de Paris 6) Cristian Ungureanu (NEC Labs)

51. Thank You Questions?