Selective Versioning in a
Secure Disk System
Swaminathan Sundararaman
University of Wisconsin-Madison
Gopalan Sivathanu
Google Inc.
Erez Zadok
Stony Brook University
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/2007
Selective Versioning in a Secure Disk System
2
Aspects of Data Security
• Confidentiality
Preventing unauthorized reads
• Integrity
Detecting unauthorized writes
• Recoverability
Protecting against data destruction
08/15/2007
Selective Versioning in a Secure Disk System
3
Treat Model
User Applications
Security
Compromised
Mech.
File Systems
OS
Entire disk data
vulnerable
Data
Existing Systems
07/31/2008
Selective Versioning in a Secure Disk System
4
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/2007
Selective Versioning in a Secure Disk System
5
Our Solution
User Applications
Compromised
File Systems
OS
Versioned
Data
08/15/2007
Data
Regular
data
Selective Versioning in a Secure Disk System
6
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/2007
Selective Versioning in a Secure Disk System
7
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
08/15/2007
Selective Versioning in a Secure Disk System
8
FFS Like File System
SB
Logical Dependency
Grouping
Semantic
Importance
of blocks
IB
SB
Super Block
IB
Inode Block
DirB Directory Block
DirB
DirB
DirB
DB
IB
IB
IB
IB
Data Block
IB
Unreachable
Blocks
DB
08/15/2007
DB
DB
DirB
DB
DB
Selective Versioning in a Secure Disk System
DB
9
Overview
• Motivation
• Design
• Related Work
• Evaluation
• Conclusion
08/15/2007
* Block Allocation
* Pointer Management
* Securing Disk Data
* Selective Versioning
* Operation-level Constraints
* Data Recovery
Selective Versioning in a Secure Disk System
10
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
08/15/2007
Selective Versioning in a Secure Disk System
11
Disk Virtualization
Mapping in internally maintained by SVSDS
Mapping Table
Applications
Logical
Blocks
Physical
Blocks
1
1
2
2
3
3
4
4
5
Logical
Block #
Physical
Block #
1
2
2
4
3
1
5
• 9 write_block(3)
• lookup entry in mapping table
• redirect write request to physical block 1
08/15/2007
Selective Versioning in a Secure Disk System
12
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
08/15/2007
Selective Versioning in a Secure Disk System
13
Identifying Meta-data
SB
Super Block
IB
Inode Block
SB
Pointers help identify meta-data
IB
Outgoing pointer implies
its a Meta-data block
DirB Directory Block
DB
Data Block
DB
08/15/2007
DirB
DirB
DirB
IB
IB
IB
IB
IB
DB
DB
DirB
DB
DB
Selective Versioning in a Secure Disk System
DB
14
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
08/15/2007
Selective Versioning in a Secure Disk System
15
Identifying Files
SB
Super Block
IB
Inode Block
SB
Pointers help identify all files of a
directory
* Mark all files in this particular Dir
IB
DirB Directory Block
DB
Data Block
DB
08/15/2007
DirB
DirB
DirB
IB
IB
IB
IB
IB
DB
DB
DirB
DB
DB
Selective Versioning in a Secure Disk System
DB
16
Versioning Policy
• Versioning interval
Time interval between versions
Configurable by the administrator
Currently, one versioning interval for all
blocks
08/15/2007
Selective Versioning in a Secure Disk System
17
Versioning Blocks
Mapping Table
Applications
Logical
Blocks
Physical
Blocks
1
1
2
2
3
3
4
4
5
Logical
Block #
Physical
Block #
1
2
3
2
4
3
1
5
Version Table
• 9 write_block(1)
• lookup entry in mapping table
Ver. Logical
Block #
#
1
• version old mapping
• allocate physical block 3
1
• updates the entry in the mapping table
08/15/2007
Selective Versioning in a Secure Disk System
18
Physical
Block #
2
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 operationlevel constraints
Read-only
Append-only
• Files marked for Read-only and Append-only
cannot be deleted
08/15/2007
Selective Versioning in a Secure Disk System
19
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/2007
Selective Versioning in a Secure Disk System
20
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/2007
Selective Versioning in a Secure Disk System
21
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/2007
Selective Versioning in a Secure Disk System
22
Overview
• Motivation
• Design
• Related Work
• Evaluation
• Conclusion
08/15/2007
Application-level Versioning
File-system-level Versioning
Disk-level Versioning
Selective Versioning in a Secure Disk System
23
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/2007
Selective Versioning in a Secure Disk System
24
Disk-Level Versioning
• Operates at the granularity of
blocks
• Security is decoupled from the OS
• Versions all blocks
• Clotho, TRAP, and S4
08/15/2007
Selective Versioning in a Secure Disk System
25
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/2007
Selective Versioning in a Secure Disk System
26
Feature Comparison
Disk-level Versioning
Versioning
File-systems
S4
TRAP
Clotho
SVSDS
Selectively versions meta-data





