oreilly - selinux open source security enhanced linux - 2004

Overview of the SELinux Security Model Section 2.1.. The SELinux Role-Based Access Control Model Section 6.2.. In a nutshell, SELinux promises to change the way Linux users practicecom

Organization of This Book

Conventions Used in This Book

Using Code Examples

How to Contact Us

Acknowledgments

Chapter 1 Introducing SELinux

Section 1.1 Software Threats and the Internet

Section 1.2 SELinux Features

Section 1.3 Applications of SELinux

Section 1.4 SELinux History

Section 1.5 Web and FTP Sites

Chapter 2 Overview of the SELinux Security Model

Section 2.1 Subjects and Objects

Section 2.2 Security Contexts

Section 2.3 Transient and Persistent Objects

Section 2.4 Access Decisions

Section 2.5 Transition Decisions

Section 2.6 SELinux Architecture

Chapter 3 Installing and Initially Configuring SELinux

Section 3.1 SELinux Versions

Section 3.2 Installing SELinux

Section 3.3 Linux Distributions Supporting SELinux

Section 3.4 Installation Overview

Section 3.5 Installing SELinux from Binary or Source Packages

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Section 3.6 Installing from Source

Chapter 4 Using and Administering SELinux

Section 4.1 System Modes and SELinux Tuning

Section 4.2 Controlling SELinux

Section 4.3 Routine SELinux System Use and Administration

Section 4.4 Monitoring SELinux

Section 4.5 Troubleshooting SELinux

Chapter 5 SELinux Policy and Policy Language Overview

Section 5.1 The SELinux Policy

Section 5.2 Two Forms of an SELinux Policy

Section 5.3 Anatomy of a Simple SELinux Policy Domain

Section 5.4 SELinux Policy Structure

Chapter 6 Role-Based Access Control

Section 6.1 The SELinux Role-Based Access Control Model

Section 6.2 Railroad Diagrams

Section 6.3 SELinux Policy Syntax

Section 6.4 User Declarations

Section 6.5 Role-Based Access Control Declarations

Chapter 7 Type Enforcement

Section 7.1 The SELinux Type-Enforcement Model

Section 7.2 Review of SELinux Policy Syntax

Section 7.3 Type-Enforcement Declarations

Section 7.4 Examining a Sample Policy

Chapter 8 Ancillary Policy Statements

Section 8.1 Constraint Declarations

Section 8.2 Other Context-Related Declarations

Section 8.3 Flask-Related Declarations

Chapter 9 Customizing SELinux Policies

Section 9.1 The SELinux Policy Source Tree

Section 9.2 On the Topics of Difficulty and Discretion

Section 9.3 Using the SELinux Makefile

Section 9.4 Creating an SELinux User

Section 9.5 Customizing Roles

Section 9.6 Adding Permissions

Section 9.7 Allowing a User Access to an Existing Domain

Section 9.8 Creating a New Domain

Section 9.9 Using Audit2allow

Section 9.10 Policy Management Tools

Section 9.11 The Road Ahead

Appendix A Security Object Classes

Appendix B SELinux Operations

Appendix C SELinux Macros Defined in src/policy/macros

Appendix D SELinux General Types

Appendix E SELinux Type Attributes

Colophon

Index

< Day Day Up >

< Day Day Up >

Copyright © 2005 O'Reilly Media, Inc All rights reserved

Printed in the United States of America

Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472

O'Reilly books may be purchased for educational, business, or sales promotional use Online editionsare also available for most titles (http://safari.oreilly.com) For more information, contact our

corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com

Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks ofO'Reilly Media, Inc The Linux series designations, SELinux: NSA's Open Source Security EnhancedLinux, images of the American West, and related trade dress are trademarks of O'Reilly Media, Inc.Many of the designations used by manufacturers and sellers to distinguish their products are claimed astrademarks Where those designations appear in this book, and O'Reilly Media, Inc was aware of atrademark claim, the designations have been printed in caps or initial caps The use of NSA's SELinux inthis book does not constitute implied or expressed endorsement of the book by National SecurityAgency (NSA) or any of its agents

While every precaution has been taken in the preparation of this book, the publisher and author assume

no responsibility for errors or omissions, or for damages resulting from the use of the information

contained herein

< Day Day Up >

< Day Day Up >

Preface

As a security researcher and author of computer books, I work hard to stay abreast of the latest

technological developments So, I'd been tracking Security Enhanced Linux (SELinux) on my technologyradar for several years But, frankly, it didn't seem to me easy enough, or robust enough, for dependableuse by Linux system administrators

About one year ago, SELinux seemed to grow up suddenly I now believe that SELinux is the mostimportant computing technology for Linux users that I've seen in the last several years Obviously, othersagree that SELinux is important and useful: SELinux has been incorporated into Fedora Core, Gentoo,and SUSE Linux And by the time this book is in print, it's expected to be part of Red Hat EnterpriseLinux

Why the sudden popularity? In a nutshell, SELinux promises to change the way Linux users practicecomputer security from a reactive posture, based on applying patches intended to close publishedvulnerabilities, to a proactive posture that seeks to prevent even unpublished vulnerabilities from

compromising systems Properly configured and administered Linux systems already hold a

well-deserved reputation for resistance to attack SELinux significantly ups the ante on attackers andintruders by providing Linux system administrators with access to sophisticated security technology of asort previously available only to administrators of high-security systems running expensive, military-gradeoperating systems

Of course, as a good friend of mine—who happens to be an economist—is fond of saying, "There's nosuch thing as a free lunch." Like other security technologies, SELinux must be properly installed,

configured, and maintained if it is to be effective This book will help you understand and intelligently useSELinux Whether you prefer to use the sample SELinux security policies delivered as part of a Linuxdistribution or to implement your own customized policies, this book will show you the way

One thing SELinux: NSA's Open Source Security Enhanced Linux doesn't do is explain how to writeprograms that use the SELinux API I anticipate that this book will be useful to those who want to writesuch programs But SELinux is designed for system administrators, not programmers, and thereforedoesn't assume programming skills or expertise Consequently, those interested in using the SELinuxAPI will have to supplement the material presented in this book with information obtained from SELinuxdocumentation and other sources

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Organization of This Book

This book is divided into nine chapters and five appendixes Here is a brief summary of each chapter'sfocus:

Chapter 1, Introducing SELinux, explains why SELinux is valuable and which common security flaws itaddresses, including the concept of the 0-day vulnerability

