Domain and Type Enforcement for Legacy File Systems. Robert Grimm

Transcription

1 Domain and Type Enforcement for Legacy File Systems Robert Grimm

2 Background I Domain and Type Enforcement (DTE) Core security in SPIN based on DTE Coarse-grained control over extensions Framework for fine-grained constraints Extensions protect their own objects Enforce access control on objects

3 Background II Legacy File Systems AFS, NFS Distributed file systems Used in several operating systems Widely used to store and share data

4 Challenge Integrate legacy file systems with DTE! Integration of SPIN with other OSs Share data over different platforms Add stronger security to legacy file systems Mechanically enforce security policy

5 Constraints Avoid changes to file system Used by other operating systems Impractical to change entire installation Easy to track updates to file system Minimize performance penalty of DTE Want close to insecure performance

6 Limitations Insecure access to files still possible Simply use another OS (Physically lock up servers) Still useful for perimeter defense Firewalls Secure web or FTP servers

7 Domain and Type Enforcement Associates subjects and objects with label Denotes privilege and access constraints Domain for subjects Type for objects Legal rights defined by global access matrix Domain Type Access mode or: Type Domain Access mode

8 Example Employee Outsider Secure FS Internal Marketing

9 Example (continued) Employee Outsider Internal rw -- Marketing rw r-

10 Basic Idea Define mapping from files to DTE types Use global name space to group files Associate group of files with DTE type rgrimm Internal rgrimm/www Marketing Two problems Lookup from path to type inefficient Relative directory operations, aliases

11 Path / Type Mapping I Maintain second name space tree Maps paths into DTE types Sparse representation Originally as required for mapping Expand on directory traversal First node visit expensive Subsequent visits incur small overhead

12 Path / Type Mapping II File System Path / Type Mapping rgrimm rgrimm www papers 552 www

13 Path / Type Mapping III On creation of mapping Reduce DTE access matrix from: Type Domain Access Mode to: Domain Access Mode Push information down mapping tree On visit of new file system node Expand mapping if necessary Link mapping into file system node

14 Access Right Check On file operation Get DTE domain for current thread Look up access mode Verify that operation is legal Directories are files, too Need to do similar access check

15 Changing the Mapping Implicit changes Introduce consistency problems Need to save modifications Similar to file system meta-data updates Expensive Solution: Allow explicit dynamic changes

16 Implementation within NFS Client Module DTEMap 100 lines interface 300 lines implementation Changes to NFS client 30 lines removed 100 lines added

17 Performance Evaluation Two micro-benchmarks Directory traversal 110 directories in groups of 10 Small file read Read 1024 bytes per operation Results in microseconds per operation

18 Initial Directory Traversal % Insecure Secure

19 Cached Directory Traversal % Insecure Secure

20 Small File Reads % Insecure Secure % Initial Cached

21 Extensibility is Hard I You can always tune core code Revisit interface contracts LOOPHOLE may be useful What level of abstraction? Some interfaces hide too much information Need mount path in NFS client Some interfaces are too low-level Access check requires 3 procedure calls

22 Extensibility is Hard II Error handling must be extensible, too! NameServer.Error Based on error codes Error.E, File.ErrorT Combines Mach, Unix and text error messages SecurityError.T Individual exceptions

23 Conclusions Integration is feasible Reasonable performance penalty Need end-to-end performance results Revisit basic design assumptions Extensibility requires major design effort Need to revisit core interfaces