Design and Implementation of Secure Xenix

Gligor, Virgil D.; Chandersekaran, Coimbatore; Chapman, Robert S.; Dotterer, L.J.; Hetch, M.S.; Jiang, Wen-Der; Johri, A.; Luckenbaugh, G.L.; Vasudevan, N.

doi:10.1109/tse.1987.232893

Cited by 34 publications

(10 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…48 One such product was Trusted Xenix, a multilevel secure access control system for the Unix-variant Xenix that was based on the Bell-LaPadula security model. 49 SRI's Advisor Project was a research and development effort to provide TIS with a modified version of NIDES to most effectively enhance intrusion detection efforts with Trusted Xenix. SRI was TIS's subcontractor on TIS's contract with Rome Laboratory.…”

Section: Next Generation Intrusion Detection Expert Systemmentioning

confidence: 99%

The March of IDES: Early History of Intrusion-Detection Expert Systems

Yost¹

2016

IEEE Annals Hist. Comput.

View full text Add to dashboard Cite

This paper examines the pre-history and history of early intrusion detection expert systems by focusing the first such system, Intrusion Detection Expert System, or IDES, which was developed in the second half of the 1980s at SRI International (and SRI's follow-on Next Generation Intrusion Detection Expert System, or NIDES, in the early-to-mid 1990s). It also briefly recounts other early intrusion detection systems, the National Security Agency's Computer Misuse and Anomaly Detection (CMAD) Program, and analyzes the disproportionately high contributions of women scientists to leadership in intrusion detection system research and development relative to other computer security specialties.Intrusion detection systems are software-based systems that monitor computer user behavior audit data (and other computer system events) in order to detect and flag potential unauthorized access to and inappropriate use of a computer system. These detection systems can be used to help identify potential external perpetrators, internal misusers (who exceed or abuse privileges), and masquerading programs (Trojan horses). Perpetrators might be seeking to access or manipulate data (for criminal or non-criminal purposes), introducing malware (including but not limited to viruses, worms, and Trojan horses), or researching a system for a future attack.Intrusion detection systems (IDS) can operate either in batch mode (analyzing volumes of collected computer user behavior data and system events) or in real-time (analyzing users' behavior as they are actively on a computer system). Some intrusion detection systems include an expert system component-a rule-based, adaptive learning capability. This paper focuses on the pre-history and history of the most prominent and influential early intrusion detection expert system, which was developed at SRI International in the 1980s and generically took the name that quickly came to define its type-Intrusion Detection Expert System, or IDES. In exploring this history, the paper situates intrusion detection within the broader field of computer security and surveys the evolution of IDES into SRI's Next-Generation Intrusion Detection Expert System (NIDES) in the early 1990s. It also briefly examines the emergence of other prominent intrusion detection systems, the intrusion detection system research program at the National Security Agency (NSA), and the outsized contribution of women scientists to leadership in this field. In a short span of time-the early 1980s to the mid-1990s-intrusion detection

show abstract

Section: Next Generation Intrusion Detection Expert Systemmentioning

confidence: 99%

The March of IDES: Early History of Intrusion-Detection Expert Systems

Yost¹

2016

IEEE Annals Hist. Comput.

View full text Add to dashboard Cite

show abstract

“…Previous research efforts [13,23,25,29,46,47], as well as hardened Linux configurations, such as SELinux and AppArmor, have only considered least privilege on these utilities from the perspective of the administrator, not the untrusted user. In the case of mount utilities, systems like AppArmor attempt to limit the effects of a compromised mount to arbitrarily changing the file system tree.…”

Section: 5%mentioning

confidence: 99%

“…Secure Xenix [23,25], and other secure Unix variants [13,29,46,47] developed modern best practices for enforcing least privilege on the administrator: fragmenting administrative privilege into roles or capabilities, restricting the ability to create more setuid binaries, and removing the setuid bit if a binary is overwritten. Limiting the risk of exploiting a setuid binary is complimentary to Protego's goal of eliminating the need for setuid binaries.…”

Section: Related Workmentioning

confidence: 99%

Practical techniques to obviate setuid-to-root binaries

Jain

Tsai

John

et al. 2014

Proceedings of the Ninth European Conference on Computer Systems

View full text Add to dashboard Cite

Trusted, setuid-to-root binaries have been a substantial, long-lived source of privilege escalation vulnerabilities on Unix systems. Prior work on limiting privilege escalation has only considered privilege from the perspective of the administrator, neglecting the perspective of regular users-the primary reason for having setuid-to-root binaries.The paper presents a study of the current state of setuidto-root binaries on Linux, focusing on the 28 most commonly deployed setuid binaries in the Debian and Ubuntu distributions. This study reveals several points where Linux kernel policies and abstractions are a poor fit for the policies desired by the administrator, and root privilege is used to create point solutions. The majority of these point solutions address 8 system calls that require administrator privilege, but also export functionality required by unprivileged users. This paper demonstrates how least privilege can be achieved on modern systems for non-administrator users. We identify the policies currently encoded in setuid-to-root binaries, and present a framework for expressing and enforcing these policy categories in the kernel. Our prototype, called Protego, deprivileges over 10,000 lines of code by changing only 715 lines of Linux kernel code. Protego also adds additional utilities to keep the kernel policy synchronized with legacy, policy-relevant configuration files, such as /etc/sudoers. Although some previously-privileged binaries may require changes, Protego provides users with the same functionality as Linux and introduces acceptable performance overheads. For instance, a Linux kernel compile incurs less than 2% overhead on Protego.

show abstract

“…Secure Xenix Somewhat later than the work above, IBM retrofitted Microsoft's Xenix with access control and auditing features [111].This work was influenced the UNIX retrofit of Kramer [173], but aimed to provide a comprehensive and effective implementation of Multics security features [280] (see Chapter 3) in Xenix. Two key issues among several addressed by the Secure Xenix work were compatibility and trusted path.…”

Section: Kvm/370mentioning

confidence: 99%

Operating System Security

Jaeger

2008

Synthesis Lectures on Information Security, Privacy, and Trust

View full text Add to dashboard Cite

Operating systems provide the fundamental mechanisms for securing computer processing. Since the 1960s, operating systems designers have explored how to build "secure" operating systemsoperating systems whose mechanisms protect the system against a motivated adversary. Recently, the importance of ensuring such security has become a mainstream issue for all operating systems. In this book, we examine past research that outlines the requirements for a secure operating system and research that implements example systems that aim for such requirements. For system designs that aimed to satisfy these requirements, we see that the complexity of software systems often results in implementation challenges that we are still exploring to this day. However, if a system design does not aim for achieving the secure operating system requirements, then its security features fail to protect the system in a myriad of ways. We also study systems that have been retrofit with secure operating system features after an initial deployment. In all cases, the conflict between function on one hand and security on the other leads to difficult choices and the potential for unwise compromises. From this book, we hope that systems designers and implementors will learn the requirements for operating systems that effectively enforce security and will better understand how to manage the balance between function and security.

show abstract

Design and Implementation of Secure Xenix

Cited by 34 publications

References 7 publications

The March of IDES: Early History of Intrusion-Detection Expert Systems

The March of IDES: Early History of Intrusion-Detection Expert Systems

Practical techniques to obviate setuid-to-root binaries

Operating System Security

Contact Info

Product

Resources

About