Chapter 2, Overview of the SELinux Security Model, explains such basic concepts as roles, domains,and transitions It prepares the reader for SELinux installation

Chapter 3, Installing and Initially Configuring SELinux, lays out the current state of SELinux support inseveral GNU/Linux distributions and provides guidance for installation

Chapter 4, Using and Administering SELinux, is a basic SELinux system guide for system administrators,covering such techniques as user administration

Chapter 5, SELinux Policy and Policy Language Overview, prepares the reader to write or revise

policies, which is necessary when new software is installed on an SELinux system or when policies need

to be adjusted to current system use This chapter discusses the build process, the layout of

policy-related files, and general issues such as macros

Chapter 6, Role-Based Access Control, introduces the syntax of policy files and describes the directivesthat relate to user roles

Chapter 7, Type Enforcement, discusses the next major aspect of SELinux policies, type-enforcementfiles

Chapter 8, Ancillary Policy Statements, finishes the explanation of policy statements with a description ofconstraints and other miscellaneous directives

Chapter 9, Customizing SELinux Policies, pulls together all the material from the book, provides

concrete examples of how to adjust SELinux systems to users' needs, and introduces tools that helpmonitor the system and view policies

Five appendixes list the classes, operations, macros, types, and attributes defined by SELinux policy files

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

Conventions Used in This Book

This book uses the following typographical conventions:

Constant Width Bold

Used in examples and tables to show commands or other text that should be typed literally by the user

Constant Width Italic

Used in examples and tables to show text that should be replaced with user-supplied values

This icon signifies a tip, suggestion, or general note

This icon signifies a warning or caution

A final word about syntax: in many cases, the space between an option and its argument can be omitted

In other cases, the spacing (or lack of spacing) must be followed strictly For example, -wn (no

intervening space) might be interpreted differently from -w n It's important to notice the spacing used inoption syntax

Keyboard Accelerators

In a keyboard accelerator (such as Ctrl-Alt-Del), a dash indicates that the keys should be held downsimultaneously, whereas a space means that the keys should be pressed sequentially For example,Ctrl-Esc indicates that the Control and Escape keys should be held down simultaneously, whereas CtrlEsc means that the Control and Escape keys should be pressed sequentially

IF a keyboard accelerator contains an uppercase letter, you should not type the Shift key unless it'sgiven explicitly For example, Ctrl-C indicates that you should press the Control and C keys;

Ctrl-Shift-C indicates that you should press the Control, Shift, and C keys

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

< Day Day Up >

Using Code Examples

This book is here to help you get your job done In general, you may use the code in this book in yourprograms and documentation You do not need to contact us for permission unless you're reproducing asignificant portion of the code For example, writing a program that uses several chunks of code fromthis book does not require permission Selling or distributing a CD-ROM of examples from O'Reillybooks does require permission Answering a question by citing this book and quoting example codedoes not require permission Incorporating a significant amount of example code from this book intoyour product's documentation does require permission

We appreciate, but do not require, attribution An attribution usually includes the title, author, publisher,and ISBN For example: "SELinux: NSA's Open Source Security Enhanced Linux, by Bill McCarty.Copyright 2004 O'Reilly Media, Inc., 0-596-00716-7."

If you feel your use of code examples falls outside fair use or the permission given above, feel free tocontact us at permissions@oreilly.com

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

How to Contact Us

Please address any comments or questions concerning this book to the publisher:

O'Reilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472(800) 998-9938 (in theU.S or Canada)(707) 829-0515 (international/local)(707) 829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information Thesite also includes a link to a forum where you can discuss the book with the author and other readers.You can access this page at:

http://www.oreilly.com/catalog/selinux

To comment or ask technical questions about this book, send email to:

bookquestions@oreilly.com

For more information about books, conferences, software, Resource Centers, and the O'Reilly

Network, see our web site at:

http://www.oreilly.com

< Day Day Up >

< Day Day Up >

Acknowledgments

Thanks to my editor, Andy Oram, who struggled alongside me through some difficult challenges ofstructure and design This book wouldn't have been nearly as clear and readable without Andy's insightsand patient influence

Thanks also to Margot Maley of Waterside Productions, Inc., who brought this authorship opportunity

to my attention

Several reviewers, some working for O'Reilly Media and some working elsewhere, commented on themanuscript and suggested helpful corrections and improvements In particular, I'd like to thank thefollowing people for taking time to review this book: Dr Steve Beatty, Joshua Brindle, David Castro,and George Chamales I greatly appreciate their assistance and readily confess that any errors in themanuscript were added by me after their reviews, and so are entirely my responsibility

My family—Jennifer, Patrick, and Sara—provided their customary compassion and assistance duringthis latest authorship experience Thanks, guys!

I also acknowledge the faithfulness of my savior, Jesus Christ His perfect love is entirely undeserved

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

Chapter 1 Introducing SELinux

This chapter explains the what and why of SELinux It begins by describing the threat environment andwhy the prevalent model of security—patching against known vulnerabilities—is inadequate The chaptergoes on to describe several security mechanisms designed to protect against both known and unknownvulnerabilities The chapter then presents an overview of SELinux, describing its main features,

capabilities, and history The chapter concludes with a survey of resources helpful to SELinux users

< Day Day Up >

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

1.1 Software Threats and the Internet

Because you're reading this book, it's likely that you're responsible for the management of one or moresensitive hosts If that's the case, you're aware that the threat level for Internet-based attacks has

increased rapidly over the last several years and continues to do so One authoritative barometer of thistrend is the number of incident reports logged by the Computer Emergency Response Team

Coordination Center (CERT/CC) of Carnegie Mellon University's Software Engineering Institute Table1-1 shows the number of incident reports for 2000 through 2003 During this four-year period, incidentreports increased at an average annual rate of almost 85 percent That is, the number of incidents hasroughly doubled each year If this rapid rate of increase continues, the year 2010 will see over 10 millionincident reports

Table 1-1 CERT/CC incident reports[1]

Insider Threats

Not all threats arise from software or the Internet So-called insider threats, which come

from local-area networks or proprietary wide-area networks, can present even more

serious risks Insiders often attack systems by means other than software vulnerabilities

For instance, employees in two work groups may collude to falsify database records to

steal from their employer Such threats generally cannot be prevented by purely technical

means Gartner research has estimated that 70 percent of security incident costs are related

to breaches committed by insiders Securing the Enterprise: The Latest Strategies and

Technologies for Building a Safe Architecture (Gartner, 2003), available at

http://www4.gartner.com/5_about/news/sec_sample.pdf

