Intro - Despite growing awareness of the need for security in computing systems, current efforts to provide security are unlikely to succeed because they suffer from a flawed assumption. In this talk and our paper, we discuss why failure is inevitable if security efforts continue on their current path and call for a course correction. Agenda - Start by identifying the flawed assumption, counter it with our own thesis. - Address objections arising from the fact that our thesis is not new and has significant historical baggage. - Identify missing links which are necessary to solve the problem. - Examine the specific assumptions of one example security mechanism, and how the missing links can provide a sound basis for those assumptions. - Argue that no other approach will suffice. - Lay out what must be done to reach the goal. The Inevitability of Failure - State flawed assumption of current security efforts, counter with our thesis. - Evidence for the thesis is supplied in the presentation and paper, as well as by many others past and present. Deja Vu 1 - Customers are buying systems with inadequate security for their needs in ignorance of the risk; vendors are selling systems with inadequate security; security practitioners are developing solutions which ignore the premise, paying at most lip service to it. - Some people are actually suggesting that it is false, examples in NSPW, '97 IEEE TCB debate. - Past workaround of assuming homogenous enclaves is no longer feasible. - Malicious code threat significantly higher - DEFCON6 provided a recent example of the threat from trojan horses Deja Vu 2 - None of the mainstream vendors bet on secure operating systems; just dalliances. Secure OS products always secondary, separate, behind the power curve in application support. Really only prototypes, no higher level support (eg policy administration), poor system integration, poor performance. Negatives due to lack of mainstream support, commitment, second thought syndrome, not due to security. Came closest to goal in Multics. - Even security practitioners failed to demand secure operating systems to support their own work and failed to convey the real threat to the end customers. - TCSEC was an important contribution, but its use created many problems in causing the very notion of a secure operating system to be dismissed by customers. Encouraged the myth that MAC is only for the military. - There is a point where the cost exceeds the benefit, but a secure operating system doesn't push you there. In fact, the comparative cost of securing applications is much higher, and doesn't scale. Without a secure operating system, the benefit of any security measures is very limited. If you have valuable data, you need an SOS. - Lacking/ignoring functionality: eg networking (or network security), management, application integration Missing Links - Critical elements which are missing from mainstream operating systems. Not an exhaustive set, but foundational elements which have a high value for security. A starting point for improvement. - Exactness of assurance: demonstrate that features provide the desired functionality and nothing else. - System assurance requires showing that your notion of security is met by the set of properties, beyond scope of just the operating system. - Assurance isn't just formal methods. Good software engineering is a step in the right direction. CMU SEI studies have shown that good software engineering actually reduces overall development and maintenance costs. Research still needs to be done in finding ways to leverage existing assurance work as systems evolve, and to address composability issues. - Although features are undependable in the absence of assurance evidence, they still have value. The lack of assurance evidence doesn't guarantee that the features are incorrect. Mandatory Security: Definition - Before talking about the key gains of mandatory security, we need to clearly define what we mean by the term. Differences in the definition of mandatory security has led to confusion. - Some limit the term mandatory security policy to policies that are global and persistent, ie particular information has the same security attributes wherever it is and at all times. Such policies are important, since only they can provide true confinement. However, it is inappropriate to classify all other policies as discretionary, eg a configuration of type enforcement or Clark-Wilson or dynamic RBAC. Hence, we use "mandatory" or "nondiscretionary" to mean administratively controlled, and view global and persistent as an especially important subset of the set of mandatory policies. - To further clarify our definition of mandatory security, we must also lay out our definition of discretionary security. Some define discretionary security policy to mean policies which are based on identity. But this means that an identity-based policy which can only be changed by an administrator is called "discretionary", which seems inappropriate. We define it to mean policies controlled by ordinary users. - Based on our definition, every kind of policy can be either mandatory or discretionary, depending on who may change the policy. - Operating systems must support this more flexible notion of mandatory security. Our own research is in this area, and we have developed a series of prototypes, DTMach, DTOS and Flask, working collaboratively with Secure Computing Corporation throughout and with the University of Utah Flux group on Flask. Our most recent prototype system, Flask, is described in the paper listed here, available under the listed URL. There are also links from that URL to information on our prior prototypes. - Other policies tend to be driven by the access control policy. The mandatory cryptographic usage policy extends the guarantees of the access control policy beyond the boundaries of control of the TCB. The authentication usage policy is likely to require stronger mechanisms when authenticating a subject for an especially privileged access control domain. Mandatory Security: Key Gains - Mandatory security mechanisms in the operating system offer several key gains over just providing security in applications. - State the gains. - "legitimate users with limited authorization" - preventing legitimate users of the system from accessing data in ways which violate the policy - "authorized users unwittingly using malicious applications" - preventing malicious applications from accessing data in ways which violate the intent of their user - Mandatory security mechanisms in the operating system make it possible to achieve these gains, but the mere existence of such mechanisms does not automatically achieve that end. The mandatory security policy must be carefully defined in order to achieve these gains. Some of the gains require the flexibility mentioned previously, eg support for enforcing MLS doesn't help protect secured applications against tampering or bypass, but support for enforcing type enforcement policies does. Type enforcement policies only provide global and persistent guarantees if configured to do so, and are prone to misconfiguration, while a BLP or Biba policy trivially provides global and persistent guarantees. - With global and persistent policies, mandatory security mechanisms can go beyond strong separation of applications and provide true confinement. - (optional) Many modern systems (Exokernel, VSTa, Fluke, L4) emphasize the importance of being able to dynamically subset existing protection domains to an arbitrary degree, eg to permit a user to execute a browser in a restricted environment and to permit the browser to execute helpers in restricted subenvironments. This is valuable, and supported by Flask (through extension policies), but still requires that the outermost policy provide strong boundaries. Thus, mandatory security is a foundation on which these constrained subenvironments may be constructed. - These key gains cannot be provided solely through application-layer security mechanisms. Mandatory security mechanisms in the operating system provide better protection, and at a far lower cost than attempting to provide "total" security in each application, which isn't feasible anyway. Trusted Path and Protected Path - Trusted path as in the TCSEC definition - Trusted path permits functions to exist which might otherwise not be allowed due to threat of malicious applications. Can prevent malicious applications from obtaining sensitive information, performing functions on behalf of user which violate user's intent or tricking user into believing that a function has been invoked without invoking it. - Trusted path obviates need for extra rules in system which arise due to threat of malicious applications beyond the human rules (eg suspending the *-property for a trusted downgrader which uses a trusted path mechanism). - Even in the absence of hardware support for trusted path, an OS-provided trusted path mechanism increases the difficulty of spoofing attacks by malicious applications. OS developers should provide the OS-level support, and state requirements on hardware developers for future hardware support. - Protected path is a slight variation of the TNI's notion of a trusted channel for network trusted paths. Example of cryptographic service provider. Typically just an extension to existing OS IPC mechanism. Flawed Assumptions - Current security efforts will fail due to their flawed assumptions. Each of these assumptions are flawed because they depend on the operating system, but current mainstream operating systems cannot adequately support these assumptions. - Here we examine the flawed assumptions of one example from our paper, application-space cryptography. A similar analysis can be applied to any form of application-space security, and our paper applies such an analysis to... Given another 90 pages for our paper, we could have easily filled them with the corresponding analysis of the vast array of currently existing security solutions. - Application-space cryptography is more than just software cryptography; any application-invoked cryptography, including application-invoked hardware cryptographic token. - The first assumption can be also be stated as "cryptography is invoked when you think it is and in the manner you think it is." - With an inline hardware cryptographic device, none of the assumptions depend on the operating system. However, this isn't application-space cryptography, and it is very inflexible and coarse-grained. With an application-invoked hardware cryptographic token, the first three assumptions rely on operating system protection. Without a hardware cryptographic token, all of the assumptions rely on operating system protection. Meeting the Need - Here we examine how the missing link features can meet the assumptions of application-space cryptography. A similar analysis is performed for the other examples in our paper. - Various combinations are possible. For example, controls over the use of the cryptographic component could be enforced by the operating system through the mandatory security mechanisms or by the cryptographic component itself based on the client identity provided by the protected path mechanism or by a combination of both. The mandatory security mechanism may limit the ability of malicious applications to use the cryptographic component, thereby reducing the need for trusted path invocation. This is particularly important, because it isn't practical to have explicit user authorization for every cryptographic operation. No Other Way - Remind audience of our defn of discretionary security. - Current mainstream operating systems only provide discretionary security mechanisms, and only a weak form of discretionary security in which the policy can be changed by ordinary users _and their programs_ (the last portion is not part of our more general defn of discretionary security). - Discretionary security only protects information from legitimate users with limited authorization if all of the authorized users are benign and extremely careful about protecting their own objects, and even then it doesn't protect indirect observation of information. Harder to place any confidence in system with only discretionary security, too many people to trust (not just in terms of their integrity, but also in terms of their freedom from making mistakes). - These discretionary security mechanisms provide no protection against malicious applications executed by authorized users. Reaching the Goal - State as "We believe that..." - New research and development: assurance techniques for new OS paradigms, incremental assurance, composability, formal methods, policy and mechanism flexibility, policy reconciliation, trust issues, proper roles of applications vs. OS in security, proper roles of OS components in security - This will lead... - We must not settle for mediocrity! - Market trends depend on you. If you continue to place a higher priority on other things, the market will follow you. The market believes that you would rather have a dancing paperclip than security, and sales back them up. This must change!