Guardat: Enforcing data policies
at the storage layer
Anjo Vahldiek-Oberwagner1, Eslam Elnikety1,
Aastha Mehta1, Deepak Garg1, Peter Druschel1,
Rodrigo Rodrigues2, Johannes Gehrke3,4, Ansley Post5
1MPI-SWS,
2NOVA
LINCS/Nova University of Lisbon,
3Microsoft, 4Cornell, 5Google
Web attacks and leaks
2
Threat 1: Unauthorized Access
Unauthorized access due to configuration errors, bugs, attacks.
Clients
Web Server Host
Web Server
App
Operating System
File System
Web Server State:
httpd.conf
.htaccess
users
groups
Content
3
Threat 2: State Corruption
State corruption due to configuration errors, bugs, attacks.
Clients
Web Server Host
Web Server
App
Operating System
File System
Web Server State:
httpd.conf
.htaccess
users
groups
Content
4
Threat 3: Trojans & log manipulation
Trojans & log manipulation due to attacks.
Clients
Web Server Host
Web Server
Web Server State:
App
Operating System
File System
Logs
Executables
5
Threat 4: Unaccounted Provider Access
Providers bypass application access control protections.
Clients
Web Server Host
Web Server
Web Server State:
App
Operating System
File System
Provider employee
Content
6
Why is mitigation difficult?
• Confidentiality and integrity depend on
large, fast evolving code base.
• Access control lists and access checks spread
across system.
• Recovering corrupt persistent state is difficult.
7
Guardat: Storage Layer Compliance
Stakeholder: User, provider, developer, privacy officer
Application
File attestation
OS
File System
Guardat
Storage
Layer
Per file policy
Trusted
Controller
8
Outline
Design Principles
2
1
Declarative
Policies
Enforcement
File
Attestation
Guardat
Transaction
Implementation & Evaluation
9
Policy language in a nutshell
Goals::
• High level policy
• Concise
• Easy to audit
• Efficient
enforcement
permission:- Boolean expression over predicates
read :- When to read a file
update :- When to update the file
setPolicy :- When to change policy
destroy :- When to reuse the name
10
Protecting files from unauthorized access
Threat: Unauthorized access due to configuration error, bug or attack.
Private files:
read :- sessionIs(Alice)
update :- …
setPolicy :- sessionIs(Alice)
destroy :- sessionIs(Alice)
Assumption: Integrity of Alice’s key is maintained
Guarantee: Protected files may only be read with an authenticated
session.
11
Protecting files from corruption
Threat: State corruption due to configuration error, bug or attack.
Private files:
read :- …
update :- sessionIs(Alice)
setPolicy :- …
destroy :- …
Assumption: Integrity of Alice’s key is maintained.
Guarantee: Protected files may only be updated within an authenticated
session.
12
Protecting executables
Threat: Attack installing a trojan.
Signed updates-only executables:
read :- TRUE
update :- fileNameIs(F)
∧ fileNewLenIs(L)
∧ (0, L) willHaveHash Nh
∧ keyIs(K, “Vendor”)
∧ K signs okHash(F, N, Nh)
setPolicy:- FALSE
Assumption: Integrity of the vendor’s key is maintained.
Guarantee: Protected files cannot be overwritten except with content
signed by the vendor.
13
Protecting log files from manipulation
Threat: Attack manipulating logs.
Append-only log files:
read :- TRUE
update :- [ fileCurrLenIs(Lc)
∧ fileNewLenIs(Ln) ∧ Ln ≥ Lc
∧ txUpdatedExAre(M)
∧ listsAreDisjoint(M, [0, Lc])]
∨ [sessionIs(Admin)]
setPolicy :- FALSE
destroy :- FALSE
Assumption: Administrator key integrity
Guarantee: Protected files cannot be overwritten, only appended.
14
Protecting content from unaccounted
provider access
Threat: Provider accesses are not accounted for.
Private files accounting
for provider access:
read: - ((“profil”, SEQCNTLOC, _) says seqcnt(currseq)) ^
((“acclog”, _, _) says read(currseq, _, offset, length)) ^
AccessOffIs(offset) ^ AccessLenIs(length)
update:- ((“profil”, SEQCNTLOC, _) says seqcnt(currseq)) ^
((“profil”, SEQCNTLOC, _) willSay seqcnt(nextseq)) ^
EQ(currseq + 1, nextseq) ^ ((“acclog”, gennb, _, _) says
write(nextseq, _, newhash, offsetlist)) ^ ((offsetlist)
willHaveHash newhash) ^ TxUpdateLocAre(offsetlist)
setpolicy: FALSE
destroy: FALSE
Log file with log entry check
and append-only:
Read :-TRUE
update:
[ FileCurrExAre(oe) ^ FileNewExAre(ne) ^ isPrefix(oe, ne) ^
((“acclog”, neo, _) willSay_(nseq, _. _. _)) ^ ((“acclog”, neo READENTRYLENGTH, _) says _(nseq-1, _, _, _)) ^
FileCurrLenIs(currlen) ^ LT(currlen, neo)]
∨[FileCurrExAre(oe) ^ FileNewExAre(ne) ^
isPrefix(oe, ne) ^ ((“acclog”, neo, _) willSays _(nseq, _. _. _))
^ ((“acclog”, gennb, neo -WRITEENTRYLENGTH, _) says
_(nseq-1, _, _, _)) ^ FileCurrLenIs(currlen) ^ LT(currlen, neo) ]
∨[ ((“acclog”, neo, nel) willSaywrite(nseq, _, _, _)) ^ ((“acclog”,,neo, nel) says
write(nseq, _, _, _) ^ ((“profil”, gennb, SEQCNTLOC, _) says
seqcnt(currseq)) ^ LT(currseq, nseq) ^ TxUpdateLocAre((neo, nel))]
setpolicy:-FALSE
destroy:-FALSE
Assumption: Auditor key integrity
Guarantee: Protected files cannot be accessed without corresponding
log entry in the access log.
15
Outline
Design Principles
2
1
Declarative
Policies
Enforcement
File
Attestation
Guardat
Transaction
Implementation & Evaluation
16
Storage Layer Enforcement
Host
Web Server
App
Library
Operating System
File System
OS abstraction
File System
VMM
Virtual device
Storage Layer
Storage controller
Disk
DiskDisk
Decrease risk of
circumvention
17
Storage Layer Enforcement
Host
Web Server
App
Physically protected
Machine Room
Operating System
File System
VMM
Storage Area Network
Server
Network
Disk
DiskDisk
Disk
DiskDisk
18
Outline
Design Principles
2
1
Declarative
Policies
Enforcement
File
Attestation
Guardat
Transaction
Implementation & Evaluation
19
File Attestation: Bridging gap between file
and block level enforcement
Stakeholder: User, provider, developer, policy officer
Attests:
•
•
•
•
File name
Policy
State
Content
Application
Per file policy
OS
File System
Guardat
Storage
Layer
Trusted Controller
Metadata:
Data Disk
NVM
20
Outline
Design Principles
2
1
Declarative
Policies
Enforcement
File
Attestation
Guardat
Transaction
Implementation & Evaluation
21
Introducing Guardat Transactions
•
•
•
•
Atomic update of file
Bundle multiple accesses
Delays evaluation to commit operation
Transaction caches
2
1
22
Guardat Transaction by Example
Shifting burden of proving complex policy compliance to untrusted code
keeping policies concise and policy evaluation efficient.
N#
Application
OS
File System
Guardat
Device
Demonstrate policy compliance:
1. Download binary + certificate
2. Begin transaction tx (+ certificate)
3. Write new binary
4. Commit transaction tx`
Metadata:
Trusted Controller
Transaction cache
N#
N#
23
Outline
Design Principles
2
1
Declarative
Policies
Enforcement
File
Attestation
Guardat
Transaction
Implementation & Evaluation
24
Implementation
Alternatives:
1. Hybrid Disk/RAID controller
2. Microcontroller on SCSI/SATA adapter
3. VMM
4. Storage area Network (SAN)
Trusted controller in iSCSI Enterprise Target (IET) server
Guardat IET
server
Trusted Controller
(~ 20,000 LoC)
Network
Data Disk
(HDD/SSD)
Metadata
(SSD)
25
SSD Throughput overhead: < 2%
• 3.8 Million files
• 40,000 policies
Throughput in MB/S
600
500
400
300
200
Better 100
0
Seq. read
iSCSI
Guardat
Seq. write
Access type
512B Access Latency
HDD latency overhead: < 1%
Latency in ms (log)
10
iSCSI
1
Guardat
Better 0.1
Random Sequential
Reads
Latency in ms
0.3
0.2
0.1
Better
0
Random Sequential
Writes
SSD latency overhead
iSCSI
Guardat
Random Sequential
Reads
Random Sequential
Writes
Protected Apache Web server
Protection:
• Append-only logs
• Vendor-only update
executables
• Owner-only update
to content pages
Requests/s
250
200
150
100
50
0
Better
2% overhead at
peak throughput.
iSCSI
Guardat
60
Concurrent HTTP Clients
Scenario:
• Modified Apache (added 51 Lines of code)
• Hosting 220 GB English Wikipedia (~15M files)
• Replay an hourly access distribution of Wikipedia
28
Conclusions
• Guardat guarantees confidentiality and integrity of
persistent data and state of a system.
• No need to trust higher software layers.
• Guardat protects computer systems from
unauthorized access, trojans and log manipulations.
• Efficient prototype implementation in SAN server.
29
Guardat: Enforcing data policies
at the storage layer
Eslam
Elnikety
Aastha
Mehta
Peter
Druschel
Rodrigo Rodrigues
Anjo Vahldiek-Oberwagner
vahldiek@mpi-sws.org
30
Backup slides
Backup slides
31
Guardat: Related work
• TCG storage work group spec [2012]
– Architecture for sessions, access control policies
– Concrete design, evaluation left to vendors
– No object attestation
• TC: Semantic attestation [Haldar 2004], Excalibur [Santos 2012],
Pasture [Kotla 2012]
• Integrity/confidentiality: self-encrypting disks, capability NAS
[Aguilera 2003], type-safe disks [Sivathanu 2006], Venti [Quinlan
2002], S4 [Strunk 2000], NetApp SnapVault, PCFS[Garg 2010],
PFS[Walsh 2012]
• Extended disk functionality: hybrid disks, object-based storage
[Mesnier 2003], active disks [Riedel 2001], semantically smart disks
[Sivathanu 2003], differentiated storage [Mesnier 2011]
• VMM/OS data protection: Overshadow [Chen 2008], InkTag
[Hofmann 2013], Nexus [Sirer 2011], DCAC [Xu 2014]
32
Related work: Trusted Computing
Property
Trusted computing
Guardat
Root of trust
TPM
TGC
Authenticates
Motherboard
Guardat device
Certifies
HW/SW configuration
(remote attestation)
Object state + policy
(object attestation)
Storage property
provided
Confidentiality +
Read integrity
Confidentiality + Write
integrity
Properties expressed in Trusted software
Policy language
TCB
TPM + trusted SW
TGC (narrow API)
Persistent secure state
NVRAM
Entire storage device
Mostly complementary; can be combined, e.g.,
• Remotely attested external verifier
• Tamper-resident persistent storage
33
Threats to persistent data
•
•
•
•
•
Storage media failure (deterioration, obsolescence)
Natural disasters and physical attack
Operator error and negligence
Software/hardware bugs
This talk
Cyber attack and sabotage
Problem is real: Among most frequent causes of loss
• Human error is (close) second to device failure
• Software errors + viruses third
34
Discussion: Enforcement layer
35
Legacy FS
36
Transaction API
37
Stateful policies
38