While available evidence does suggest that system administrators have historically been reluctant toreport incidents and have become less reluctant lately, evidence also indicates that the threat level issubstantial and is rising rapidly As an information assurance researcher, I monitor several class-C

networks for familiar and novel attacks My data shows that a typical host on these networks is subject

to attack every few seconds An unprotected host can succumb to attack in less time than it takes toinstall a typical operating system or software patch Therefore, those for whom the confidentiality,

integrity, and availability of information are important must invest significant effort to protect their hosts,especially those that connect to the Internet

To effectively protect hosts against threats, it's important to understand the nature of the threats and whythey are increasing Three of the most significant factors that have led to the increased level of softwarethreats are software complexity, network connectivity, and active content and mobile code

1.1.1 Software complexity

Because the human intellect is finite, software developers commit errors and leave omissions during theimplementation of software systems The defects resulting from their errors and omissions cause

software systems to behave in unwanted or unanticipated ways when executed in untested or

unanticipated ways Attackers can often exploit such misbehaviors to compromise systems As a generalprinciple, the more complex a system, the greater the intellectual demands its implementation imposesupon its developers Hence, complex systems tend to have relatively large numbers of defects and berelatively more vulnerable to attacks than smaller, simpler systems Modern software systems, such asoperating systems and standard applications, are large and complex The Linux operating system, forinstance, contains over 30 million source lines of code And Red Hat Linux 7.1 was 60 percent largerthan Red Hat Linux 6.2, which was released about one year earlier.[2] Therefore, contemporary

systems are generally vulnerable to a variety of attacks and attack types, as explained in the followingsections of this chapter

[2] Source: http://www.dwheeler.com/sloc/

1.1.1.1 Network connectivity

A second factor contributing to increased software threats is increased network connectivity and, inparticular, the Internet itself Connectivity provides a vector whereby attacks successfully launchedagainst one networked host can be launched against others The Internet, which interconnects the

majority of networks in existence, is the ultimate attack vector The recent popularity of consumer

access to the Internet compounds the threat, since the computers of most consumers are not hardened

to resist attack Unsecured hosts easily fall prey to viruses and worms, many of which install backdoors

or Trojan horses that enable compromised systems to be remotely accessed and controlled Attackerscan launch attacks by using these compromised hosts, thereby hiding their identity from the victims oftheir attacks and law enforcement Many attackers attack from across international borders, whichcomplicates the work of law enforcement Because law enforcement generally has been ineffective inidentifying and apprehending all but a handful of notorious computer criminals, attackers have believedthemselves to be beyond the reach of prosecution and have acted out their whims and criminal urgeswith impunity The recent advent of wireless connectivity exacerbates the risks, as several of the securityfacilities commonly used on wireless networks implementing the IEEE 802.11 standard (such as

Wireless Encryption Equivalent Privacy (WEP)) have turned out to be flawed, and therefore vulnerable

to attack

Active content and mobile code

A third factor contributing to increased software threats is the use of active content and mobile code.Active content refers to documents that have the capability of triggering actions automatically without theintervention, or possibly even the awareness, of their user Ordinary, ASCII-encoded documents are notactive in this sense However, a variety of modern document types can include active content such asAbobe PDF documents, MS Office documents, Java applets, and web pages containing JavaScriptcode or using browser plug-ins Even PostScript documents, which are widely thought to be safe, cancontain active content The danger of active content is that users generally perceive documents as

benign, passive entities However, malicious active content can compromise a user's computer as easily

as any other form of malicious code Opening, or even merely selecting and previewing, a documentcontaining malicious active content may enable the malicious code to compromise a user's computer

Cybercriminals Think Themselves Safe

One of my research projects involves the use of honeypots to study computer attacks and

attackers A honeypot is a specially instrumented system that is left open to attack You can

learn more about them at http://www.honeynet.org

In 2003, I monitored intruders on one of my honeypots, who were discussing the likelihood

of their apprehension and prosecution In response to concerns expressed by one attacker,

another—whom I'll call Peer—responded as follows:

Peer: well didn't give a—*** I'm not in US

Peer: and frankly my country doesn't have a cyberlaw :P

The final two characters in Peer's response, :P, are an Internet Relay Chat (IRC) device

intended to represent the appearance of sticking out one's tongue, a common gesture of

disdain

Mobile code is code designed to be transported across a network for execution on remote hosts

Mobile code is often designed to extend the capabilities of software programs and, because of users'desires for flexible and convenient software, has become ubiquitous Email clients and web browsers, forexample, accept and process a wide variety of mobile code types, including Java and JavaScript

programs, Microsoft ActiveX controls, and others

Unfortunately, active content and mobile code provide more than flexibility and convenience to users:they provide attackers with a flexible and convenient attack vector Many Internet attacks take the form

of active content or mobile code delivered via email When a user views an email message containingmalicious code, the malicious code may seize control of the user's computer Especially sophisticatedmalicious code may not even require user action Such code may be capable of compromising a

vulnerable computer in a fraction of a second, without presenting the computer's user with an

opportunity to refuse the code permission to execute or even receive notification of the event

