Presentation is loading. Please wait.

Presentation is loading. Please wait.

Selective Versioning in a Secure Disk System Swaminathan Sundararaman University of Wisconsin-Madison Gopalan Sivathanu Google Inc. Erez Zadok Stony Brook.

Similar presentations


Presentation on theme: "Selective Versioning in a Secure Disk System Swaminathan Sundararaman University of Wisconsin-Madison Gopalan Sivathanu Google Inc. Erez Zadok Stony Brook."— Presentation transcript:

1 Selective Versioning in a Secure Disk System Swaminathan Sundararaman University of Wisconsin-Madison Gopalan Sivathanu Google Inc. Erez Zadok Stony Brook University

2 08/15/2007Selective Versioning in a Secure Disk System2 Securing Disk Data Data protection is performed by Applications File systems Existing data protection systems operate at the OS level OS compromises Root kit attacks, buffer overflow attacks, viruses, malware, … Entire disk data vulnerable Protecting data in the event of OS comprises Difficult with existing solutions

3 08/15/2007Selective Versioning in a Secure Disk System3 Aspects of Data Security Confidentiality Preventing unauthorized reads Integrity Detecting unauthorized writes Recoverability Protecting against data destruction

4 07/31/2008Selective Versioning in a Secure Disk System4 Compromised Treat Model User Applications Data File Systems Security Mech. Entire disk data vulnerable OS Existing Systems

5 08/15/2007Selective Versioning in a Secure Disk System5 Selective Versioning in a Secure Disk System (SVSDS) Makes stored data recoverable in the event of an OS compromise Transparently versions data inside the disk Applications cannot bypass versioning Enforces operation-level constraints Protects important file from being modified Selectively versions user-chosen files Reduces the space overhead

6 08/15/2007Selective Versioning in a Secure Disk System6 Compromised Our Solution User Applications File Systems Regular data OS Versioned Data Data

7 08/15/2007Selective Versioning in a Secure Disk System7 Versioning Inside the Disk Why disk-level versioning is difficult ? No information about higher level semantics  Narrow block-based interface Versions all blocks  Higher space overheads  Fewer versions  Reverts all blocks Should make use of higher level abstraction Version at a more usable granularity Leverage Type-Safe Disks (TSD) [OSDI’06]

8 08/15/2007Selective Versioning in a Secure Disk System8 Background on TSD Pointers: primary mechanism of organizing stored data Pointers define Semantic dependencies between blocks Logical groupings of blocks Importance of blocks File systems and databases use pointers extensively b+trees, hashes, lists, indexes TSDs track block relationship through pointers

9 FFS Like File System 08/15/2007Selective Versioning in a Secure Disk System9 SB IB DirB IB DB SB IB DirB DB Super Block Inode Block Directory Block Data Block Semantic Dependency Logical Grouping Importance of blocks Unreachable Blocks

10 Motivation Design Related Work Evaluation Conclusion * Block Allocation * Pointer Management * Securing Disk Data * Selective Versioning * Operation-level Constraints * Data Recovery 08/15/2007Selective Versioning in a Secure Disk System10 Overview

11 08/15/2007Selective Versioning in a Secure Disk System11 Securing Disk Data Need to restrict access to versioned data Virtualizes the disk address space Prevents users from directly manipulating data stored inside the disk. Two address space  logical and physical  Applications access data only through the logical address space

12 Disk Virtualization 08/15/2007Selective Versioning in a Secure Disk System12 Logical Block # Physical Block # 12 Mapping Table Applications 12345 12345 24 31 Logical Blocks Physical Blocks Mapping in internally maintained by SVSDS 31 3 1  write_block(3) lookup entry in mapping table redirect write request to physical block 1

13 08/15/2007Selective Versioning in a Secure Disk System13 Selective Versioning Versioning all blocks consumes more storage space Shorter version histories Blocks have varying levels of importance Meta-data blocks (like inodes) define the reachability of their data blocks Only some data blocks are important (/tmp files, program installers are not) Importance changes with the number of outgoing pointers By default SVSDS versions all meta-data blocks

