Results 1 - 10
of
10
The Flask Security Architecture: System Support for Diverse Security Policies
- in Proceedings of The Eighth USENIX Security Symposium
, 1999
"... Operating systems must be flexible in their support for security policies, providing sufficient mechanisms for supporting the wide variety of real-world security policies. Such flexibility requires controlling the propagation of access rights, enforcing fine-grained access rights and supporting the ..."
Abstract
-
Cited by 114 (8 self)
- Add to MetaCart
Operating systems must be flexible in their support for security policies, providing sufficient mechanisms for supporting the wide variety of real-world security policies. Such flexibility requires controlling the propagation of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted access rights. Previous systems are lacking in at least one of these areas. In this paper we present an operating system security architecture that solves these problems. Control over propagation is provided by ensuring that the security policy is consulted for every security decision. This control is achieved without significant performance degradation through the use of a security decision caching mechanism that ensures a consistent view of policy decisions. Both fine-grained access rights and revocation support are provided by mechanisms that are directly integrated into the service-providing components of the system. The architecture is described through its prototype implementation in the Flask microkernelbased operating system, and the policy flexibility of the prototype is evaluated. We present initial evidence that the architecture’s impact on both performance and code complexity is modest. Moreover, our architecture is applicable to many other types of operating systems and environments. 1
The Confused Deputy (or why capabilities might have been invented)
- ACM SIGOPS Operating Systems Review
, 1994
"... This paper appeared in nearly this form in the Oct. 1988 issue of Operating Systems Review, pp 36:38 Bold face stuff should be changed for greater correspondence to Unix. This is a nearly true story (unessential details have been changed). The events happened about 1977 at Tymshare, a company which ..."
Abstract
-
Cited by 36 (0 self)
- Add to MetaCart
This paper appeared in nearly this form in the Oct. 1988 issue of Operating Systems Review, pp 36:38 Bold face stuff should be changed for greater correspondence to Unix. This is a nearly true story (unessential details have been changed). The events happened about 1977 at Tymshare, a company which provided commercial timesharing services. Before this happened I had heard of capabilities and thought that they were neat and tidy, but was not yet convinced that they were necessary. This occasion convinced me that they were necessary. It is an intricate scenario but such is the nature of computers. Our operating system was much like Unix (Ô of AT&T) in its protection structures. A compiler was installed in a directory called SYSX. A user would use the compiler by saying "RUN /SYSX/FORT", and could provide the name of a file to receive some optional debugging output. We had instrumented the compiler to collect statistics about l
Network File Server Design for Continuous Media
, 1992
"... a continuous media file server is presented to demonstrate the effectiveness of design decisions and to illuminate the impact of continuous media storage on computer architecture. To my family Preface I am grateful to my supervisor Professor Roger Needham for the opportunity and encouragement to ..."
Abstract
-
Cited by 14 (0 self)
- Add to MetaCart
a continuous media file server is presented to demonstrate the effectiveness of design decisions and to illuminate the impact of continuous media storage on computer architecture. To my family Preface I am grateful to my supervisor Professor Roger Needham for the opportunity and encouragement to pursue this research. My thanks and appreciation also go to numerous members of the Computer Laboratory. Particular members of the System Research Group deserve special mention including, Joe Dixon, Cosmos Nicolaou, Derek McAuley, Glenford Mapp, Cormac Sreenan, Eoin Hayden, Tim Wilson, Richard Black and Mark Hayter. Their valuable advice and constant stimulation provided an excellent environment in which to develop my understanding. For reading and commenting on earlier drafts of this dissertation, I thank Cormac Sreenan, Richard Black, Simon Crosby, Cosmos Nicolaou, Roger Needham, Tim Wilson, Heather Leitch, Mark Hayter and Derek McAuley. My deepest appreciation i
Recursive Sandboxes: Extending Systrace to Empower Applications
- In Proceeding of the 19 th IFIP International Information Security Conference (SEC
, 2004
"... The systrace system-call interposition mechanism has become a popular method for containing untrusted code through program-specific policies enforced by user-level daemons. We describe our extensions to systrace that allow sandboxed processes to further limit their children processes by issuing dyna ..."
Abstract
-
Cited by 8 (0 self)
- Add to MetaCart
The systrace system-call interposition mechanism has become a popular method for containing untrusted code through program-specific policies enforced by user-level daemons. We describe our extensions to systrace that allow sandboxed processes to further limit their children processes by issuing dynamically constructed policies. We discuss our extensions to the systrace daemon and the OpenBSD kernel, as well as a simple API for constructing simple policies. We present two separate implementations of our scheme, and compare their performance with the base systrace system. We show how our extensions can be used by processes such as ftpd, sendmail, and sshd.
PSOS Revisited
, 2003
"... This paper provides a retrospective view of the design of SRI's Provably Secure Operating System (PSOS), a formally specified tagged-capability hierarchical system architecture. It examines PSOS in the light of what has happened in computer system developments since 1980, and assesses the relevance ..."
Abstract
-
Cited by 7 (2 self)
- Add to MetaCart
This paper provides a retrospective view of the design of SRI's Provably Secure Operating System (PSOS), a formally specified tagged-capability hierarchical system architecture. It examines PSOS in the light of what has happened in computer system developments since 1980, and assesses the relevance of the PSOS concepts in that light.
Capabilities revisited: A holistic approach to bottom-to-top assurance of trustworthy systems
- In Fourth Layered Assurance Workshop
, 2010
"... Abstract: Long active in computer security, our two laboratories have jointly begun a new total-system effort to develop a hierarchically layered high-assurance strongly typed capability-based system. While capabilities have long been proposed as a mechanism for mapping language structure and securi ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
Abstract: Long active in computer security, our two laboratories have jointly begun a new total-system effort to develop a hierarchically layered high-assurance strongly typed capability-based system. While capabilities have long been proposed as a mechanism for mapping language structure and security policy into the hardware protection mechanism, they have seen relatively little use in general-purpose computing. A confluence of events has created the opportunity for new research, and perhaps technology transfer: soft core FPGAs, increased risk of attack even in consumer environments, and a renewed interest in revising the hardware-software interface. Capability Hardware Enhanced RISC Instructions (CHERI) will blend traditional RISC CPU instructions with new capability facilities, offering the promise of hybrid software designs easing incremental adoption. This paper represents an early-stage description of the approach and goals.
Key Management for Content Access Control in a Hierarchy
"... Abstract—The need for content access control in hierarchies (CACH) appears naturally in all contexts where a set of users have different access rights to a set of resources. The hierarchy is defined using the access rights. The different resources are encrypted using different keys. Key management i ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Abstract—The need for content access control in hierarchies (CACH) appears naturally in all contexts where a set of users have different access rights to a set of resources. The hierarchy is defined using the access rights. The different resources are encrypted using different keys. Key management is a critical issue for scalable content access control. In this paper, we study the problem of key management for CACH. We present main existing access control models, and show why these models are not suitable to the CACH applications, and why they are not implemented in the existing key management schemes. Furthermore, we classify these key management schemes into two approaches, and construct an access control model for each approach. The proposed access control models are then used to describe the schemes in a uniform and coherent way. A final contribution of our work consists of a classification of the CACH applications, a comparison of the key management schemes, and a study of the suitability of the existing schemes to the CACH applications with respect to some analytical measurements. Index Terms—content access control, confidentiality, group communication, key management, hierarchy. I.
The Confused Deputy (or why capabilities might have been invented) Norm Hardy Senior
"... This is a nearly true story (inessential details have been changed). The events happened about eleven years ago at Tymshare, a company which provided commercial timesharing services. Be-fore this happened I had heard of capabilities and thought that they Were neat and tidy, but was not yet convinced ..."
Abstract
- Add to MetaCart
This is a nearly true story (inessential details have been changed). The events happened about eleven years ago at Tymshare, a company which provided commercial timesharing services. Be-fore this happened I had heard of capabilities and thought that they Were neat and tidy, but was not yet convinced that they were necessary. This occasion convinced me that they were necessary. Our operating system was much like Unix (aM of AT&T) in its protection structures. A compiler was installed in a directory called SYSX. A user would use the compiler by saying "RUN (SYSX)FORT", and could provide the name of a file to receive some optional debugging output. We had instrumented the compiler to collect statistics about language feature usage. The statistics file was called (SYSX)STAT, a name which was assembled into the compiler. To enable the compiler to write the (SYSX)STAT file, we marked the file holding the compiler { (9YSX)FORT} with homefiles license. The operating system allowed a program with such license to write files in its home directory, SYSX in our case. The billing information file (SYSX)BILL was also stored in SYSX. Some user came to know the name (9YSX)BILL and supplied it to the compiler as the name of the file to receive the debugging information. The compiler passed the name to the operating system in a request to open that file for

