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


Aspects of Data Security

• ConfidentialityPreventing unauthorized reads

• IntegrityDetecting unauthorized writes

• RecoverabilityProtecting against data destruction


Compromised

Treat Model

User Applications

Data

File SystemsSecurity

Mech.

Entire disk data vulnerable

OS

Existing Systems


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


Compromised

Our Solution

User Applications

File Systems

Regular data

OS

Versioned Data Data


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]


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


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


OverviewOverview


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


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


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


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


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


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


Versioning Policy

• Versioning intervalTime interval between versions

Configurable by the administrator

Currently, one versioning interval for all blocks

Versioning Blocks


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


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


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


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


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


Overview

• Motivation

• Design

• Related Work

• Evaluation

• Conclusion

Overview

Application-level VersioningFile-system-level VersioningDisk-level Versioning


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.


Disk-Level Versioning

• Operates at the granularity of blocks

• Security is decoupled from the OS

• Versions all blocks

• Clotho, TRAP, and S4


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


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.


Overview

• Motivation

• Design

• Issues

• Related Work

• Evaluation

• Conclusion

Overview


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


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


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)


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


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


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%


Wait Time

User Time

System Time


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



Overview

• Motivation

• Design

• Issues

• Related Work

• Evaluation

• Conclusion

Overview


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


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?

selective versioning in a secure disk system swaminathan sundararaman university of...

Documents

secure disk systemffs

disk addres

diskwhy disklevel versioning

pointersselective versioning

securing disk dataneed

event of os

block allocation

blocksfile systems