Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Rootkit-Resistant DisksStephen McLaughlin
CSE 544 - Systems Security, SP 2010
1
in conjunction with Kevin Butler and Patrick McDaniel(Slides adapted from Kevin Butler’s. (The good one’s are Kevin’s.))
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Trust models so far
• Applications
‣ Exploits, command injection, confused deputy
‣ Kaput
• Operating System
‣ IOCTL, sysfs, procfs, NETLINK, /dev/mem, Windows User-Mode Driver Framework
‣ Rootkits: User-based, kernel-based, persistent and non-persistent
• Virtual Machine Monitor ???
2Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Won’t happen
3Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What’s left?
• Mediation = regulating usage of data.
• All data ultimately resides in persistent storage.
• The disk interface is the first line of defense for data.
‣ (And a restricted one at that.)
• BUT
‣ Disks have traditionally been just bit buckets
4Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Storage Today
• Disk systems are being increasingly equipped with their own memory and processing capabilities
‣ e.g., hybrid hard disks (NVRAM), FDE drives (crypto ASIC)
• Narrower interface means limited interaction with the rest of the system
‣ Downside: limited context for information being received from the operating system and the file system: disk is only exposed as a block device (semantic gap between layers)
5
non-volatile memory
disk
plattersfirmware
bus
I/O
SATA/
SCSI/
ATA
interface
ASIC
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Semantic Gap
• MPS for storage
‣ Subjects?
‣ Objects?
‣ Operations?
6Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Semantic Gap
• MPS for storage
‣ Subjects?Just one: the entire host system
‣ Objects?
‣ Operations?
7Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Semantic Gap
• MPS for storage
‣ Subjects?Just one: the entire host system
‣ Objects?Blocks
‣ Operations?
8Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Semantic Gap
• MPS for storage
‣ Subjects?Just one: the entire host system
‣ Objects?Blocks
‣ Operations?Read / Write
9Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Semantic Gap
• MPS for storage
‣ Subjects?Just one: the entire host system
‣ Objects?Blocks
‣ Operations?Read / Write
10
Label state, transition state, credentials???
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Need to add semantics
• First, we should understand what type of policies can be reasonably enforced
• Disks not useful for secrecy
‣ Once a block is read, it’s gone
• Disks very useful for integrity
‣ Storage is the last stop for every write
• Policies stack nicely
• Every modification to a piece of data is mediated
• Integrity violation is required for a particular class of attack ...
11Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Rootkit Persistence• Infecting the storage makes a bad problem worse
• Rootkits may try to make themselves persistent
‣ modify binaries or configuration files to insert themselves into the boot process
• Q: How do you know if the rootkit has been eradicated if it becomes persistent?
‣ A: You don’t -- only surefire way of removing it is to wipe the disk clean and reinstall the OS
‣ Solving the problem of rootkits is akin to solving the general problem of malicious software
‣ However... what if we can prevent rootkit persistence?12
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Goals for a disk solution• Protection against real rootkits
‣ demonstrable protection against currently deployed persistent kernel-level rootkits
• Usable without user interaction and with minimal administration
‣ transparent operation
• Highly performant
‣ minimize performance overhead
• Low storage overhead
‣ as little metadata storage as possible13
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Rootkit-Resistant Disks• Disk enforcement of block immutability prevents critical
data from being overwritten by malicious agents
‣ Hence, preventing a compromised OS from infecting its on-disk image
• Users directly interface with the disk using a physical token, creating a trusted path to the disk
‣ token carries a capabilitythat provides contextto the disk
14
drive enclosure
non-volatile memory
disk
plattersfirmware
bus
I/O
SATA/
SCSI/
ATA
interface
token
interface authorization
point
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
RRD Overview
• Under normal operation where no tokens are present, the RRD is used as a regular disk
• When a token is inserted, blocks written are labeled with the token’s label and marked as immutable
• Once that token is removed, any writes to the labeled block are blocked
‣ malicious software unable to write itself to immutable portions of the disk - prevents rootkit persistence
15
Disk
NVRAM
Current Token
App
File System
App
File System
Host
Write OK Write Denied
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Extended Filesystem Layout
16
boot block
super-block
block GDT
block bitmap
inode bitmap
inode table data blocks
backup SB
backup BGDT
block bitmap
inode bitmap
inode table data blocks
block bitmap
inode bitmap
inode table data blocks
backup SB
backup BGDT
block bitmap
inode bitmap
inode table data blocks
block bitmap
inode bitmap
inode table data blocks
byte 1024
Blk grp 0Blk grp 1Blk grp 2Blk grp 3Blk grp 4
. . .
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
RRD Setup & Operation• Initial installation of the drive best done from a
trusted boot (e.g., root of trust install)
• Initial disk setup is a three-step process:
‣ Write filesystem structures that need to be written by any process (e.g., journal, log, block & inode bitmaps) with permanently mutable token
‣ Write critical system data (e.g., MBR, boot loader, kernel, kernel modules), system binaries and configs with immutable token
‣ Rest of installation and subsequent operation of disk performed without a token
• Tokens only necessary again when upgrading OS17
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Upgrading
• Upgrades should have their own runlevel to prevent pollution of blocks with the immutable token
‣ something akin to single-user mode
‣ Vista supports something similar: shuts down services before upgrades are applied
• OS must sync buffers with the disk before entering and leaving this runlevel
‣ Same rationale, want to prevent block pollution
18Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Block Write Policy
19
1: for all blk in Request do2: !b !LABELOF(blk)3: !t !LABELFROMTOKEN()4: if !b "= nil and !b "= !pm and !b "= !t then5: return ‘Write denied’6: end if7: if !b = nil and !t "= nil then8: !b ! !t
9: end if10: end for11: return ‘Write OK’Algorithm 1: RRD-write. Only if a block is unlabeled or has thesame label !t as the inserted token will the write be successful;otherwise, if there is a label mismatch or if the block is labeledpermanently mutable !pm, the write will fail.
when files are deleted. This leads to labeled blocks becoming unus-able, as while they have been freed by the file system, they remainwrite-protected by the disk. We find in our examination of labelcreep that its effects on an RRD are limited; we investigate thisfacet of operation through experimentation in greater detail in Sec-tion 4.3. It is possible to mitigate the effects of label creep throughunlabeling of tokens; we explore this in further detail in Section 5.
2.5 RRD OperationWe now outline the steps by which an RRD would be set up and
operated. An RRD may be shipped pre-formatted with the appro-priate labeled tokens, or the user may perform the initial set up ofthe device. It is important at this stage to boot the system where thedisk is to be set up into a state that is free of rootkits that may infectthe machine; the disk is in a vulnerable state at this point. While atrusted boot prior to the installation of an RRD (and with regardsto BIOS integrity) is outside the our scope of feasibility, a methodof ensuring a trusted system setup could involve the use of a root oftrust installation [56] where the system is booted from a trusted CDand the subsequent boot and installation is measured for integrityat every stage.
Once the system is booted, the disk may be formatted. The sim-plest and safest manner for setting up the drive is to define a systempartition that holds the OS binaries and configuration files, and auser partition for other data. During partitioning, the token mustbe inserted to protect the MBR. The system partition may then beformatted without an installed token such that the filesystem is mu-table (i.e., data may be written to it). As mentioned above, cer-tain special filesystem structures (e.g., a filesystem journal2) mayneed to be always writable. The blocks allocated to these struc-tures should be written with the permanently-mutable token. Wedescribe this process in more detail in Section 5.
At this point, the operating system may be installed on the disk.A token should be inserted in the disk to move the RRD into admin-istrative mode. This will render important binaries (e.g., programsinstalled in the /usr/bin hierarchy in a UNIX-like system) andconfiguration files immutable. Finer-grained access is possible atthis point; for example, if there is a desire for access to writingbinaries to be decoupled with access to configuration files, the in-staller can be partitioned to first write the binaries with an appropri-ate binaries token before writing configuration files (e.g., the /etc
2Note that we do not currently support full journal functionality ina filesystem like ext3, because journaled data may be written to la-beled blocks at a time when the token is not in the disk. We discussa small filesystem modification that supports full ext3 journaling inSection 5.2.
hierarchy) with a configuration token. Once the installation is com-plete, the user partition may be formatted and the disk is ready tobe operated.
Normal operation of the system should preclude the need forany involvement of physical tokens. Only when system updates orchanges to the configuration are necessary will tokens be necessary.To prevent the token from affecting other files during an upgrade,it is optimal to perform these operations in their own runlevel, suchthat processes are stopped and labels are not inadvertently writtento incorrect blocks. It is also important that the operating systemsynchronize its data with the disk by flushing buffers (e.g., throughthe sync command) when the upgrade is completed and before thetoken is removed. At this point, the system may return to its pre-vious runlevel and operations may continue as usual. Note that wecannot protect against system upgrades that are already compro-mised as may be the case, and protections against upgrade tamper-ing are insufficient in current software update mechanisms [4]. AnRRD can protect against persistent rootkits that attack the systemwhen the token is not installed, but if a program contains a trojanor other exploit and is installed when an administrative token ispresent, it will have the ability to attack the boot process and installitself to maintain persistence.
3. PROTOTYPE IMPLEMENTATIONWe implemented an RRD that fulfills block requests over TCP.
The choice to use a network interface was made as developmentof firmware for commodity disks is prohibitively difficult due to alack of open firmware and development environments. Our proto-type RRD provides the same functionality and security guaranteesdescribed above, and can be used as the root partition of a run-ning system. Because the prototype exports a nonstandard inter-face, we developed a driver for disk-to-host communication. Thisdriver would normally not be necessary given a disk with a stan-dard interface, e.g. SCSI, and contributes nothing to the securityof our scheme. Finally, we create an installer to simplify the pro-cesses of installing a base system on an RRD. We now describe theimplementation details of our prototype, as well as the RRD driverand installer.
3.1 RRDThe prototype RRD has two components: a Linksys NSLU2 net-
work attached storage link [33], commonly referred to as a “slug”,and an external USB hard disk. The setup of this prototype is shownin Figure 2. The external hard disk is a standard model and offersno additional functionality beyond the typical SCSI command in-terface. The slug is a network storage link, an embedded devicethat acts as a bridge between an external USB hard disk and a net-work attached storage (NAS) device. It has one RJ45 jack whichprovides the network interface, and two USB-2.0 ports used for theexported storage devices. In our case, we use one of the USB portsfor the disk and the other for USB thumb drives which constitutethe physical tokens. The role of the slug is threefold:
• Receive block requests from the network;• Store and enforce the RRD’s policy;• Act as an entry point for physical tokens.
In order to develop software for the slug, we replaced its de-fault firmware with the SlugOS Linux distribution [50]. We thenuploaded netblockd, a server program we developed to satisfyblock I/O requests over TCP sockets. netblockd consists of2,665 lines of code and was cross-compiled for the slug using theOpenEmbedded framework [31]. netblockd satisfies all requests
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Tokenblock request
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
enforcement point
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
enforcement point
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implementation
• Linksys NSLU2 (“slug”) provides disk processing capabilities
• netblock provides block device over network to slug (only necessary because no direct interface access to disk)
• label read from token by netblockd, writes compared against BLOCK_LABELS
20
User Space
Kernel Space
Application
File System
RRD Driver*
netblockd*
Slug
udev*
/dev/sda
/mnt/nvram
/mnt/token
slugos 4.8Linux kernel
RRD Host
netblock
client*
External Drive
BLOCK-LABELS
Physical Token
enforcement point
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Evaluation• Setup: prototype RRD (slug: 266 MHz ARM IXP420
processor, 32 MB RAM), host running Ubuntu Linux 2.6.22 kernel
• Questions we consider:
‣ Defenses against real rootkits
‣ Performance overhead from block labeling
‣ Scalability due to labelconstraints
21Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Rootkit Defense• Ran live version of Mood-NT
against the RRD
• Rootkit failed to replace /sbin/init with its own initialization program, rebooted to normal state
• Examined chkrootkit scanner to validate
‣ found over 150 files that would be modified by 44 rootkits
‣ all marked immutable by RRD such that they cannot gain persistence
• Proper labeling of files on installation is critical
22
Adore: /usr/[lib|bin]/[start|stop].sh/usr/[lib|bin]/adore/usr/bin/atm
Ramen: /etc/inetd.confabManiac RK: /usr/bin/mailrct0rn: /sbin/src/.puta
/sbin/xlogin /lib/ldlib.tk/usr/info/t0rn/usr/local/lib/libproc.a
Lion: /bin/in.telnetd /bin/mjyRK17: /usr/bin/squit /usr/bin/pbackrsha: /usr/bin/n3tstat /usr/bin/kr4p
/usr/bin/chsh2 /etc/rc.d/rshaShitC: /usr/[bin|sbin]/[frgy|home|sy]
/usr/bin/in.slogindShowtee: /usr/lib/liblog.o
/usr/include/cron.h/usr/include/syslogs.h
Romanian: /usr/include/file.h /usr/bininclude/addr.h
HKRK: /etc/rc.d/init.d/networkESRK: /usr/lib/tcl5.3
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Filesystem Hierarchy Standard• Understanding file mutability can be informed through
application of the UNIX filesystem hierarchy standard (FHS)
‣ enables software and users to predict the location of installed files and directories
23
/
binbootetchomelibsbintmpusrvar
essential command binaries
static boot loader files
host system configuration
user directories
shared libs & kernel modules
system binaries
temp files
shareable read-only data
spool files, logs, etc.
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Filesystem Hierarchy Standard• Understanding file mutability can be informed through
application of the UNIX filesystem hierarchy standard (FHS)
‣ enables software and users to predict the location of installed files and directories
23
/
binbootetchomelibsbintmpusrvar
essential command binaries
static boot loader files
host system configuration
user directories
shared libs & kernel modules
system binaries
temp files
shareable read-only data
spool files, logs, etc.
binliblocalshare
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Filesystem Hierarchy Standard• Understanding file mutability can be informed through
application of the UNIX filesystem hierarchy standard (FHS)
‣ enables software and users to predict the location of installed files and directories
23
/
binbootetchomelibsbintmpusrvar
essential command binaries
static boot loader files
host system configuration
user directories
shared libs & kernel modules
system binaries
temp files
shareable read-only data
spool files, logs, etc.
binliblocalshare
binetcmansbin
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Filesystem Hierarchy Standard• Understanding file mutability can be informed through
application of the UNIX filesystem hierarchy standard (FHS)
‣ enables software and users to predict the location of installed files and directories
23
/
binbootetchomelibsbintmpusrvar
essential command binaries
static boot loader files
host system configuration
user directories
shared libs & kernel modules
system binaries
temp files
shareable read-only data
spool files, logs, etc.
binliblocalshare
binetcmansbinshare
etcman
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Evaluation
24
System Install microbenchmarks: Component Total Time % of measured
disk 340.5 53.8%
network 288.1 44.7%
security 16.4 2.5%
Postmark transactions per second:
Config. TPS % decrease
no security 235.1
security 231.7 1.4%
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Scalability
25
• Block label ranges take only a small amount of metadata storage
100
101
102
103
104
105
106
mkfs copy base upgrade 1 upgrade 2
Num
ber o
f Blo
cks
or R
ange
s
Ranges (ext2)Ranges (ext3)
Blocks Labelled (ext2)Blocks Labelled (ext3)
‣ less than 40 KB of storage for a 4 GB system on disk
‣ average label range size: 12 bytes
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Label Creep
• If a block is labeled immutable, the label cannot be changed (unless label is revoked): creates issue of label creep
• semantic gap between FS, storage prevents free space reclamation
• Evaluation: after installation and 2 system upgrades, about 10% of labeled data blocks subject to label creep (about 1% of entire partition)
‣ ext3 journal labeled permanently mutable, single constant increase in labeled block size (32,768 blocks)
26Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Once Upon atime• Consider the structure of an inode
27
mode UID size atime ctime
mtime dtime GID link cnt blck cnt
flags OS
pointers to blocks
...
file ver file ACL dir ACL frag OS
...
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Once Upon atime• Consider the structure of an inode
27
mode UID size atime ctime
mtime dtime GID link cnt blck cnt
flags OS
pointers to blocks
...
file ver file ACL dir ACL frag OS
...
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Useful FS Modifications
• Having the filesystem fail silently is suboptimal
• Recommended: an ACCESS DENIED message delivered to the filesystem such that writes don’t return BAD BLOCK messages and choose more appropriate inodes to write to
• We are investigating these modifications to ext3
‣ note that the system works without them, but it’s extra sugar for the user and the OS
28Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Disk Maintenance Tasks• Token duplication
‣ 2 available slots on disk, insert token to duplicate and blank token
• Backup
‣ duplicate backup token, retrieve another RRD and put backup token in that drive, connect together
‣ geometry does not need to be identical since block copy
• Revocation
‣ unlabel token placed in RRD with token to be revoked
‣ block labels associated with revoked token will be erased from RRD
29Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Working with Windows• RRDs are conceptually independent of the overlying
operating system and filesystem structures
• RRD solution would work in Windows with the following considerations taken into account:
‣ dealing with immutable file layout requires changes to installer (\Windows and \Windows\System should be immutable in Windows)
‣ immutable portions of the Windows registry (make certain hives immutable)
‣ Registry virtualization in Vista: remap read-only registry settings to user home directories (limits the effects of system registry settings going awry) = no writes needed
30Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Effects of Ext4
• Extents: are beneficial to us
‣ By setting larger ranges on where a file may write, longer series of contiguous blocks are allocated, meaning less metadata needs to be stored on the disk
‣ Multiblock allocation: similar benefits
• Allocate-on-flush (Delayed Allocation)
‣ Blocks allocated for pending writes are not allocated until flushed by OS
‣ Allows more contiguous writes but doubly important that sync must be called before immutable token released
31Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Lessons
• Enforcing block immutability at the disk can prevent malicious writes to critical operating system files, providing resistance against persistent rootkits
• Reference monitor guarantees at the disk level have wide implications for policy
• Future direction: RRD is a specific case of a more general problem
‣ what if we consider the binding of entire operating systems to a series of tokens and enforce a policy over that?
‣ what about allowing greater interaction with the host?32
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Future work:Token Usability
• Little work has been done in the area of token usability in a security context
‣ Piazzalunga et al. wrote one of the few studies explore security of tokens from user standpoint
• Our goal: Determine user experience with using token plugged into disk for administrative tasks
‣ regular operation first (e.g., email, web browsing)
‣ tasks requiring administrator (e.g., software update)
• How do interfaces in software and hardware affect user behavior and ability to make correct security decisions?
33Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Current Initiatives
• Investigating how to add the host to the TCB by validating it prior to allowing the disk to divulge data
• Using commodity trusted hardware on the host (e.g., TPM), receive attestations to integrity state
• Implemented prototype for portable storage, which tends to be used across a variety of hosts
• Formalized a notion of continuous attestations using LS2 logic of secure systems to prove secrecy and integrity properties
34Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Questions
35
Kevin Butler
Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Extra Slides
36Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Broader Case
• Device for enforcing MAC policy at the storage layer with a trusted path from the user directly to the disk
37Thursday, April 8, 2010
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Related Work
• NASD (Gibson et al., ASPLOS 1998)
• Active Disks (Riedel 1999)
• Storage-based Intrusion Detection (Pennington et al., USENIX Security 2003)
• Secure Versioning Disks (Sundararaman et al., USENIX Security 2008)
38Thursday, April 8, 2010
Top Related