Versions single files / directories





Enforces operation-level constraints





Protects data after OS compromise





Feature
Our Hybrid Solution combines strong
security of Disk-level versioning system with
the flexibility of versioning file systems.
08/15/2007
Selective Versioning in a Secure Disk System
27
Overview
• Motivation
• Design
• Issues
• Related Work
• Evaluation
• Conclusion
08/15/2007
Selective Versioning in a Secure Disk System
28
Prototype Implementation
• Pseudo-device driver in Linux kernel 2.6.15
User Application
File System
SVSDS Interface
SVSDS Pseudo-device Driver
Regular Block Interface
Block Driver
Disk / RAID
• 7,487 lines of kernel code
3,600 from existing TSD prototype
08/15/2007
Selective Versioning in a Secure Disk System
29
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
08/15/2007
Selective Versioning in a Secure Disk System
30
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/2007
Selective Versioning in a Secure Disk System
31
Postmark
900
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%
Elapsed Time (Seconds)
800
700
600
Wait Time
500
400
User Time
300
System Time
200
100
0
Ext2
Ext2TSD
Ext2Ver(M)
Ext2Ver(A)
Versioning Interval : 30 second Number of versions created : 27
Postmark: IO Intensive Workload
08/15/2007
Selective Versioning in a Secure Disk System
32
Space Overhead
Space for
Data
(MB)
Space for
Versions
(MB)
Overhead
(%)
Ext2
12,452
0
0
Ext2TSD
12,452
0
0
Ext2Ver(M)
12,452
443
3.6
Ext2Ver(A)
12,452
1,879
15.1
Versioning Interval : 30 seconds Number of versions created : 27
08/15/2007
Selective Versioning in a Secure Disk System
33
Kernel Compile
3000
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%
Elapsed Time (Seconds)
2500
2000
Wait Time
1500
User Time
1000
System Time
500
0
Ext2
Ext2TSD
Ext2Ver(M)
Ext2Ver(A)
Versioning Interval : 30 seconds Number of versions created : 78
Kernel compile: Models user behavior
08/15/2007
Selective Versioning in a Secure Disk System
34
Space Overhead
Space for
Data
(MB)
Space for
Versions
(MB)
Overhead
(%)
Ext2
1,782
0
0
Ext2TSD
1,782
0
0
Ext2Ver(M)
1,782
51.37
2.88
Ext2Ver(A)
1,782
181.34
10.18
Versioning Interval : 30 seconds Number of versions created : 78
08/15/2007
Selective Versioning in a Secure Disk System
35
Overview
• Motivation
• Design
• Issues
• Related Work
• Evaluation
• Conclusion
08/15/2007
Selective Versioning in a Secure Disk System
36
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/2007
Selective Versioning in a Secure Disk System
37
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
08/15/2007
Selective Versioning in a Secure Disk System
38
Questions?
Selective Versioning in a
Secure Disk System
Swaminathan Sundararaman,
Gopalan Sivathanu,
Erez Zadok
Stony Brook University
www.fsl.cs.sunysb.edu