Department of Computer Science Institute of Systems Architecture, Operating Systems Group jVPFS: Adding Robustness to a Secure Stacked File System with Untrusted Local Storage Components Carsten Weinhold, Hermann Härtig
INTRODUCTION Confidentiality, Integrity, Availability VPN: Secure Net Secure Net Internet TU Dresden jVPFS 2
INTRODUCTION VPFS: Confidentiality, Integrity, Availability TCB App Linux Kernel 4,600 SLOC Secure Commodity File System File System 50,000+ SLOC Microkernel / Micro ! Hypervisor [1] Weinhold, Härtig: „ VPFS: Building a Virtual Private File System With a Small Trusted Computing Base“ , EuroSys’08 TU Dresden jVPFS 2
INTRODUCTION VPFS: Confidentiality, Integrity, Availability Secure File System Secure File System Proxy Commodity File System [1] Weinhold, Härtig: „ VPFS: Building a Virtual Private File System With a Small Trusted Computing Base“ , EuroSys’08 TU Dresden jVPFS 2
OUTLINE ■ Introduction ■ VPFS: V irtual P rivate F ile S ystem ■ j VPFS: Adding robustness securely ■ Evaluation ■ Lessons learned TU Dresden jVPFS 3
VPFS STACK Secure File System Secure File System Proxy Commodity File System TU Dresden jVPFS 4
FILES & FILE CONTAINERS Virtual Private File System (TCB) H M M M H H H D D D D D Reused Commodity File System (Untrusted) ■ Encrypted files in commodity file system ■ Merkle hash tree to detect tampering TU Dresden jVPFS 5
UPDATING HASH TREE H M M M H H H D D D D D ■ High overhead: many writes + crypto ops ■ Hash tree updates must be atomic TU Dresden jVPFS 6
CONSISTENCY PROBLEM ■ File ! system consistency is complex problem: ■ Correct implementation is difficult [2,3] ■ Bugs often in corner cases, error checking [4] ■ Widely used file systems affected, too ■ Goal: keep complexity out of the TCB [2] Yang et al.: „Using Model Checking to Find Serious File System Errors“ , ACM TOCS Vol.24 Issue 4, 2006 [3] Prabhakaran et al.: „Model ! Based Failure Analysis of Journaling File Systems“ , DSN’05 [4] Gunawi et al.: „EIO: Error Handling is Occasionally Correct“ , FAST’08 TU Dresden jVPFS 7
HASH TREE + JOURNAL H M M M H H D D D H H H H ■ Record new hash sums in journal ■ Recovery: valid hash either in tree or journal TU Dresden jVPFS 8
BLOCK WRITE BACK Security critical ■ Calculate hash + encrypt block ■ Put ciphertext + hash into shared ring buffer ■ Do ordered write to legacy file system ■ Append hash sums to journal ■ Write blocks afterwards ■ Optimizations Critical only for Availability TU Dresden jVPFS 9
JOURNALING METADATA ■ Approach: log operations, not blocks ■ Code reuse: replay during recovery via API ■ Simple dependency tracking ■ Non ! intrusive implementation ■ Dependencies: ■ New files: inode, name, parent dir ■ Updated files: file size, hash sums ■ Unlinked / moved files: name, parent dir TU Dresden jVPFS 10
TRACKING NEW FILES file table new ! file table fd p_fd p_inode name 0 File* 0 1 1 2 File* 2 1 0 „dir“ 3 File* 3 2 0 „file23“ 4 File* 4 2 113 „file42“ ... ... 511 511 Pathname elements to log: .../ dir/ file42 TU Dresden jVPFS 11
JOURNAL CONTENT H M M M H H M M H D D D File_create File_create Update_block Update_block Update_block „dir“ „file42“ H(block), H(block), H(block), file size file size file size TU Dresden jVPFS 12
JOURNAL SECURITY ■ Confidentiality: Root ■ Filenames, inodes, etc.: encrypted Record Record ■ Block offset, type: plaintext Record MAC ■ Tamper detection: Record ■ Anchor of journal in „Sealed Memory“ MAC Record ■ Journal is continuously MAC’d Record MAC ■ Record groups: ■ All records between two MACs TU Dresden jVPFS 13
RECOVERY PROCEDURE Root Critical only for 1. Recover legacy file system Availability Record 2. Find complete record groups in journal Record 3. Restore pre-journal versions of metadata blocks Record MAC 4. Read root info (aka superblock) Record 5. Replay: MAC a) Get complete record groups Record b) Check integrity + decrypt Record c) Re-execute operations: MAC open(), unlink(), ... Record d) Repeat from a) Security critical Record TU Dresden jVPFS 14
COOPERATION ■ Extensive Reuse: ■ Complete commodity file system ■ Existing consistency primitives: ■ Journaling, copy ! on ! write, ... ■ Write ordering, snapshots ■ More details in paper: ■ Checkpoints + journal truncation ■ Flushing metadata blocks TU Dresden jVPFS 15
SOURCE COMPLEXITY SLOC OC Subsystem ReiserFS Ext4 jVPFS Journal + replay ~3,200 ~5,000 325 Basic persistency 404 16,500+ 16,500+ 24,000+ 24,000+ Core functionality 2,444 Crypto algorithms 667 TU Dresden jVPFS 16
TESTING RECOVERY ■ Testcase for recovery: ■ Unpack tar archive (3,000+ files, 70 MB) ■ Power ! cycle machine, interrupt write back ■ Recover jVPFS + try to open + read all files: ■ NILFS+Flash: successful ■ ReiserFS+HDD: successful ■ Example run: replay 1.2 MB journal in 5.1s ■ Restored: 2,710 files, 40 MB user data TU Dresden jVPFS 17
PERFORMANCE 30s Native Linux 25s jVPFS, no journal jVPFS, journal 20s 15s 10s 5s 0s PM ! 2 PM ! 2 untar untar ReiserFS NILFS ReiserFS NILFS HDD Flash HDD Flash TU Dresden jVPFS 18
LESSONS LEARNED ■ jVPFS: Less than 350 SLOC in TCB to make secure file system robust ■ Security ! critical core for journaling + replay: ■ Log API ! level operations, replay via API ■ Code reuse, simple dependency tracking ■ Move complexity to untrusted file system ■ Reuse existing consistency primitives TU Dresden jVPFS 19
Recommend
More recommend