For more information on malicious mobile code in the context of MicrosoftWindows, see Malicious Mobile Code (O'Reilly)

1.1.2 Privilege Escalation

Most common operating systems, including Microsoft Windows and Unix/Linux, provide multiple levels

of authorization, thereby restricting the operations that some programs or users are permitted to perform.Multiple levels of authorization act as bulwarks against the damage done when a program is

compromised Many common operating systems have two primary levels of authorization—one forordinary users and one for the system administrator A handful of operating systems, such as those used

on PDAs and small computing devices, do not impose any such restrictions

Restricting programs to the few functions they need to perform is called the principle of least privilege.Operating systems that lack multiple levels of authorization cannot implement the principle of least

privilege and are therefore inherently quite insecure When an attacker compromises a program runningunder a single-level operating system, the attacker gains the ability to perform any operation of which thesystem is capable However, an attacker who compromises a program on a system that has multiplelevels of authorization obtains only the privilege to perform those operations for which the program isauthorized If the program performs tasks related to system administration, the attacker may gain

wide-ranging privileges However, if the program performs relatively mundane tasks, the attacker mayachieve relatively little beyond gaining the ability to disrupt operation of the compromised program.Nevertheless, an attacker who compromises even a program that confers few privileges may achieve asignificant victory, because the attacker can use the privileges conferred by the program as a beachheadfrom which to attack programs conferring additional or greater privileges Alternatively, the attacker mayintentionally disrupt operation of the compromised program in what is called a denial of service

The Apache OpenSSL Attack

A popular Internet attack during 2002 and 2003 was the Apache OpenSSL attack,

directed against the Apache web server Most users configure Apache to run as an

ordinary user, rather than as the system administrator So, attackers who successfully

exploited a web server using the Apache OpenSSL attack generally obtained only limited

privileges However, at the time of the attack's popularity, Linux systems were vulnerable to

a second attack, one targeting the ptrace facility used to trace and debug processes Unlike

the Apache web service, which is available to remote users, the ptrace facility is available

only to local users Successful compromise of an Apache web server enabled attackers to

access the ptrace facility and exploit a ptrace defect that conferred full system

administration privileges

1.1.3 The Patch Cycle and the 0-Day Problem

When a software vendor learns that one of its products is vulnerable to attack, the vendor will generallyissue a patch Users can install the patch, which modifies the vulnerable product in a way intended toeliminate—or at least mitigate—the vulnerability Occasionally, a patch alleged to eliminate a vulnerabilitywill fail to actually do so Worse yet, occasionally a patch will introduce one or more new vulnerabilities

So patches are sometimes less than ideal solutions But, as a means of defending against software

attacks, patches suffer from a more fundamental flaw

The essential problem with patches is that they are a reactive, rather than proactive, response Patching

is thus a continual process consisting of the following steps, known as the patch cycle:

3 Users acquire, authenticate, test, and install the patch

It may seem odd that security researchers publish vulnerabilities rather than privately inform vendors ofthem, because publication of a vulnerability may help attackers discover a way to exploit it Indeed, mostsecurity researchers do prefer to inform vendors of vulnerabilities privately rather than publicly But manyvendors consistently fail to release patches in a timely manner And some vendors fail even to

acknowledge in a timely manner vulnerability reports submitted privately by researchers So, manysecurity researchers believe that it's necessary to force vendors to fix their products and therefore elect

to publish vulnerabilities In an effort to avoid giving attackers opportunity to exploit vulnerabilities, someresearchers publish them only after first privately notifying the vendor and providing an opportunity topublish a patch before publication of the vulnerability

Vendors can supply patches only for known vulnerabilities, so a fully patched computer remains

vulnerable to attacks that are unknown to the vendor Moreover, vendors require time to producepatches even for known vulnerabilities So fully patched computers also remain vulnerable to knownattacks for which vendors have not yet released patches The interval between publication of a

vulnerability and availability of a related patch is a time of especially high vulnerability During the interval,vendors race to produce effective patches, while attackers race to produce effective exploits This racegenerally favors the attackers, who do not have to test and analyze their exploits the same way thatvendors must test and analyze their patches So publication of a vulnerability amounts to initiation of acountdown to the widespread availability and use of exploits targeting the vulnerability

Moreover, vulnerabilities are sometimes privately known and exploited well in advance of their

publication Vulnerabilities for which no patch is yet available are known as 0-day vulnerabilities orsimply 0-days ("oh days") The same term is often used to refer to attacks that target 0-day

vulnerabilities Attacks that target 0-days are a particularly potent form of attack, because even systemswhose administrators have assiduously kept current with all vendor patches are vulnerable to them.Fortunately, most attacks do not target 0-days The National Institute of Standards cites CERT dataindicating that 95 percent of attempted network intrusions target vulnerabilities for which patches areavailable.[3] However, patching is ineffective against the remaining 5 percent of network attacks, whichtarget 0-day vulnerabilities

[3] Procedures for Handling Security Patches, NIST Special Publication 800-40, p 2, available at

http://csrc.nist.gov/publications/nistpubs/800-40/sp800-40.pdf

1.1.4 Protecting Against 0-Days

Ordinary computer users may be content merely to patch their computers regularly, a practice that canprotect them against 95 percent of attempted network intrusions However, administrators of sensitivesystems generally cannot afford to allow their systems to remain vulnerable to the 5 percent of attemptedintrusions that target 0-day vulnerabilities Although patching is, by definition, an ineffective defenseagainst attacks targeting 0-day vulnerabilities, several types of defenses are more or less effective inprotecting against them

Defense by Layers

No software is known to be free of defects, and no means of producing defect-free

software is known Thus, no means of network or host defense that depends on the correct

operation of software can be fully reliable Hence, practical defense consists of

implementing multiple defensive measures in hopes that if one defensive measure fails, one

or more other measures will prove effective This principle is known as defense by layers

A corollary principle holds that imperfections in a defense mechanism do not preclude its

use, since all defense mechanisms are considered to be imperfect Instead, rational

decisions concerning which defense mechanisms an organization should deploy are based

on risk assessment and cost-benefit analysis

1.1.5 Network and Host Defenses

Because hosts are generally subject to a variety of vulnerabilities for which no patch exists or has beeninstalled, hosts must be protected against attack Two basic sorts of defenses are employed:

Network firewalls

Firewalls restrict the traffic flowing into and out of a network The most basic sort of firewall restrictstraffic by IP address More sophisticated firewalls allow only designated application-layer protocols orrequests having a specified form For instance, some firewalls can block web client access to malformedURLs of the sort often associated with attacks However, most currently deployed firewalls do notexamine the application layer of traffic Such firewalls are generally ineffective in protecting against 0-dayattacks launched against ports to which the firewall is configured to allow access

Network intrusion detection and prevention systems

Intrusion detection systems don't prevent attacks from succeeding; they merely detect them To do so,they monitor network traffic and generate an alert if they recognize an attack They typically use a

database of signatures or rules to recognize the attacks Thus, an intrusion detection system may notgenerate an alert for a particular 0-day attack, since the attack may not match any rule or signaturewithin the system's database Some intrusion detection systems do not rely on a database of signatures

or rules Instead they alert the user to unusual traffic However, anomaly-based intrusion detectionsystems are not yet in widespread use

An intrusion prevention system attempts to detect and prevent attacks However, like anomaly-basedintrusion detection systems, intrusion prevention systems are not yet in widespread use

• Access control lists

Host firewalls and intrusion detection systems

Firewalls and intrusion detection systems can be deployed on individual hosts as well as at the networklevel Because host-based firewalls operate similarly to network-based firewalls, they are seldom moreeffective than network-based firewalls in protecting against 0-day attacks Host-based intrusion

detection systems are sometimes more effective in recognizing novel attacks than their network-basedcousins However, like their cousins, they detect rather than prevent attacks, so they are not an adequatesolution to the 0-day problem

Logging and auditing

Logs and other audit trails can provide indications or clues that an attack has succeeded However,properly monitoring logs requires considerable effort, and many system administrators fail to take thetime to regularly review logs But even when logs are regularly monitored, they merely detect rather thanprevent attacks

Memory protection

One technique that is often effective in protecting against 0-day attacks is memory protection Here aresome of the most popular memory protection schemes:

Stack canaries

Based on a concept originated by Crispin Cowan, a stack canary is a memory word containing a

designated value, pushed onto the stack when a routine is called When control returns to the callingroutine, it verifies that the value of the stack canary has not been modified Buffer overflow attacks thattarget the stack are likely to modify the value of the stack canary and therefore may be detected

Nonexecutable stack

Buffer overflow attacks that target the stack generally inject code into the stack and compromise thetarget host by executing the injected code Since most programs don't require that stack contents beexecutable, buffer overflow attacks can be complicated or even thwarted by preventing execution ofcode residing on the stack Many common microprocessors—including those having the Intel x86

architecture—can be configured to prohibit execution of stack contents

Random assignment of memory

Many exploits depend on knowledge of the specific memory locations occupied by the components ofvulnerable programs Specially modified compilers or loaders can randomize the addresses of memoryinto which program components are loaded, thereby breaking exploits that depend on fixed memoryassignments

Well-designed and well-implemented memory protection schemes tend to be effective even againstattacks on 0-day vulnerabilities However, some specific implementations of memory protection

schemes can be circumvented relatively easily In other cases, such as that of Microsoft's "security errorhandler" function added to its C++ compiler, the scheme itself is the source of vulnerabilities.[4]

[4] See "Microsoft Compiler Flaw Technical Note," by Chris Ren, Michael Weber, and Gary McGraw,and "Cigital Warns of Security Flaw in Microsoft NET Compiler," both available at

http://www.cigital.com/news/index.php?pg=art&artid=70

SELinux does not incorporate memory protection facilities However, SELinux consistently interoperateswell with such facilities Therefore, SELinux users can generally employ memory protection featureswhen their operating system provides them

Sandboxes

Yet another approach to defending hosts against 0-day attacks is running programs, especially services,within contexts called sandboxes that limit their capabilities Sandboxing is common for programs running

under Unix and Unix-like operating systems such as Linux, which includes the chroot command that

creates such a sandbox Sandboxing is also used for Java programs running within popular web

browsers

Sandboxing generally doesn't prevent the exploitation of an 0-day vulnerability But, the attacker whosuccessfully exploits an 0-day vulnerability in a sandboxed program gains access to only the capabilitiesafforded by the sandbox Therefore, the sandbox limits the damage resulting from a successful attack

However, sandboxes are software entities and thus are equally as imperfect: an attacker who gainsaccess to a sandbox may be able to attack and escape it In general, under Unix and Unix-like operating

systems, it's possible for attackers to escape chroot sandboxes that contain programs running as the

root user However, sandboxes that contain programs running as a non-root user are less vulnerable

SELinux provides a special sort of sandbox, known as a domain, that is very difficult for attackers to

escape—even if the domain contains programs running as the root user

Access-control lists

An especially flexible form of sandbox is provided by mechanisms known as access-control

mechanisms In their simplest form, access-control mechanisms are found in every multiuser operatingsystem that protects the files and resources owned by one user from unauthorized access by other users

Access-control mechanisms are implemented by associating access-control lists (ACLs) with objects(e.g., files and directories), thereby limiting access to the protected objects Essentially, the most familiarform of an ACL consists of three elements:

By associating an ACL with a file, for example, you can specify the users permitted to access the file

The familiar Unix chmod command accomplishes exactly this result Representing many sorts of system

objects, such as devices and FIFOs, this simple mechanism enables system administrators and users tolimit access to most system objects ACLs can also specify access by subjects other than users, such asprograms Although several commercial operating systems based on Unix include ACLs, Linux doesnot SELinux, on the other hand, goes beyond ACLs in providing a special type of access control

known as mandatory access control (MAC) The following section explains MAC and contrasts it withthe type of access control commonly used by Linux

1.1.6 Discretionary and Mandatory Access Control

Most operating systems have a built-in security mechanism known as access control Two main types ofaccess control are commonly used:

Discretionary Access Control (DAC)

Discretionary access controls are specified by the owner of an object, who can apply, modify, or

remove them at will

Mandatory Access Control (MAC)

Mandatory access controls are specified by the system They cannot be applied, modified, or

removed—except perhaps by means of a privileged operation

1.1.6.1 Discretionary access control

Linux employs discretionary access control Under discretionary access control, a program runs with thepermissions of the user executing it For instance, if I log in as the user mccartyb and execute the

program mutt to read my email, the program executes under my user ID and is capable of performingany operation that I'm permitted to perform In particular, it can read and write files in my home

directory and its subdirectories, such as the sensitive files holding SSH information Of course, muttdoesn't need to access such files and generally wouldn't do so But, by exploiting a vulnerability in mutt,

an attacker may coerce mutt to access or modify sensitive files, thereby compromising the security of myuser account

Obviously, mutt doesn't need to be able to perform every operation that I'm permitted to perform It has

a well-defined purpose that requires only a handful of permissions, mostly related to network access.Granting mutt a broad array of permissions is inconsistent with the principle of least privilege From thestandpoint of the principle of least privilege, giving a program all the privileges of the user running theprogram is wretchedly excessive and highly risky

Under discretionary access control, a compromised program jeopardizes every object to which theexecuting user has access The risk is particularly great for programs that run as the root user, becausethe root user has unrestricted access to system files and objects If an attacker can compromise a

program running as the root user, the attacker can often manage to subvert the entire system

Therefore, discretionary access control provides a rather brittle sort of security When subjected to asufficiently potent attack, discretionary access control shatters, giving the attacker a virtually free hand

1.1.6.2 Mandatory access control

SELinux supplements the discretionary access control mechanism of Linux with mandatory accesscontrol Under mandatory access control, each program runs within a sandbox that limits its permissions

A compromised program jeopardizes only the permissions available to the program These are generally

a small subset of all the permissions afforded the user executing the program

Generally speaking, mandatory access controls are much more effective than Unix-style discretionaryaccess controls, for the following principal reasons:

to the principle of least privilege; that is, they're generally granted permission to perform only a limited set

of necessary operations Therefore, an attacker who compromises a program running as the root user on

an SELinux system does not generally gain an effective beachhead from which to successfully attack theentire system Instead, the attacker gains control of only the compromised program and a handful ofrelated operations

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

1.2 SELinux Features

SELinux is a software product that includes several mechanisms that protect against attacks exploitingsoftware vulnerabilities, including attacks on 0-day vulnerabilities In particular, SELinux implementsrole-based access control and sandboxing

SELinux also provides a logging and audit facility that records attempts to exceed specified permissions

By monitoring the system log, the administrator of an SELinux system can often discover attempts toescalate privileges and take action to prevent an intruder or insider from interfering with operation of thesystem

SELinux is designed to protect against misuse and unauthorized use such as:

• Information security breaches

1.2.1 How SELinux Works

Figure 1-1 depicts the operation of SELinux in a highly simplified fashion SELinux works by associatingeach program or process with a sandbox known as a domain Each domain is assigned a set of

permissions sufficient to enable it to function properly but do nothing else For instance, a domain islimited in the files it can access and the types of operations it can perform on those files To enablespecification of such permissions, each file is labeled with information called a security context Thedefinition of a domain spells out what operations it can perform on files having specific security contexts

A domain cannot access files having security contexts other than those for which it is explicitly grantedaccess

Figure 1-1 The operation of SELinux

Under specified conditions, a process that executes a program leaves its current domain and transitions

to a new domain Typically, transitions occur upon executing a program designated as an entry point tothe new domain The new domain may have more or fewer privileges than the original domain Thus,programs can initiate other programs having more or fewer privileges than themselves

An SELinux facility known as type enforcement (TE) ensures that the rules governing domains arealways observed SELinux also has a secondary facility known as role-based access control (RBAC).RBAC limits user access to domains For instance, some domains are defined to be accessible only tothe system administrator, whereas other domains are defined to be publicly available to any user

An exciting aspect of SELinux is that the definitions of domains, security contexts, and transitions appear

in files called policy files that can be modified by the SELinux system administrator Thus, SELinuxsecurity policies are extremely flexible and can support a wide range of security needs For instance,suppose that you want to install a program that neither you nor anyone you know has previously rununder SELinux Therefore, no policy specifying the operations that the program should and should not

be allowed to perform exists Nevertheless, you can create such a policy and enjoy the benefits ofrunning the program in a manner consistent with the principle of least privilege

1.2.2 SELinux Components and Linux Security Modules (LSM)

SELinux was originally implemented as a set of Linux kernel modules that worked with the Linux 2.2kernel SELinux has since been updated to work with Linux 2.4 SELinux can also work with the LinuxSecurity Modules (LSM) feature of the Linux 2.6 kernel

LSM consists of a set of hooks inserted into the Linux kernel These hooks provide the means to notify

a software unit, such as SELinux, whenever a process attempts to perform an operation on an object,such as opening a file for read access or deleting a file LSM also provides a means whereby the

software unit can prohibit the attempted access, making it straightforward for software developers toimplement a security engine that oversees access to files and other objects, such as that used in SELinux

In addition to kernel modules, SELinux includes a set of system administration programs that have beenmodified to be aware of the SELinux environment, and a set of programs used to administer SELinuxitself SELinux also includes a policy, implemented as a set of files, that defines users and roles and their permissions

SELinux and User-Mode Linux (UML)

User-Mode Linux is an open source product that enables a single host to run multiple,

sandboxed instances of the Linux kernel, referred to as virtual machines UML's function is

roughly comparable to that of commercial virtualization products, such as VMware and

Microsoft's Virtual PC However, UML supports only Linux, whereas VMware and

Virtual PC support a variety of operating systems Each virtual machine running under

UML can run programs and applications, maintain a distinct filesystem separate from that of

other virtual machines, and access the network So if a program or an entire instance of a

running kernel is compromised, the other programs and kernel instances may not be

affected

SELinux includes a set of policies that are intended to strengthen the UML sandbox and

thereby improve system security and integrity Using SELinux, you can make it less likely

that a wayward application or a successful attack compromising one virtual machine will

lead to the subversion or failure of other virtual machines You can learn more about

User-Mode Linux at http://user-mode-linux.sourceforge.net

Alternatives to SELinux

An alternative product providing functions generally similar to those of SELinux is

GRSecurity, described at http://grsecurity.org Like SELinux, GR Security is supported

only for Linux 2.x

Developers of open source operating systems other than Linux are implementing products

similar to SELinux For example, the BSD community is creating TrustedBSD To learn

more about TrustedBSD, see its web site, http://www.trustedbsd.org

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

< Day Day Up >

1.3 Applications of SELinux

To understand the value of SELinux, let's revisit the Apache and ptrace vulnerability mentioned earlier inthe sidebar "The Apache OpenSSL Attack." Unknown to the administrator of the server, the version ofApache being run contains a vulnerability for which no patch is yet available An attacker exploits thisvulnerability to remotely compromise Apache, thereby gaining the privileges extended to the apache useraccount Because the system's security is based on discretionary access control, these privileges arerelatively extensive In particular, they're sufficient to allow the attacker to execute the ptrace program,which also contains a vulnerability Moreover, the ptrace program is a setsuid program that always runs

as the root user regardless of the identity of the user who launches it Thus, when the attacker

compromises ptrace, he gains access to the root account and has unrestricted access to all system filesand resources The attacker establishes a backdoor by which to conveniently reenter the system at will,cleans the system logs to cover all traces of his intrusion, and adds the system to his list of owned hosts

If the web server had been running on an SELinux host with properly configured policies, the scenariowould have proceeded differently As before, the attacker would have been able to compromise

Apache by using his 0-day attack But, having done so, the attacker would gain only those permissionsafforded the domain under which Apache was run These would not permit the attacker to run theptrace program, and so he would be prevented from using the ptrace vulnerability to seize control of thesystem The domain associated with Apache would not provide the attacker with write access to theHTML files making up the web site Thus the attacker would be prevented from defacing it Unless theattack terminated the Apache process, the attack might not even interrupt the availability of web

services Under SELinux, the effects of the attack might be largely mitigated

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

1.4 SELinux History

SELinux, though only recently released to the public as a software product, has a substantial heritage.SELinux descends from work that began several decades ago In 1973, computer scientists David Belland Leonard LaPadula defined the concept of a secure system state and published a formal modeldescribing a multilevel security system

Later, in the 1980s, the work of Bell and LaPadula strongly influenced the U.S government's

development of the Trusted Computer System Evaluation Criteria (TCSEC, popularly known as theOrange Book) The TCSEC defined six evaluation classes with progressively more stringent securityrequirements: C1, C2, B1, B2, B3, and A1 Class C1 and C2 systems, like Linux, depended upondiscretionary access controls Class B1 systems and systems of higher classes had to, like SELinux,implement mandatory access controls

During the 1990s, researchers at the U.S National Security Agency (NSA) worked with SecureComputing Corporation (SCC) to develop a strong and flexible mandatory access control architecture.Initially, their work focused on theoretical proofs of the properties and characteristics of the architecture.Eventually, working with a research team at the University of Utah, they developed a working prototype

of the architecture called Flask within Fluke, a research operating system

Later, NSA researchers worked with Network Associates and the R&D firm MITRE to implement thearchitecture within the open source Linux operating system Their work was released to the public inDecember 2000, as an open source product

Subsequently, Linux 2.5 was modified to incorporate LSMs, a kernel feature intended to simplifyintegration among SELinux, similar products, and the Linux operating system This modification wascarried forward to Linux 2.6 when development of Linux 2.5 was deemed complete

More recently, several Linux distributors have announced plans to support SELinux within their Linuxdistributions Among these are Red Hat, distributor of the commercial Linux distribution with the largestmarket share in the U.S and worldwide, and SUSE, distributor of Europe's leading Linux distribution.SELinux is already a standard component of Fedora Core, the noncommercial Linux distribution whosedevelopment is sponsored by Red Hat, and several other noncommercial Linux distributions, includingDebian GNU/Linux and Gentoo Linux

Several Linux distributions augment SELinux with other security mechanisms For instance, GentooLinux can be configured to compile the Linux kernel and applications to work with either of two

One of the best ways to observe the high level of security possible by using SELinux is to

visit one of the SELinux demonstration systems provided for public use Using an SSH

client, you can remotely log into a demonstration system as the root user and try to hack

your way to escalated privileges Most likely, you'll completely fail

One such system is the demonstration system hosted by Gentoo's Hardened Project,

described at http://selinux.dev.gentoo.org Another demonstration system, a Fedora Core

system administered by Russell Coker, is described at

http://www.coker.com.au/selinux/play.html Finally, a demonstration system running Debian

is described at http://selinux.simplyaquatics.com

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

1.5 Web and FTP Sites

The main web site for SELinux is provided by the NSA:

The NSA's SELinux

http://www.nsa.gov/selinux

The web site includes a FAQ, available at http://www.nsa.gov/selinux/info/faq.cfm

In addition, various Linux distributors and interested parties provide SELinux-related web pages andFTP sites Among the most popular and useful are:

Kerry Thompson's SELinux

Several mailing lists address issues related to SELinux Among these are:

The NSA's SELinux mailing list

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

"Orange Book."[1]) Because of this chapter's practical aim, its emphasis is on basic Flask and SELinuxconcepts and terms Chapter 5 explains the SELinux security model in greater detail In addition toproviding an overview of SELinux functions, Chapter 5 provides an overview of SELinux architecture,describing each major SELinux component.