14 Identifying Meta-data 08/15/2007Selective Versioning in a Secure Disk System14 SB IB DirB IB DB SB IB DirB DB Super Block Inode Block Directory Block Data Block Pointers help identify meta-data Outgoing pointer implies its a Meta-data block

15 08/15/2007Selective Versioning in a Secure Disk System15 Versioning Selected Data Users would like to protect their files Pointer information provides logical grouping of blocks SVSDS does a BFS and marks the blocks for versioning

16 Identifying Files 08/15/2007Selective Versioning in a Secure Disk System16 SB IB DirB IB DB SB IB DirB DB Super Block Inode Block Directory Block Data Block Pointers help identify all files of a directory * Mark all files in this particular Dir

17 08/15/2007Selective Versioning in a Secure Disk System17 Versioning Policy Versioning interval Time interval between versions Configurable by the administrator Currently, one versioning interval for all blocks

18 Versioning Blocks 08/15/2007Selective Versioning in a Secure Disk System18 Applications 12345 12345 Logical Block # Physical Block # 12 Mapping Table 24 31 Logical Blocks Physical Blocks Logical Block # Physical Block # Version Table Ver. # 3 1 12  write_block(1) lookup entry in mapping table version old mapping allocate physical block 3 updates the entry in the mapping table

19 08/15/2007Selective Versioning in a Secure Disk System19 Operation-Level Constraints Important to protect certain files from being modified or overwritten Executable files, Library files, Log files, System configuration files SVSDS allows users to specify operation- level constraints Read-only Append-only Files marked for Read-only and Append-only cannot be deleted

20 08/15/2007Selective Versioning in a Secure Disk System20 Operation-level Constraints Read-only constraint Ensures that marked blocks are immutable Protects against intruders, viruses, Trojan horses, malware, etc. Append-only constraint Ensures that entries in log files are not deleted or modified Helps in forensic analysis after an intrusion

21 08/15/2007Selective Versioning in a Secure Disk System21 Administrative interface Special hardware port on the disk Authentication based on capability Prevents users from reverting back to previous versions Can be used to change the versioning frequency

22 08/15/2007Selective Versioning in a Secure Disk System22 Issues Currently revert at the granularity of time Do not revert based on logical abstractions Denial of Service attacks Marking arbitrary files  Use administrative interface to mark files Overwriting versioned blocks  Exponentially increase the versioning interval Creating lots of bogus files  No perfect solution  Stop writes when disk fills up

23 08/15/2007Selective Versioning in a Secure Disk System23 Overview Motivation Design Related Work Evaluation Conclusion Overview Application-level Versioning File-system-level Versioning Disk-level Versioning

24 08/15/2007Selective Versioning in a Secure Disk System24 Versioning File Systems Flexible Allow per-file policies Are only as secure as the OS previous versions can be deleted if the OS is compromised Users can bypass versioning Ext3cow, VersionFS, Elephant, etc.

25 08/15/2007Selective Versioning in a Secure Disk System25 Disk-Level Versioning Operates at the granularity of blocks Security is decoupled from the OS Versions all blocks Clotho, TRAP, and S4

26 08/15/2007Selective Versioning in a Secure Disk System26 Disk-Level Versioning (contd.) Self-Securing Storage System (S4) Object-based disk Internally audits all requests Protects data in compromised systems  Combines log structuring with journal-based metadata versioning Versions all requests for use in intrusion analysis. No support for operation-based constraints

27 08/15/2007Selective Versioning in a Secure Disk System27 Feature Comparison Feature Versioning File-systems Disk-level Versioning S4TRAPClothoSVSDS Selectively versions meta-data  Versions single files / directories  Enforces operation-level constraints  Protects data after OS compromise  Our Hybrid Solution combines strong security of Disk-level versioning system with the flexibility of versioning file systems.

