Context Sensitive File System Britton Dennis Tyler Travis Clark - - PowerPoint PPT Presentation

context sensitive
SMART_READER_LITE
LIVE PREVIEW

Context Sensitive File System Britton Dennis Tyler Travis Clark - - PowerPoint PPT Presentation

Context Sensitive File System Britton Dennis Tyler Travis Clark Wood Outline Motivation Related Works System Overview Context Monitor File System Demo Problems / Future Work Q and A Motivation Context


slide-1
SLIDE 1

Context Sensitive File System

Britton Dennis Tyler Travis Clark Wood

slide-2
SLIDE 2

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-3
SLIDE 3

Motivation

 Context awareness is important:

 Mobile devices, BYOD  Cheap Storage  Ubiquitous wireless connections

 Ways related works fall short:

 Security  Transparency

slide-4
SLIDE 4

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-5
SLIDE 5

Related Works

 quFiles  Ext3cow  NCryptfs

slide-6
SLIDE 6

Related Works quFiles

 Way to implement context awareness at file level  quFiles directory stores different versions of the same logical file; serves appropriate file to application on demand  Transparent to applications  Not transparent to users

slide-7
SLIDE 7

Related Works ext3cow

 Way of doing file versioning / auditing by using copy on write on the inode structure  Appends snapshot epoch number to files  Semi transparent to applications  Not transparent to users

slide-8
SLIDE 8

Related Works NCryptfs

 Adds encryption to existing Linux file systems  Balanced security, performance, convenience, portability  Prevent clear text from being cached  Context unaware

slide-9
SLIDE 9

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-10
SLIDE 10

System Overview

 Proposed by Michael Mitchell  Our system is a proof of concept  Two components

 Context Monitor  File system

 Serves different files based on the security of the environment  The metrics we wanted to optimize were portability and security

slide-11
SLIDE 11

System Diagram

Context Monitor User Application e.g. Word User Kernel VFS Modified ext3

slide-12
SLIDE 12

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-13
SLIDE 13

Context Monitor

 Modular user level deamon built mostly in python  Each module polls a specific system internal (e.g. USB, Wifi, etc) for the current status  The module then calculates how secure that component is at the moment and assigns a number  Then all the numbers from all the modules are weighted according to the user’s policy and a general ‘security level’ is generated  This is then sent to the file system so that the file system knows whether to open ‘up’ or lock ‘down’ the file access  The information is passed down through ioctl calls to give an extra level of security and flexibility as opposed to syscalls or procfiles as the caller needs to know the call number and the magic number

slide-14
SLIDE 14

Context Monitor Main Flow

Context Monitor Context Analyzer FS Wireless Test GPS Test

USB Test Port Test

slide-15
SLIDE 15

USB Test

Context Monitor Test Case Flow

USB Module USB Level USB Level 1 USB Calculator USB Level n

Context Monitor

slide-16
SLIDE 16

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-17
SLIDE 17

File System

 Built from ext3 from kernel v3.8.5  For each file the user sees there are really n+1 files where n is the number of security levels  The extra n files have the same base name put append a separator string as well as the security level number  To keep secure data from being leaked, during a security level change, the file system will close all processes (as well as their children) that opened a file owned by the file system  To prevent name space collisions and secure information leakage, the read directory file operation will hide all files ending with our suffix (except the ones the user created which can be determined through a recursive scan)  To offer more data at higher security levels, the inode from the file at level i has blocks that point to all the blocks that inode at i-1 points to as well as some blocks only it can see.

slide-18
SLIDE 18

Foo.txt

File System Organization

File Foo.txt File Foo.txt:0 File Foo.txt:1 Dummy inode Level 0 inode Level 1 inode Physical Block 300 Physical Block 301 Physical Block 302 Physical Block 303

slide-19
SLIDE 19

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-20
SLIDE 20

Demo

slide-21
SLIDE 21

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-22
SLIDE 22

Problems / Future Work

 File system

 Get write to work  Try to eliminate the need to open/close files in kernel context  Fairly high chance that code contains locking issues and memory leaks  Run some benchmarks and get some performance numbers to see if this is even within in the realm of usability  Look into possible caching issues  Resolve naming collisions that occur from non regular files  Support other file operations  Add similar mechanism for other types of files, e.g.. Directories  Add support for an arbitrarily large number of different security levels

 Context Monitor

 Add other tests  Close file system if security level goes below acceptable limits  Add config options

 Provide a second user level program

 Allow users to view data blocks belonging only at a certain levels  Allow users to switch to a level lower than what is deemed safe

slide-23
SLIDE 23

Outline

 Motivation  Related Works  System Overview  Context Monitor  File System  Demo  Problems / Future Work  Q and A

slide-24
SLIDE 24

Q and A