[1] DoD Trusted Computer System Evaluation Criteria (DoD 5200.28-STD), available from the U.S.National Institute of Standards, http://csrc.nist.gov/secpubs/rainbow/nsaorder.txt

< Day Day Up >

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

2.1 Subjects and Objects

Like other onetime elementary and secondary students, you've probably endured many school lectures

on the subject of English grammar If you're old enough, you may even have endured that most fearedexercise of secondary education (which is now largely extinct): the sentence diagram, like that shown in

Figure 2-1

Figure 2-1 A simple sentence diagram

At the time of your elementary and secondary studies, the various parts of speech—nouns, verbs,

adjectives, adverbs, and so on—and components of sentence structure—subjects, actions, direct andindirect objects, and so on—may not have seemed to you and your fellow students to be the mostfascinating of topics And, unless in adult life you've worked as a writer or editor, your aversion mayseem to have been well-founded: many adults seem to get through life quite well with only a very

fragmentary understanding of English grammar

If I claimed that knowledge of English grammar would help you better secure your computer systems,would that influence your estimate of the value of its study? Perhaps not But my claim would

nevertheless be true The security model that underlies SELinux is based on simple grammatical conceptscommon to English and most other human languages, as well as artificial languages such as computerprogramming languages Some scientists believe that an understanding of these concepts is more or lessintrinsic to humankind—encoded in the structure of the human mind itself—and quietly shapes the way