28 08/15/2007Selective Versioning in a Secure Disk System28 Overview Motivation Design Issues Related Work Evaluation Conclusion Overview

29 08/15/2007Selective Versioning in a Secure Disk System29 Prototype Implementation Pseudo-device driver in Linux kernel 2.6.15 7,487 lines of kernel code 3,600 from existing TSD prototype SVSDS Pseudo-device Driver User Application Disk / RAID SVSDS Interface Regular Block Interface File System Block Driver

30 08/15/2007Selective Versioning in a Secure Disk System30 Evaluation Test platform Linux 2.6.15 2.8GHz Xeon (single CPU) 1GB of RAM 74GB, 10Krpm, Ultra-320 SCSI disk 95% confidence intervals within 5% of the mean

31 08/15/2007Selective Versioning in a Secure Disk System31 Conventions Used in Figures Ext2: Ext2 on a regular disk Ext2TSD: Ext2TSD on a TSD Ext2Ver(M): Ext2TSD on a SVSDS (meta-data versioning) Ext2Ver(A): Ext2TSD on a SVSDS (all blocks are versioned)

32 08/15/2007Selective Versioning in a Secure Disk System32 Postmark Elapsed Time (Seconds) Elapsed: S.I. System: 1.4x Wait: -8.8% Elapsed: S.I. System: 4.3x Wait: -20% Elapsed: S.I. System: 4.3x Wait: -19.5% Wait TimeUser TimeSystem Time Versioning Interval : 30 second Number of versions created : 27 Postmark: IO Intensive Workload

33 08/15/2007Selective Versioning in a Secure Disk System33 Space Overhead Space for Data (MB) Space for Versions (MB) Overhead (%) Ext2 12,45200 Ext2TSD 12,45200 Ext2Ver(M) 12,4524433.6 Ext2Ver(A) 12,4521,87915.1 Versioning Interval : 30 seconds Number of versions created : 27

34 08/15/2007Selective Versioning in a Secure Disk System34 Kernel Compile Kernel compile: Models user behavior Elapsed Time (Seconds) Elapsed: -0.3% System: +3.6% Wait: -24.0% Elapsed: S.I. System: +4.6% Wait: -5.6% Elapsed: 0.8% System: +10.1% Wait: -0.8% Versioning Interval : 30 seconds Number of versions created : 78 Wait TimeUser TimeSystem Time

35 08/15/2007Selective Versioning in a Secure Disk System35 Space Overhead Space for Data (MB) Space for Versions (MB) Overhead (%) Ext2 1,78200 Ext2TSD 1,78200 Ext2Ver(M) 1,78251.372.88 Ext2Ver(A) 1,782181.3410.18 Versioning Interval : 30 seconds Number of versions created : 78

36 08/15/2007Selective Versioning in a Secure Disk System36 Overview Motivation Design Issues Related Work Evaluation Conclusion Overview

37 08/15/2007Selective Versioning in a Secure Disk System37 Conclusion Hybrid solution Strong security and flexible versioning Meta-data versioning Protects important file system accessibility information preserves namespace hierarchy Versioning chosen data items Enables flexible policies based on data importance Widens window of recoverability

38 08/15/2007Selective Versioning in a Secure Disk System38 Conclusion (Contd.) Lazy reallocation of blocks Implicit data versioning Operation-based constraints protects log files and executables Enables easier intrusion detection Acceptable space and performance overheads

39 Selective Versioning in a Secure Disk System Swaminathan Sundararaman, Gopalan Sivathanu, Erez Zadok Stony Brook University www.fsl.cs.sunysb.edu Questions?


Download ppt "Selective Versioning in a Secure Disk System Swaminathan Sundararaman University of Wisconsin-Madison Gopalan Sivathanu Google Inc. Erez Zadok Stony Brook."

Similar presentations


Ads by Google