Proving Confidentiality in a File System Using DISKSEC

Proving confidentiality in a file system using DISKSEC Atalay Ileri, Tej Chajed, Adam Chlipala, Frans Kaashoek, and Nickolai Zeldovich, MIT CSAIL https://www.usenix.org/conference/osdi18/presentation/ileri This paper is included in the Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’18). October 8–10, 2018 • Carlsbad, CA, USA ISBN 978-1-939133-08-3 Open access to the Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX. Proving confidentiality in a file system using DISKSEC Atalay Ileri,˙ Tej Chajed, Adam Chlipala, M. Frans Kaashoek, and Nickolai Zeldovich MIT CSAIL Abstract challenging to specify. For example, consider a natural specification for readdir, which allows the file system to SFSCQ is the first file system with a machine-checked return the names in a directory in any order. This nonde- proof of security. To develop, specify, and prove SFSCQ, terminism could be abused by a buggy or malicious file this paper introduces DISKSEC, a novel approach for rea- system to leak confidential file data through careful ma- soning about confidentiality of storage systems, such asa nipulation of the order of readdir results. Furthermore, file system. DISKSEC addresses the challenge of specify- nondeterminism is essential to a file system, because file ing confidentiality using the notion of data noninterfer- systems must deal with crashes, which can occur nonde- ence to find a middle ground between strong and precise terministically at any time. information-flow-control guarantees and the weaker but One approach to specifying confidentiality is to for- more practical discretionary access control. DISKSEC mulate it as a noninterference property, such as in most factors out reasoning about confidentiality from other information-flow-control systems. This means that the properties (such as functional correctness) using a no- execution of one process (a potential victim processing tion of sealed blocks. Sealed blocks enforce that the file confidential data) cannot influence the execution ofan- system treats confidential file blocks as opaque inthe other process (an adversary trying to learn that data). Non- bulk of the code, greatly reducing the effort of proving interference can be stated concisely, and is easy for appli- data noninterference. An evaluation of SFSCQ shows cations to use. However, information-flow-control style that its theorems preclude security bugs that have been guarantees are stronger than what file systems aim for. found in real file systems, that DISKSEC imposes little Instead, file systems aim for weaker notions of confiden- performance overhead, and that SFSCQ’s incremental tiality, along the lines of discretionary access control on development effort, on top of DISKSEC and DFSCQ, on files that reveal some metadata, such as file lengths. which it is based, is moderate. A second challenge lies in proving confidentiality. Con- 1 Introduction fidentiality is a “two-safety” property [34], which requires reasoning about pairs of executions to show that an ad- Many security problems today stem from bugs in software. versary cannot observe any differences correlated with Although there has been significant effort in reducing confidential data. However, reasoning about pairs of exe- bugs through better testing, fuzzing, model checking, and cutions is more complicated than reasoning about a single so on, subtle bugs remain and continue to be exploited. execution, which is sufficient for proving integrity and Machine-checked verification is a powerful approach that functional correctness. can eliminate a large class of bugs by proving that an This paper presents DISKSEC, an approach for proving implementation meets a precise specification. the security, and specifically confidentiality, for storage Prominent examples of machine-checked security systems, such as file systems. The paper demonstrates proofs include verification of strict isolation (with confi- the benefits of DISKSEC by developing, specifying, and dentiality) for an OS kernel in CertiKOS [15], seL4 [26], proving the security of a file system in a prototype called and Komodo [17], as well as security proofs in Iron- SFSCQ, based on the DFSCQ file system [13]. clad [20] about applications like a password hasher and DISKSEC addresses the specification challenge by us- a notary service. However, proving the security of sys- ing a notion of data noninterference that both matches tems with rich sharing semantics, such as file systems, what file systems aim to provide and is concise andeasy is an open problem. For example, unlike prior examples to use for applications. Data noninterference requires that that focus on strict isolation without controlled sharing, an adversary’s execution be independent of the contents users in a file system can share files with one another, and of individual files, but it allows the adversary to observe the underlying implementation has shared data structures other metadata, such as file length and directory entries, (such as a buffer cache or write-ahead log) that contain and allows for discretionary access control (i.e., a user data from different users. can choose to disclose their data). Proving security for a file system requires addressing To address the challenge of proving security, DISKSEC two key challenges. The first challenge lies in specify- factors out reasoning about confidentiality from all other ing security. Integrity can be expressed as simply as a properties, such as functional correctness. DISKSEC does functional correctness property. Confidentiality is more so by introducing a notion of sealed blocks. This builds USENIX Association 13th USENIX Symposium on Operating Systems Design and Implementation 323 on the intuition that file systems do not look inside of data noninterference can be thought of as a specializa- the blocks that represent user file contents. As a result, tion of abstract noninterference [18], relaxed noninterfer- DISKSEC is able to treat confidential file blocks as opaque ence [24], or observation functions [15]. One difference in much of the file-system code, greatly reducing the need in our approach is that data noninterference stops at the for manual proofs of two-safety that consider pairs of file-system API boundary; applications are not subject executions. The only manual proofs of two-safety are in to data-noninterference policies. This matches well the the top-level read and write system calls. traditional discretionary access-control policies enforced We implemented DISKSEC and SFSCQ in the Coq by file systems. proof assistant [35]. All proofs of security are machine- Formalizing data noninterference requires reasoning checked by Coq, eliminating the possibility of bugs that about two executions, since confidentiality is a two-safety violate SFSCQ’s specification. An evaluation of SFSCQ property [34]. In this context, our contribution lies in a shows that its specifications are complete enough to prove specification and a proof style based on sealed blocks that confidentiality of a simple application. The evaluation helps us prove a data-noninterference two-safety property also shows that DISKSEC’s approach allowed us to de- about the file system. velop SFSCQ with a modest amount of effort, and that SFSCQ achieves comparable performance to the DFSCQ Machine-checked security in systems. Several prior file system that it is based on. projects have proven security (and, specifically, confi- The contributions of this paper are: dentiality) properties about their system implementations: • SFSCQ, the first file system with a machine-checked seL4 [23, 26], CertiKOS [15], and Ironclad [20]. For proof of confidentiality. SFSCQ has a concise specifi- seL4 and CertiKOS, the theorems prove complete isola- cation that captures discretionary access control using tion: CertiKOS requires disabling IPC to prove its security data noninterference, and deals with nondeterminism theorems, and seL4’s security theorem requires disjoint due to crashes. sets of capabilities. In the context of a file system, complete isolation is not possible: one of the main goals of a • DISKSEC, an approach for specifying and proving file system is to enable sharing. Furthermore, CertiKOS confidentiality for storage systems that reduces proof is limited to proving security with deterministic specifi- effort. DISKSEC uses the idea of sealed blocks to cations. Nondeterminism is important in a file system factor out reasoning about confidentiality from most to handle crashes and to abstract away implementation of the file system code. details in specifications. • An evaluation that demonstrates that DISKSEC’s ap- Ironclad proves that several applications, such as a no- proach leads to negligible performance overheads in tary service and a password-hashing application, do not SFSCQ, that it precludes the possibility of confiden- disclose their own secrets (e.g., a private key), formu- tiality bugs that have been found in existing file sys- lated as noninterference. Also using noninterference, Ko- tems, and that SFSCQ’s specification allows applica- modo [17] reasons about confidential data in an enclave tions to reason about their confidentiality. and showing that an adversary cannot learn the confiden- Our SFSCQ prototype has several limitations. Since tial data. Ironclad and Komodo’s approach cannot specify it relies on Coq’s extraction to Haskell, inherited from or prove a file system: both systems have no notion

Load more