Design and Implementation of the Log-based File I/O Library for Sandboxing CSE 542 Operating Systems Fall 2005 Qi Liao and Xuwen Yu

Introduction What is sandboxing? Create confined execution environment Confine the activities of untrusted program in a limited domain Related Work: The sandboxing tech. often prevent unwanted access by simply denying actions that are not permitted. …… However, sometimes it is not clear if an action is desirable without looking at all of a program's actions together. So, how to keep the system secure and at the same time not influence the sandboxed process?

What we need to do? At the first step,we design a file I/O library to redirect the file I/O operations to the log file. It is secure and will not influence the sandboxed process Log file can also be examined to see the overall effect of a program. Log file can be committed and replayed If acceptable: the log can be played to modify the file system the log even can be played on another host to modify its file system. ( as patches generation) Next step is to apply the log-based file I/O library to a sandbox such as Parrot for further testing and improvement.

System Design  Design  Strictly sequential operations;  One operation followed by data if data writing is involved.  Data structure  Main log table design  Auxiliary table design  Procedures  I/O requirement  Record the operation  Check the table and record the return value;(success or fail)  Modify the table; record the data; Open file1 ＊ Open file2 ＊ Write file1 ( fd1, buff, length) ＊＊ Modification data of file1 Write file2 ( fd1, buff, length) ＊＊ Modification data of file2 Entry filena me fdfd in_log _bit Live/dead bit status_bitcur_offset

Main Lookup Table Entry 0 — in FS 0 — dead 0 — close 0 — beginning of file 1 — in Log 1 — live 1 — open for read file.size() — append flag 2 — open for write others 3 — open for r/w Hash table (hash filename  int % big prime) External linked list for collision handling File nameFdIn_log_bitLive/dead bit Status bitCur_offsetCacheable bit Pointer to read cache

Log Operations: Open, Close  Open:int pfs_log_open(string filename,int flags,mode_t mode);  Close:void pfs_log_close(int fd);  set the open status bit of the file’s entry to be 0.  If open a new file and no live entry in table: add the entry; else return error;  If open an existing file : if in log: already opened or deleted: return -1, otherwise :modify open status bits in entry; if not in log: check real file system: if the file exists,add an entry to table, otherwise return -1

Log Operations: Read, Write, Lseek, Remove  Read:void pfs_log_read(int fd,char * buf, unsigned int length);  Write:void pfs_log_write(int fd, const void * buf, unsigned int length);  Check if the file is created in log or in the real file system - if in real system, need to read original file;  Scan through the log and read all the modification data  Read relative data to the buffer  Update the length field in the entry.  Append actual written data to the log.  Lseek: void pfs_log_lseek(int fd, off_t offset, int whence);  Remove: int pfs_log_remove(const char * filename);

Log Operations: Write and Read Table Write and Read Log Table void pfs_log_write_table(); void pfs_log_read_table(); Write and read table entries between memory and disk.

Log Operations: Replay Log Replay void pfs_log_play(); Parse Table for Read Operation and Log Play Operation

Experimental Results and Optimization of Prototype 1.Auxiliary Table Problem: most of the search operations in the write and read calls require search based on the file descriptor while the key of the main table is the filename. Solution: maintain another auxiliary table which is indexed by the file descriptor. Performance Comparison of Write Operations between With and Without Auxiliary Table as Table Size Increases. (concurrently opened 50 files and randomly write 1000 times)

Experimental Results and Optimization of Prototype 2.Cached File for Read Operation Problem: Read Operation is the bottleneck. Must be efficient enough to make logging practical. Observation: Most files are not modified from previous read. No need to scan the whole log over and over. Solution: Cache the file in memory and set cache flag in table. Any write void cache. Comparison between cached and no-cached reading of 1 byte for 1000 times after a random lseek operation.

Experimental Results: Open, Close, Write, Read, Lseek Open (create new files) and Close Operation Time in Unix and Log Comparison of Read and Write Operations between Unix Standalone File System and Logging Process (Unit: Milliseconds)

Conclusion Log-based file I/O library can be used in existing sandboxes to record and handle the interposed I/O system calls. Table structures and careful design of log operations are necessary to provide a consistent view of system state to sandboxed processes. Performance can be dramatically improved by optimizing data structures and caching policies. Logging is feasible and desirable in sandboxing.

Future Work Efficiency Improvement read, write, log play Connect to Parrot Support more functions More system calls, directories, etc. Grid Computing Remote I/O operations