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?