Pastures: Towards Usable Security Policy EngineeringSergey Bratus, Alex Ferguson, Doug McIlroy, Sean SmithDartmouth CollegeAbstractWhether a particular computing installation meets itssecurity goals depends on whether the administrators cancreate a policy that expresses these goals—security in prac-tice requires effective policy engineering. We have foundthat the reigning SELinux model fares poorly in this regard,partly because typical isolation goals are not directly statedbut instead are properties derivable from the type definitionsby complicated analysis tools. Instead, we are experiment-ing with a security-policy approach based on copy-on-write“pastures”, in which the sharing of resources between pas-tures is the fundamental security policy primitive. We arguethat it has a number of properties that are better from theusability point of view. We implemented this approach as apatch for the 2.6 Linux kernel.1 IntroductionComputing systems typically depend on their operatingsystems to enforce trustworthy behavior. Architects and ad-ministrators describe this behavior in terms of various se-curity goals, such as protecting the integrity and confiden-tiality of data. To achieve these goals, architects and ad-ministrators should be able to configure them with securitypolicies that actually express these goals. Thus we reach apoint when policy engineering becomes a critical issue.The problem of engineering usable OS security policieshas been worked on for decades. However, we claim thatage does not imply maturity. The continuing trouble withsecurely configuring real systems for real applications inthe real world demonstrates the absence of the accepted andeffective best practice that would come with a solved prob-lem. Approaches based on formal models do not appearto have gained much traction with system administratorsand defenders, outside of a few small specialized commu-nities. Satisfactory approaches to securing systems in man-ageable ways are still being pursued and discussed1, and we1In particular, practitioner conferences, including the so-called hackerconventions like Defcon and Blackhat, often feature talks on exploratorymethods for protecting common server software known to be vulnerable.will later review several such approaches that enjoy de factopractitioner acceptance (most notably vserver and the use ofBSD jails for building virtual systems). We offer our ownwork as a contribution to this effort.In recent years, older ideas have re-emerged, with NSA’sSecurity-Enhanced Linux (SELinux) (e.g., [11]) consideredby many to be the de-facto best-of-breed for those want-ing a high-assurance but contemporary OS. Unfortunately,SELinux has a high cost from the point of view of usability:its monolithic and awkward policy structure makes it diffi-cult for programmers to configure and maintain it for real-world applications – and difficult for stakeholders to trustthat the resulting policy actually confines system behaviorto “secure” operation only.Previous studies (e.g., [4]) led us to the conclusion thatthe principal usability obstacles for the SELinux policy ap-proach are:• any reasonable degree of integrity protection requiresa large and complex policy, essentially profiling all theallowed accesses for protected applications;• by following the application execution profile, such apolicy becomes as complex as the original software –without any corresponding software engineering toolsto keep it manageable;• no protection can be afforded before such profiles arecompiled, a labor-intensive procedure.All of these obstacles are ultimately due to SELinux’sreliance on the fundamental and time-honored design prin-ciple of denying access if it is not explicitly permitted by thepolicy.In addition to these obstacles, checking if a SELinux pol-icy satisfies information flow goals is a non-trivial task, be-cause flow properties of the SELinux model cannot be ex-pressed explicitly in its policy language, but are instead de-rived from the type specifications, i.e. access profiles. Thuseven though flow goals are often of primary interest, theyare not first-order policy objects that can only be derivedfrom a rather large number of access statements.We explore an alternative approach, based on two prin-ciples:1• All accesses not explicitly allowed or denied by a pol-icy statement result in a copy-on-write (COW) duplica-tion of the accessed object, rather than a denial.• Flow properties are directly specified by the policyrather than derived from other kinds of statements.Specifically, sharing of resources between environ-ments isolated by default becomes a basic policy prim-itive.In order to implement these principles, we assign pro-tected applications to COW pastures or, for short, pastures,where a pasture is a security context similar to a vservercontext or a BSD jail, which contains private copies of filesmodified by processes assigned to it. The term, of course, isa pun on COW, the copy-on-write operation that adds newobjects to a pasture. The term also suggests the permis-sive nature of a pasture as compared to a “jail”: the pointof pastures is to allow programs to proceed by creating pri-vate copies of objects modified by their writes not explicitlylisted in an access profile, rather than terminating them fora violation of the profile.2 Our approach2.1 Revisiting typesWe consider the set of SELinux types as a set of inter-secting “access jails”, defining their allowed interactions.Indeed, the purpose of SELinux policy analysis tools ismostly to derive a description of such interactions (e.g.,the information flow between types). It seems that a di-rect specification of allowed flows combined with the de-fault integrity protection given by the copy-on-write names-pace isolation approach, could be much more concise andintelligible, being closer to the actual security goals ofmany administrators. The principal reduction in complex-ity will come from the conceptual simplicity of namespaceisolation-by-default.2.2 Motivating ExamplesLet us consider two motivating examples.Server protectionAn administrator runs a number of trusted and possiblyinteracting servers on a system wishes to introduce anew piece of third party software, say a license server.Not being sure of the security properties of this soft-ware, the admin would like to take steps to protect theintegrity of his other servers from its possible interfer-ence, whether unintentional or due to hostile
View Full Document
Unlocking...