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

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

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

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

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

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

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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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

08/15/2007Selective Versioning in a Secure Disk System29 Prototype Implementation Pseudo-device driver in Linux kernel ,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

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

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)

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

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, Ext2Ver(A) 12,4521, Versioning Interval : 30 seconds Number of versions created : 27

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

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, Ext2Ver(A) 1, Versioning Interval : 30 seconds Number of versions created : 78

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

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

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

Selective Versioning in a Secure Disk System Swaminathan Sundararaman, Gopalan Sivathanu, Erez Zadok Stony Brook University Questions?