we view and understand reality Of course, if grammar is truly innate, one may well wonder why it'snecessary to teach it to students But rather than get sidetracked by a debate over psycholinguistics (asthe study of the grammatical mind is called), let's explore the relationship between grammar, SELinux,and computer security

At its root, the SELinux security model encompasses three elements:

Subjects are the actors within a computer system You might initially think that users would be the

subjects of the SELinux security model, especially if your experience with computer systems has beenprimarily with desktop—rather than server—systems However, users don't crawl inside their computersand act directly on the bits and bytes that compose computer systems Instead, processes are the trueactors However, processes often act as surrogates for human users So subjects and users are closelyassociated, even though processes—not users—are the true actors

Processes and Programs

If you're not a programmer, the distinction between processes and programs may not be

obvious Or even if you are a programmer, you may be confident that you understand the

distinction, but be unable to readily articulate it

Simply put, a program is an executable file, whereas a process is a program that has been

read into memory and has commenced execution For instance, if you start two identical

terminal windows on your graphical desktop, you have started two processes that run the

same program Unlike a program, a process has state information The state information

associated with a process records the identity of the user account running the process, the

instruction pointer (which indicates the next instruction to be executed), the value of every

active program variable, and a variety of other information Because processes and

programs are closely related, some folks like to think of processes as programs in motion

