A Decade of OS Access-Control Extensibility

Total Page:16

File Type:pdf, Size:1020Kb

A Decade of OS Access-Control Extensibility practice DOI:10.1145/2408776.2408792 movement from multiuser computing Article development led by queue.acm.org toward single-user devices with com- plex application models. The transition was facilitated by extensible access-con- Open source security foundations trol frameworks, which allow operating- for mobile and embedded devices. system kernels to be more easily adapt- ed to new security requirements. BY ROBErt N.M. WAtsON One such extensible kernel refer- ence-monitor framework is the Trust- edBSD MAC (Mandatory Access Con- trol) Framework, developed beginning in 2000 and shipped in the open source A Decade of OS FreeBSD operating system in 2003. This article first describes the context and challenges for access-control ex- tensibility and high-level framework Access-Control design, then turns to practical expe- rience deploying security policies in several framework-based products, in- cluding FreeBSD, nCircle appliances, Juniper’s Junos, and Apple’s OS X and Extensibility iOS. While extensibility was key to each of these projects, they motivated con- siderable changes to the framework it- self, so the article also explores how the framework did (and did not) meet each product’s requirements, and finally re- flects on the continuing evolution of operating-system security. A Quiet Revolution in OS Design Embedded and mobile operating sys- TO DISCUSS OPERATING-SYSTEM security is to marvel tems have changed greatly in the past 20 years: devices have gained the CPU at the diversity of deployed access-control models: power to run general-purpose operat- Unix and Windows NT multiuser security, Type ing systems; they have been placed in Enforcement in SELinux, anti-malware products, app ubiquitous networking environments; they have needed to support mature sandboxing in Apple OS X, Apple iOS, and Google software stacks including third-party Android, and application-facing systems such as applications; and they have found Capsicum in FreeBSD. This diversity is the result of a themselves exposed to malicious ac- tivity motivated by strong financial stunning transition from the narrow 1990s Unix and incentives. Vendors built on exist- NT status quo to security localization—the adaptation ing operating systems—often open source—to avoid creating them from of operating-system security models to site-local or scratch. This provided mature applica- product-specific requirements. tion frameworks and complex network This transition was motivated by three changes: stacks, both areas of weakness for then-contemporary “embedded oper- the advent of ubiquitous Internet connectivity; a ating systems.” One early example is migration from dedicated embedded operating Juniper’s Junos, a version of FreeBSD adapted for router control planes in systems to general-purpose ones in search of more 1998. This trend had come to fruition sophisticated software stacks; and widespread by 2007 when Google’s Android, based 52 COMMUNICATIONS OF THE ACM | FEBRUARY 2013 | VOL. 56 | NO. 2 on Linux, and Apple’s iOS, based in that were designed for another place capsulation, appearing in Abrams et part on Mach and FreeBSD, became and time. al.’s Generalized Framework for Ac- available, transforming the smart- Access-Control Frameworks. Oper- cess Control (GFAC),1 and by the late phone market. ating-system developers must satisfy 1990s in Ott’s Rule Set-based Access Common to all of these environ- device vendors, who require everything Control (RSBAC)14 and Spencer et al.’s ments is a focus on security and reli- from router and firewall hardening Flask security architecture.17 Main- ability: as third-party applications are to mobile-phone app sandboxing. stream operating-system vendors did deployed in systems from Junos, via its Operating-system vendors had accu- not adopt these approaches until the SDK, and to iOS/Android app stores, rately observed a difficult adoption early 2000s with the MAC Framework sandboxing becomes critical, first to path for historic trusted operating sys- on FreeBSD22 and shortly after, Linux prevent bricking (reducing a device to tems, whose mandatory access-control Security Modules (LSM).23 In both cas- a mere brick as a result of malfunction schemes suffered from poor usability, es, a key concern was supporting third- or abuse) and later to constrain mal- performance, maintainability, and— party security models without com- ware. This trend is reinforced by mo- perhaps most critically—end-user de- mitting to fixed policies as had earlier bile-phone access to online purchas- mand. Likewise, they saw many prom- trusted systems. ing, and most recently, banking and ising new security models in research, payment systems. As a result, the role each with unknown viability, suggest- The MAC Framework SSOCIATES A of operating-system security has shift- ing that no single access-control mod- The MAC Framework was proposed ORYS ORYS B ed from protecting multiple users from el would meet all needs. This practical in 1999, with the first whitepaper on each other toward protecting a single reality of security localization directly its design published in June 2000.20 It NDRIJ A / operator or user from untrustworthy motivates extensible access control. appeared in FreeBSD 5.0 in 2003 as an applications. In 2013, embedded de- Research over the preceding 20 experimental feature—compiled out REENBERG G vices, mobile phones, and tablets are years had made clear the need for a ref- by default but available to early adopt- RIAN points of confluence: the interests of erence monitor—a self-contained, non- ers. FreeBSD 8.0 in 2009 included the B many different parties—consumers, bypassable, and compact (hence verifi- framework as a production feature, phone vendors, application authors, able) centralization of access control.2 compiled into the default kernel. (A and online services—must be medi- By the early 1990s, this concept had timeline of key events in its develop- LLUSTRATION BY BY LLUSTRATION I ated with the help of operating systems been combined with the notion of en- ment appears in Figure 1.) FEBRUARY 2013 | VOL. 56 | NO. 2 | COMMUNICATIONS OF THE ACM 53 practice The MAC Framework offers a logi- compiled into the kernel or loadable range of object types, from files to net- cal solution to the problem of kernel modules and implement well-defined work interfaces, and integrate with the access-control augmentation: exten- kernel programming interfaces (KPIs). kernel’s concurrency model. sion infrastructure able to represent Policies can augment access-control Mandatory Policies. MAC describes many different policies, offering im- decisions and make use of common a class of security models in which proved maintainability and supported infrastructure such as object labeling policies constrain the interactions by the operating-system vendor. Simi- to avoid direct kernel modification of all system users. Whereas discre- lar to device drivers and virtual file and code duplication. They are able to tionary access control (DAC) schemes system (VFS) modules,10 policies are enforce access control across a broad such as file-system access-control lists Figure 1. MAC Framework research and development with key corporate contributions. June 2000: extensible access control October 2007, August 2008: MAC framework for FreeBSD proposed at Framework improvements merged Network Associates Laboratories to FreeBSD from Apple OS X 2001–2004 DARPA CBOSS project 2004–2007 US Navy SEFOS project at 2009: MAC Framework DTrace on access control extensibility at McAfee Research improves the MAC instrumentation added by University of McAfee Reasearch Framework; SEBSD; Apple OS X port Cambridge during dynamic analysis study 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 July 2002: MAC Framework merged to November 2006: nCircle contributes OS 2008: Seccuris contributes MAC FreeBSD 5.0 development tree privilege extensions to MAC Framework Framework IPC enhancements while developing Biba-based network intrusion detection appliance 2007: Secure Computing Corporation (later McAfee) contributes MAC Framework patches from FreeBSD transition; Sidewinder is evaluated to EAL 4+ Figure 2. Policy models are encapsulated in kernel modules that augment kernel access control. Process Process Process Process Label management APIs System call interface support security-aware but Kernel subsystems policy-agnostic applications consult framework to check access control decisions and notify the framework MAC label of object lifecycle events Process Socket VFS system DTrace to support labeling signals IPC calls DTrace probes allow monitoring and tracing of framework entry point MAC Framework invocation and results Operating Policy modules can be com- system Biba MLS piled into the kernel, loaded kernel at boot, or (where supported ugidfw by policy semantics) loaded and uploaded at runtime. 54 COMMUNICATIONS OF THE ACM | FEBRUARY 2013 | VOL. 56 | NO. 2 practice (ACLs) allow object owners to protect code conflicts with security exten- (or share) objects at their own discre- sions. Assurance is also affected, as tion, MAC enforces systemwide se- the burden of arguing for correctness curity invariants regardless of user is left entirely in the hands of the ex- preference. The research literature de- tension writer. scribes a plethora of mandatory poli- The MAC ˲ System call interposition is widely cies grounded in information flow and Framework used in antivirus systems and, in the rule-based models. past, security extension products and Early mandatory policies focused
Recommended publications
  • The Title Title: Subtitle March 2007
    sub title The Title Title: Subtitle March 2007 Copyright c 2006-2007 BSD Certification Group, Inc. Permission to use, copy, modify, and distribute this documentation for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE DOCUMENTATION IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS DOCUMENTATION INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CON- SEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEG- LIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS DOCUMENTATION. NetBSD and pkgsrc are registered trademarks of the NetBSD Foundation, Inc. FreeBSD is a registered trademark of the FreeBSD Foundation. Contents Introduction vii 1 Installing and Upgrading the OS and Software 1 1.1 Recognize the installation program used by each operating system . 2 1.2 Recognize which commands are available for upgrading the operating system 6 1.3 Understand the difference between a pre-compiled binary and compiling from source . 8 1.4 Understand when it is preferable to install a pre-compiled binary and how to doso ...................................... 9 1.5 Recognize the available methods for compiling a customized binary . 10 1.6 Determine what software is installed on a system . 11 1.7 Determine which software requires upgrading . 12 1.8 Upgrade installed software . 12 1.9 Determine which software have outstanding security advisories .
    [Show full text]
  • Role Based Access Control on MLS Systems Without Kernel Changes
    Role Based Access Control on For example, roles in a bank may include the role of teller or accountant. Each of these roles has a set of MLS Systems without Kernel privileges or transactions that they can p erform, includ- Changes ing some privileges that are available to b oth roles. Roles can b e hierarchical. For example, some roles in a hospital D. Richard Kuhn may b e health care provider, nurse, and do ctor. The do c- National Institute of Standards and Technology tor role may include all privileges available to the nurse Gaithersburg, Maryland 20899 role, which in turn includes all the privileges available to the health care provider role. Roles have b een used in a variety of forms for com- Abstract puter system security for at least 20 years, and several prop osals for incorp orating roles into existing access con- Role based access control (RBAC) is attracting increas- trol mechanisms have b een published [2], [3], [4]. More ing attention as a security mechanism for b oth commer- recently, formal defnitions for general-purp ose RBAC no- cial and many military systems. This pap er shows how tions have b een prop osed [5], [6], [7]. RBAC can b e implemented using the mechanisms avail- This pap er shows how RBAC can b e implemented able on traditional multi-level security systems that im- using the controls available on traditional lattice-based plement information fow p olicies. The construction from multi-level secure systems. This approach presents a MLS to RBAC systems is signifcant b ecause it shows that number of advantages: the enormous investment in MLS systems can b e lever- aged to pro duce RBAC systems.
    [Show full text]
  • Examining the Viability of MINIX 3 As a Consumer Operating
    Examining the Viability of MINIX 3 as a Consumer Operating System Joshua C. Loew March 17, 2016 Abstract The developers of the MINIX 3 operating system (OS) believe that a computer should work like a television set. You should be able to purchase one, turn it on, and have it work flawlessly for the next ten years [6]. MINIX 3 is a free and open-source microkernel-based operating system. MINIX 3 is still in development, but it is capable of running on x86 and ARM processor architectures. Such processors can be found in computers such as embedded systems, mobile phones, and laptop computers. As a light and simple operating system, MINIX 3 could take the place of the software that many people use every day. As of now, MINIX 3 is not particularly useful to a non-computer scientist. Most interactions with MINIX 3 are done through a command-line interface or an obsolete window manager. Moreover, its tools require some low-level experience with UNIX-like systems to use. This project will examine the viability of MINIX 3 from a performance standpoint to determine whether or not it is relevant to a non-computer scientist. Furthermore, this project attempts to measure how a microkernel-based operating system performs against a traditional monolithic kernel-based OS. 1 Contents 1 Introduction 5 2 Background and Related Work 6 3 Part I: The Frame Buffer Driver 7 3.1 Outline of Approach . 8 3.2 Hardware and Drivers . 8 3.3 Challenges and Strategy . 9 3.4 Evaluation . 10 4 Progress 10 4.1 Compilation and Installation .
    [Show full text]
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • File Permissions Do Not Restrict Root
    Filesystem Security 1 General Principles • Files and folders are managed • A file handle provides an by the operating system opaque identifier for a • Applications, including shells, file/folder access files through an API • File operations • Access control entry (ACE) – Open file: returns file handle – Allow/deny a certain type of – Read/write/execute file access to a file/folder by – Close file: invalidates file user/group handle • Access control list (ACL) • Hierarchical file organization – Collection of ACEs for a – Tree (Windows) file/folder – DAG (Linux) 2 Discretionary Access Control (DAC) • Users can protect what they own – The owner may grant access to others – The owner may define the type of access (read/write/execute) given to others • DAC is the standard model used in operating systems • Mandatory Access Control (MAC) – Alternative model not covered in this lecture – Multiple levels of security for users and documents – Read down and write up principles 3 Closed vs. Open Policy Closed policy Open Policy – Also called “default secure” • Deny Tom read access to “foo” • Give Tom read access to “foo” • Deny Bob r/w access to “bar” • Give Bob r/w access to “bar • Tom: I would like to read “foo” • Tom: I would like to read “foo” – Access denied – Access allowed • Tom: I would like to read “bar” • Tom: I would like to read “bar” – Access allowed – Access denied 4 Closed Policy with Negative Authorizations and Deny Priority • Give Tom r/w access to “bar” • Deny Tom write access to “bar” • Tom: I would like to read “bar” – Access
    [Show full text]
  • Access Control and Operating System
    Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store
    [Show full text]
  • Moving Your Itunes Library!Peter Degroot 2/19/11 Moving Your Itunes Library (And Backing It up - Covered at the End)
    Moving your iTunes Library!Peter DeGroot 2/19/11 Moving your iTunes Library (and backing it up - covered at the end) One way to free up space on your computer's internal hard drive is to move iTunes to an external disk, but moving iTunes is not as simple as moving iPhoto or other kinds of data. The first thing you need to know is where the iTunes Library is located. It is in Home/Music/iTunes Now here is tricky part #1. The actual music is in the folder iTunes Music, which is sometimes confusingly referred to as the iTunes Library. It's confusing because there is another file actually named "iTunes Library", but it doesn't contain any music, video, or other content. Is really just a database file that helps manage the contents of iTunes. The only item you want to move to another location such as an external disk, is the iTunes Music Folder. That's just fine, because this is the folder that takes up 98% of the space that iTunes requires on your computer. iTunes expects to find all of the other files and folders in the iTunes folder in Home/Music. In fact, if you move them or move the whole iTunes folder off the startup disk, iTunes will not find it and will create new copies that don't link to any data. It will look like you lost all of your iTunes music, podcasts, etc. Bottom Line: only move the iTunes Music folder. But don't move it yet. P. 1 of 8 Moving your iTunes Library!Peter DeGroot 2/19/11 Tricky part #2.
    [Show full text]
  • Making Linux Security Frameworks Available to Containers
    Security Namespace : Making Linux Security Frameworks Available to Containers Yuqiong Sun, David Safford, Mimi Zohar, Dimitrios Pendarakis, Zhongshu Gu and Trent Jaeger Container vs. Virtual Machines • Containers are operating system level virtualization environment for running multiple isolated Linux systems on a single Linux control host Image credit: Docker Inc. and RightScale Inc. Is Kernel Sharing All Good? • Container owners cannot leverage kernel security frameworks to protect their containers • I.e., cannot apply local security policies to govern integrity measurement, code execution, mandatory access control, etc. Integrity Attestation for Container • On a container cloud, can a container owner attest integrity of his/her containers to his/her customers? • Exactly what Linux Integrity subsystem (a.k.a. IMA) is designed for kernel mmap() extend Process Measure record Policy Measurements Integrity Attestation for Container (Cont.) • But… • Mixed measurements from different containers and host Process mmap() kernel extend Container1 Measure mmap() record Process Policy Measurements Container2 Integrity Attestation for Container (Cont.) • But… • Mixed measurements from different containers and host • Different versions of policies Process mmap() kernel extend Container1 Measure mmap() record Process Policy1 Policy2 Measurements Container2 Integrity Attestation for Container (Cont.) • But… • Mixed measurements from different containers and host • Different versions of policies • And policies do not always agree with each other Me:
    [Show full text]
  • Operating System Structure
    Operating System Structure Joey Echeverria [email protected] modified by: Matthew Brewer [email protected] Nov 15, 2006 Carnegie Mellon University: 15-410 Fall 2006 Overview • Motivations • Kernel Structures – Monolithic Kernels ∗ Kernel Extensions – Open Systems – Microkernels – Exokernels – More Microkernels • Final Thoughts Carnegie Mellon University: 15-410 Fall 2006 1 Motivations • Operating systems have a hard job. • Operating systems are: – Hardware Multiplexers – Abstraction layers – Protection boundaries – Complicated Carnegie Mellon University: 15-410 Fall 2006 2 Motivations • Hardware Multiplexer – Each process sees a “computer” as if it were alone – Requires allocation and multiplexing of: ∗ Memory ∗ Disk ∗ CPU ∗ IO in general (network, graphics, keyboard etc.) • If OS is multiplexing it must also allocate – Priorities, Classes? - HARD problems!!! Carnegie Mellon University: 15-410 Fall 2006 3 Motivations • Abstraction Layer – Presents “simple”, “uniform” interface to hardware – Applications see a well defined interface (system calls) ∗ Block Device (hard drive, flash card, network mount, USB drive) ∗ CD drive (SCSI, IDE) ∗ tty (teletype, serial terminal, virtual terminal) ∗ filesystem (ext2-4, reiserfs, UFS, FFS, NFS, AFS, JFFS2, CRAMFS) ∗ network stack (TCP/IP abstraction) Carnegie Mellon University: 15-410 Fall 2006 4 Motivations • Protection Boundaries – Protect processes from each other – Protect crucial services (like the kernel) from process – Note: Everyone trusts the kernel • Complicated – See Project 3 :) – Full
    [Show full text]
  • Based On: 2004 Deitel & Associates, Inc
    Based on: 2004 Deitel & Associates, Inc. Operating Systems Computer Science Department Prepared By Dr. Suleyman Al-Showarah 1.9 2000 and Beyond Middleware is computer software that provides services to software applications beyond those available from the operating system. Middleware Links two separate applications Often over a network and between incompatible machines – Particularly important for Web services Simplifies communication across multiple architectures Middleware : Software that acts as a bridge between an operating system or database and applications, especially on a network. 1.9 2000 and Beyond A Web service is a method of communication between two electronic devices over a network. Web services Encompass set of related standards Ready-to-use pieces of software on the Internet Enable any two applications to communicate and exchange data 1.10 Application Bases Application base Combination of hardware and operating system used to develop Applications Developers and users unwilling to abandon established application base Increased financial cost and time spent relearning What does Application Base mean? The application base is the directory, which contains all the files related to a .NET application, including the executable file (.exe) that loads into the initial or default application domain. 1.11 Operating System Environments Operating systems intended for high-end environments Special design requirements and hardware support needs Large main memory Special-purpose hardware Large numbers of processes Continue ... Embedded systems Characterized by small set of specialized resources Provide functionality to devices such as cell phones and PDAs (see next slide) Efficient resource management key to building successful operating system PDAs A personal digital assistant (PDA), also known as a handheld PC, or personal data assistant, is a mobile device that functions as a personal information manager.
    [Show full text]
  • OS X Mavericks
    OS X Mavericks Core Technologies Overview October 2013 Core Technologies Overview 2 OS X Mavericks Contents Page 4 Introduction Page 5 System Startup BootROM EFI Kernel Drivers Initialization Address Space Layout Randomization (ASLR) Compressed Memory Power Efficiency App Nap Timer Coalescing Page 10 Disk Layout Partition Scheme Core Storage File Systems Page 12 Process Control Launchd Loginwindow Grand Central Dispatch Sandboxing GateKeeper XPC Page 19 Network Access Ethernet Wi-Fi Multihoming IPv6 IP over Thunderbolt Network File Systems Access Control Lists Directory Services Remote Access Bonjour Page 25 Document Lifecycle Auto Save Automatic Versions Document Management Version Management iCloud Storage Core Technologies Overview 3 OS X Mavericks Page 28 Data Management Spotlight Time Machine Page 30 Developer Tools Xcode LLVM Instruments Accelerate Automation WebKit Page 36 For More Information Core Technologies Overview 4 OS X Mavericks Introduction With more than 72 million users—consumers, scientists, animators, developers, and system administrators—OS X is the most widely used UNIX® desktop operating system. In addition, OS X is the only UNIX environment that natively runs Microsoft Office, Adobe Photoshop, and thousands of other consumer applications—all side by side with traditional command-line UNIX applications. Tight integration with hardware— from the sleek MacBook Air to the powerful Mac Pro—makes OS X the platform of choice for an emerging generation of power users. This document explores the powerful industry standards and breakthrough innovations in the core technologies that power Apple’s industry-leading user experiences. We walk you through the entire software stack, from firmware and kernel to iCloud and devel- oper tools, to help you understand the many things OS X does for you every time you use your Mac.
    [Show full text]
  • Recent Security Enhancements in Netbsd
    Recent Security Enhancements in NetBSD Elad Efrat < [email protected] > September 2006 Abstract Over the years, NetBSD obtained the position of the BSD focusing on portability. While it is true that NetBSD offers an easily portable operating system, care is also given to other areas, such as security. This paper presents the NetBSD philosophy of security, design decisions, and currently offered security features. Finally, some of the current and future research will be revealed. 1. Introduction Running on almost twenty different architectures, and easily portable to others, NetBSD gained its reputation as the most portable operating system on the planet. While that may indicate high quality code, the ever demanding networked world cares about more than just that. Over the past year, NetBSD evolved quite a bit in various areas; this paper, however, will focus on the aspect relating to security. This paper was written and structured to present a full overview of the recent security enhancements in NetBSD in an easily readable and balanced form that will satisfy new, intermediate, and experienced users. References were sprinkled across the text to provide more information to those who want the gory details, while preserving the continuity. Section 2 will present the bigger picture of security in NetBSD: how NetBSD perceives security, the design decisions of NetBSD software in general and the security infrastructure and features more specifically. Section 3 will present a detailed overview of the recent enhancements in the security infrastructure and features of NetBSD including, where relevant, details about the design, implementation, and possible future development. Section 4 will present current security-related research and development in NetBSD, and section 5 will discuss how the described enhancements work together to provide a more secure platform.
    [Show full text]