Selective Versioning in a Secure Disk System Swaminathan Sundararaman University of...
-
Upload
angela-hudson -
Category
Documents
-
view
217 -
download
2
Transcript of Selective Versioning in a Secure Disk System Swaminathan Sundararaman University of...
Selective Versioning in a Secure Disk System
Swaminathan SundararamanUniversity of Wisconsin-Madison
Gopalan Sivathanu Google Inc.Erez Zadok
Stony Brook University
08/15/2007 Selective Versioning in a Secure Disk System 2
Securing Disk Data
• Data protection is performed byApplicationsFile systems
• Existing data protection systems operate at the OS level
• OS compromisesRoot 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 3
Aspects of Data Security
• ConfidentialityPreventing unauthorized reads
• IntegrityDetecting unauthorized writes
• RecoverabilityProtecting against data destruction
07/31/2008 Selective Versioning in a Secure Disk System 4
Compromised
Treat Model
User Applications
Data
File SystemsSecurity
Mech.
Entire disk data vulnerable
OS
Existing Systems
08/15/2007 Selective Versioning in a Secure Disk System 5
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 constraintsProtects important file from being modified
• Selectively versions user-chosen files Reduces the space overhead
08/15/2007 Selective Versioning in a Secure Disk System 6
Compromised
Our Solution
User Applications
File Systems
Regular data
OS
Versioned Data Data
08/15/2007 Selective Versioning in a Secure Disk System 7
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 abstractionVersion at a more usable granularity
• Leverage Type-Safe Disks (TSD) [OSDI’06]
08/15/2007 Selective Versioning in a Secure Disk System 8
Background on TSD
• Pointers: primary mechanism of organizing stored data
• Pointers defineSemantic 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/2007 Selective Versioning in a Secure Disk System 9
SB
IB
DirB DirB DirB
DirB
IB IB IB IB IB
DB DB DB DB DB DB
SB
IB
DirB
DB
Super Block
Inode Block
Directory Block
Data Block
Semantic DependencyLogical GroupingImportance 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/2007 Selective Versioning in a Secure Disk System 10
OverviewOverview
08/15/2007 Selective Versioning in a Secure Disk System 11
Securing Disk Data
• Need to restrict access to versioned data
• Virtualizes the disk address spacePrevents 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/2007 Selective Versioning in a Secure Disk System 12
Logical Block #
Physical Block #
1 2
Mapping TableApplications
1 2 3 4 5
1 2 3 4 5
2 4
3 1
Logical Blocks
Physical Blocks
Mapping in internally maintained by SVSDS
3 1
3
1
• 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 13
Selective Versioning
• Versioning all blocks consumes more storage space
Shorter version histories
• Blocks have varying levels of importanceMeta-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/2007 Selective Versioning in a Secure Disk System 14
SB
IB
DirB DirB DirB
DirB
IB IB IB IB IB
DB DB DB DB DB 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/2007 Selective Versioning in a Secure Disk System 15
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/2007 Selective Versioning in a Secure Disk System 16
SB
IB
DirB DirB DirB
DirB
IB IB IB IB IB
DB DB DB DB DB 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/2007 Selective Versioning in a Secure Disk System 17
Versioning Policy
• Versioning intervalTime interval between versions
Configurable by the administrator
Currently, one versioning interval for all blocks
Versioning Blocks
08/15/2007 Selective Versioning in a Secure Disk System 18
Applications
1 2 3 4 5
1 2 3 4 5
Logical Block #
Physical Block #
1 2
Mapping Table
2 4
3 1
Logical Blocks
Physical Blocks
Logical Block #
Physical Block #
Version Table
Ver. #
3
1
1 2
• write_block(1)
• lookup entry in mapping table
• version old mapping
• allocate physical block 3
• updates the entry in the mapping table
08/15/2007 Selective Versioning in a Secure Disk System 19
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-onlyAppend-only
• Files marked for Read-only and Append-only cannot be deleted
08/15/2007 Selective Versioning in a Secure Disk System 20
Operation-level Constraints
• Read-only constraintEnsures that marked blocks are immutable
Protects against intruders, viruses, Trojan horses, malware, etc.
• Append-only constraintEnsures 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 21
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 22
Issues
• Currently revert at the granularity of timeDo not revert based on logical abstractions
• Denial of Service attacksMarking 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 23
Overview
• Motivation
• Design
• Related Work
• Evaluation
• Conclusion
Overview
Application-level VersioningFile-system-level VersioningDisk-level Versioning
08/15/2007 Selective Versioning in a Secure Disk System 24
Versioning File Systems
• Flexible Allow per-file policies
• Are only as secure as the OSprevious 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 25
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 26
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 27
Feature Comparison
FeatureVersioning
File-systems
Disk-level Versioning
S4 TRAP Clotho SVSDS
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/2007 Selective Versioning in a Secure Disk System 28
Overview
• Motivation
• Design
• Issues
• Related Work
• Evaluation
• Conclusion
Overview
08/15/2007 Selective Versioning in a Secure Disk System 29
Prototype Implementation
• Pseudo-device driver in Linux kernel 2.6.15
• 7,487 lines of kernel code3,600 from existing TSD prototype
SVSDS Pseudo-device Driver
User Application
Disk / RAID
SVSDS Interface
Regular Block Interface
File System
Block Driver
08/15/2007 Selective Versioning in a Secure Disk System 30
Evaluation
• Test platformLinux 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 31
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 32
Postmark
0
100
200
300
400
500
600
700
800
900
Ext2 Ext2TSD Ext2Ver(M) Ext2Ver(A)
Ela
pse
d T
ime
(Sec
on
ds)
Elapsed: S.I.System: 1.4xWait: -8.8%
Elapsed: S.I.System: 4.3xWait: -20%
Elapsed: S.I.System: 4.3xWait: -19.5%
Wait Time
User Time
System Time
Versioning Interval : 30 second Number of versions created : 27
Postmark: IO Intensive Workload
08/15/2007 Selective Versioning in a Secure Disk System 33
Space OverheadSpace 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 34
Kernel Compile
Kernel compile: Models user behavior
0
500
1000
1500
2000
2500
3000
Ext2 Ext2TSD Ext2Ver(M) Ext2Ver(A)
Ela
pse
d T
ime
(Sec
on
ds)
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 Time
User Time
System Time
08/15/2007 Selective Versioning in a Secure Disk System 35
Space OverheadSpace 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 36
Overview
• Motivation
• Design
• Issues
• Related Work
• Evaluation
• Conclusion
Overview
08/15/2007 Selective Versioning in a Secure Disk System 37
Conclusion
• Hybrid solutionStrong security and flexible versioning
• Meta-data versioningProtects 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 38
Conclusion (Contd.)
• Lazy reallocation of blocksImplicit data versioning
• Operation-based constraintsprotects log files and executables
Enables easier intrusion detection
• Acceptable space and performance overheads
Selective Versioning in a Secure Disk SystemSwaminathan Sundararaman,
Gopalan Sivathanu,Erez Zadok
Stony Brook University
www.fsl.cs.sunysb.edu
Questions?