In grammar, subjects operate on objects The same is true in the SELinux security model, where

subjects (processes) also operate on objects As summarized in Appendix A, SELinux defines severaldozen security classes (or, more simply, classes) of objects, including such workhorses as:

• Special files of various types (block device, character device, socket, FIFO, and so on)

Notice that processes can serve as both subjects and objects of actions

In Linux, many kinds of entities are represented as files In particular, directories, devices, and memorycan all be accessed as files So the most common class of SELinux object that subjects act upon is a file

Table 2-1 describes the object security classes defined by SELinux

Table 2-1 SELinux object security classes

File classes

filesystem Formatted filesystem residing on disk partition

Interprocess communication classes

Network classes

netlink_socket Socket used to communicate with kernel via the

netlink syscall

address

packet_socket Obsolete object type used by Linux 2.0 programs

invoking the socket syscall

unix_dgram_socket Unix-domain datagram socket

unix_stream_socket Unix-domain stream socket

The actions that SELinux subjects perform upon objects vary with the type of object For instance, asubject can perform such operations as these on file objects:

Using this simple framework—subjects, actions, and objects—we can identify the fundamental

operation performed by the SELinux security server: determining whether a given subject is permitted toperform a given action on a given object For instance, SELinux decides questions such as: Is process

24691 permitted to read the file known as /etc/shadow? To make such decisions, the SELinux securityserver consults its policy database By basing security decisions on policies stored in a database,

