Demo Data from VLDB 2026 / reviewers in the wild / expert
Ray Spencer
dblp:121/2666
· DBLP profile ↗
2ranked-venue papers
1as first author
0since 2021 · last 1999
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Security and privacy · 2 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Network and information security
1 paper |
Systems and software security · 100% | |
| Software engineering, system software, and programming languages
1 paper |
Requirements engineering and software design · 100% |
Topics — the 2 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Systems and software security
operating system security |
0.0 | 1 | 1999 | The Flask Security Architecture: System Support for Diverse Security Policies · USENIX Security Symposium 1999 |
Requirements engineering and software design › software architecture › architectural design
security architecture |
0.0 | 1 | 1999 | The Flask Security Architecture: System Support for Diverse Security Policies · USENIX Security Symposium 1999 |
Methods — techniques the papers use, named apart from their topics
policy enforcement · 0.0access control · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1999 | The Flask Security Architecture: System Support for Diverse Security Policies
Ray Spencer, Stephen Smalley, Peter A. Loscocco, Mike Hibler, David G. Andersen, Jay Lepreau |
USENIX Security Symposium | 1 |
| 1996 | Developing and using a "policy neutral" access control policyabstractThe foundation for security enforcement is access control.Resources must be protected against access by unauthorized entities.Furthermore, authorized entities must be prevented from accessing resources in inappropriate ways.A major challenge to the developer of an access control policy is to provide users the flexibility to protect their resources as they see fit; system policies that am inconsistent with user needs are inadequate.In particular, systems that enforce a single, hard-coded policy cannot satisfy the needs of all users.As part of the Distributed Trusted Operating System (DTOS) program, we have developed and implemented a flexible security architecture using the Mach microkemel.In this architecture, the security rules enforced by the system are defined by a system component outside the microkemel.This reduces the problem of sup porting other security policies to redefining this system component; the same microkemel can be used to support a wide range of policies.Formal methods were used to provide a rigorous approach for the development of the policy.Recognizing that most people are uninterested in reading security requirements stated in formal specification languages, an approach was developed for representing and maintaining the policy in a tabular format.This paper describes the flexibility of the DTOS security architecture and the approach used in developing the access control policy for this flexible architecture.It also gives examples of how to detine a component that makes security decisions for the microkernel.''This work was suppxted in patt by the Maryland F'mcurement Office, contract MDA904-93C-4209 and was performed in cooperation with mscarchers at the Information Security Computer Science Rcseaxh Division of the Department of Jkfense. Duane E. Olawsky, Todd Fine, Edward A. Schneider, Ray Spencer |
NSPW | 4 |