SELinux achieves a high degree of flexibility Figure 2-2 illustrates this sample decision

Figure 2-2 A typical SELinux decision

Linux and SELinux: Dueling Security

Mechanisms?

As explained in the preceding chapter, Linux has its own system of discretionary access

control (DAC) How does Linux DAC interoperate with the mandatory access control

(MAC) provided by SELinux? Do we end up with dueling security mechanisms?

Fortunately, Linux DAC and SELinux MAC play well together When making security

decisions, SELinux first hands off the decision to Linux DAC If DAC forbids an action, the

action is not permitted If, on the other hand, DAC permits an action, then SELinux

performs its own authorization check, based on MAC A requested action is allowed to

occur only if both the Linux DAC and SELinux MAC authorizations are approved

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

2.2 Security Contexts

The discussion in the preceding section might lead you to believe that SELinux makes security decisionsbased on the identity of individual subjects and objects In principle, such a system could be made towork But the system would be unnecessarily unwieldy Because processes related to a single programcan generally be treated the same, it's more convenient to make security decisions based on sets orclasses of subjects and objects rather than on individual objects For example, every instance of theSSH server should generally be given the same permissions, including read access to

/etc/ssh/sshd_config Similarly, all the files within a given directory often can be manipulated by the

same subject For example, the DHCP service should be permitted to manipulate any of the files in

/var/state/dhcp To simplify decision making, similar subjects can be grouped and similar objects can be

of an object, the user identity gives the user account that owns the object

In tracking user identities, SELinux does not use the list of user accounts

maintained by Linux in /etc/passwd Instead, it uses its own database and a

mapping that associates SELinux users with Linux users This approach isconsistent with the philosophy that Linux access controls and SELinux accesscontrols should be completely separate, so that changes to one don't affect theother One important benefit of keeping separate user account databases is that

changes to /etc/passwd don't invalidate the SELinux security attributes of

subjects and objects Keeping separate user databases is not as cumbersome

as it may seem, because most systems can be configured to use only a handful

of SELinux user accounts That is, many Linux user accounts can often bemapped to a single SELinux user account

Role

Under SELinux, users are authorized to enter one or more roles, each of which defines a set of

permissions a user can be granted At a given time, a user can reside in only a single role A user cantransition from one authorized role to another by using the special command newrole This commandchanges the user's SELinux role similar to the way the Linux su command changes a user's Linux identity.SELinux establishes a special role, sysadm_r, used for administering SELinux facilities

Type

Types, which are also known as domains, divide subjects and objects into related groups Types are theprimary security attribute SELinux uses in making authorization decisions They establish the sandboxesthat constrain processes and prevent privilege escalation Therefore, you can think of a type as naming arelated sandbox

In SELinux whitepapers, such as those available at the NSA web site andelsewhere, you may read that type and domain are distinct concepts that mustnever be confused The original Flask model—and other computer securitymodels—do carefully distinguish these terms However, in SELinux the termsare synonymous, notwithstanding claims to the contrary

Types are the workhorse security attribute: an SELinux policy typically defines only a handful of usersand roles, but dozens or even hundreds of types

Conventions help in distinguishing names that represent users, roles, and types Table 2-2 summarizesthe conventions

Table 2-2 Naming conventions for security attributes

The three SELinux security attributes—user identity, role, and type—together make up what's called asecurity context For convenience and efficiency, SELinux stores security contexts in a table A securityidentifier (SID) identifies each table entry Earlier, I implied that SELinux bases security decisions onsecurity contexts This is approximately correct But, more precisely, SELinux makes security decisionsbased on SIDs rather than security contexts, thereby gaining some efficiency since SIDs are represented

as integers and are therefore efficiently manipulated by the CPU

Sometimes, a security context is loosely referred to as an SID Because there is

a one-to-one correspondence between security contexts and SIDs, suchreferences are not too harmful or confusing

During system initialization, the security context table is preloaded with a small number of SID values.These values are called initial SIDs

Because subjects are active, they often can take on a variety of roles Objects, on the other hand, arepassive and seldom have need of roles However, every subject or object must possess all three securityattributes (user, role, and type) Objects that have no other need of a role are assigned the dummy roleobject_r

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

< Day Day Up >

< Day Day Up >

2.3 Transient and Persistent Objects

Two kinds of objects exist within a Linux system: transient objects and persistent objects A transientobject has a quite limited lifetime, often existing merely as a data structure within kernel space A

process is the most common kind of transient object SELinux can directly associate an SID with atransient object by keeping a memory-resident table that maps transient object identities to SIDs andthence to security contexts

In contrast to transient objects, a persistent object has an indefinite lifetime The most common persistentobjects are files and directories Because persistent objects, once created, generally exist until they'redestroyed, a persistent object may exist across several system startups Thus, a memory-resident tablecan't be used to associate persistent objects with their SIDs, because the contents of memory-residenttables are lost at system startup Therefore, associating a persistent object with its security context issomewhat complicated

In general, persistent objects are associated with Linux filesystems, which can be used to store theirsecurity contexts Several Linux filesystem types, including the standard ext2 and ext3 filesystem types,provide an extended attribute feature that can be enabled during compilation of a Linux kernel SELinuxuses the extended attribute to store persistent security identifiers (PSIDs) on the filesystem SELinuxuses memory-resident tables to map PSIDs to SIDs, and thence to security contexts

An important operation performed when initially installing SELinux involvescreating the PSIDs for persistent objects, a process known as file labeling, ormerely labeling A special utility named setfiles is used to perform the labeling,which is guided by a database called the file context The file context identifiesthe initial security context that should be associated with specific files, and adefault context that should be associated with files not explicitly identified in thefile context Once file labeling is complete, the file context is not needed exceptunder extraordinary circumstances, such as recovery from filesystem damage

< Day Day Up >

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html