The SELinux Notebook (4th Edition)

Authors Richard Haines

License GFDL-1.3-no-invariants-or-later GPL-3.0-or-later

Plaintext

The SELinux Notebook

The SELinux
Notebook
(4th Edition)

Page 1
The SELinux Notebook

0. Notebook Information

0.1 Copyright Information
Copyright © 2014 Richard Haines.
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.3 or any later version published
by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts,
and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNUFree Documentation
License".
The scripts and source code in this Notebook are covered by the GNU General Public
License. The scripts and code are free source: you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or any later version.
These are distributed in the hope that they will be useful in researching SELinux, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
scripts and source code. If not, see <http://www.gnu.org/licenses/>.

0.2 Revision History
Edition Date Changes
1.0 20th Nov '09 First released.
2.0 8th May '10 Second release.
3.0 2nd September '12 Third release.
4.0 30th September '14 Fourth release.

0.3 Acknowledgements
Logo designed by Máirín Duffy

0.4 Abbreviations
AV Access Vector
AVC Access Vector Cache
BLP Bell-La Padula
CC Common Criteria
CIL Common Intermediate Language
CMW Compartmented Mode Workstation
DAC Discretionary Access Control

Page 2
The SELinux Notebook

F-20 Fedora 20
FLASK Flux Advanced Security Kernel
Fluke Flux µ-kernel Environment
Flux The Flux Research Group (http://www.cs.utah.edu/flux/)
ID Identification
LSM Linux Security Module
LAPP Linux, Apache, PostgreSQL, PHP / Perl / Python
LSPP Labeled Security Protection Profile
MAC Mandatory Access Control
MCS Multi-Category Security
MLS Multi-Level Security
NSA National Security Agency
OM Object Manager
OTA over the air
PAM Pluggable Authentication Module
RBAC Role-based Access Control
rpm Red Hat Package Manager
SELinux Security Enhanced Linux
SID Security Identifier
SMACK Simplified Mandatory Access Control Kernel
SUID Super-user Identifier
TE Type Enforcement
UID User Identifier
XACE X (windows) Access Control Extension

0.5 Terminology
These give a brief introduction to the major components that form the core SELinux
infrastructure.
Term Description
Access Vector A bit map representing a set of permissions (such as open,
(AV) read, write).
Access Vector A component that stores access decisions made by the
Cache (AVC) SELinux Security Server for subsequent use by Object
Managers. This allows previous decisions to be retrieved
without the overhead of re-computation.
Within the core SELinux services there are two Access Vector
Caches:
1. A kernel AVC that caches decisions by the Security
Server on behalf of kernel based object managers.

Page 3
The SELinux Notebook

Term Description
2. A userspace AVC built into libselinux that caches
decisions when SELinux-aware applications use
avc_open(3) with avc_has_perm(3) or
avc_has_perm_noaudit(3) function calls. This
will save kernel calls after the first decision has been
made.
Domain For SELinux this consists of one or more processes associated
to the type component of a Security Context. Type
Enforcement rules declared in Policy describe how the
domain will interact with objects (see Object Class).
Linux Security A framework that provides hooks into kernel components
Module (LSM) (such as disk and network services) that can be utilised by
security modules (e.g. SELinux and SMACK) to perform
access control checks.
Currently only one LSM module can be loaded, however work
is in progress to stack multiple modules).
Mandatory An access control mechanisim enforced by the system. This
Access Control can be achieved by 'hard-wiring' the operating system and
applications (the bad old days - well good for some) or via a
policy that conforms to a Policy. Examples of policy based
MAC are SELinux and SMACK.
Multi-Level Based on the Bell-La & Padula model (BLP) for
Security (MLS) confidentiality in that (for example) a process running at a
'Confidential' level can read / write at their current level but
only read down levels or write up levels. While still used in
this way, it is more commonly used for application separation
utilising the Multi-Category Security variant.
Object Class Describes a resource such as files, sockets or services.
Each 'class' has relevant permissions associated to it such as
read, write or export. This allows access to be enforced on the
instantiated object by their Object Manager.
Object Manager Userspace and kernel components that are responsible for the
labeling, management (e.g. creation, access, destruction) and
enforcement of the objects under their control. Object
Managers call the Security Server for an access decision
based on a source and target Security Context (or SID), an
Object Class and a set of permissions (or AVs). The Security
Server will base its decision on whether the currently loaded
Policy will allow or deny access.
An Object Manager may also call the Security Server to
compute a new Security Context or SID for an object.
Policy A set of rules determining access rights. In SELinux these
rules are generally written in a kernel policy language using
either m4(1) macro support (e.g. Reference Policy) or the
new CIL language. The Policy is then compiled into a binary

Page 4
The SELinux Notebook

Term Description
format for loading into the Security Server.
Role Based SELinux users are associated to one or more roles, each role
Access Control may then be associated to one or more Domain types.
Security Server A sub-system in the Linux kernel that makes access decisions
and computes security contexts based on Policy on behalf of
SELinux-aware applications and Object Managers.
The Security Server does not enforce a decision, it merely
states whether the operation is allowed or not according to the
Policy. It is the SELinux-aware application or Object
Manager responsibility to enforce the decision.
Security Context An SELinux Security Context is a variable length string that
consists of the following mandatory components
user:role:type and an optional [:range] component.
Generally abbreviated to 'context', and sometimes called a
'label'.
Security SIDs are unique opaque integer values mapped by the kernel
Identifier (SID) Security Server and userspace AVC that represent a Security
Context.
The SIDs generated by the kernel Security Server are u32
values that are passed via the Linux Security Module hooks
to/from the kernel Object Managers.
Type SELinux makes use of a specific style of type enforcement
Enforcement (TE) to enforce Mandatory Access Control. This is where all
subjects and objects have a type identifier associated to them
that can then be used to enforce rules laid down by Policy.

0.6 Index
0. NOTEBOOK INFORMATION..............................................................................2
0.1 COPYRIGHT INFORMATION..........................................................................................2
0.2 REVISION HISTORY................................................................................................... 2
0.3 ACKNOWLEDGEMENTS................................................................................................2
0.4 ABBREVIATIONS........................................................................................................2
0.5 TERMINOLOGY..........................................................................................................3
0.6 INDEX..................................................................................................................... 5
1. THE SELINUX NOTEBOOK.............................................................................. 15
1.1 INTRODUCTION........................................................................................................15
1.2 NOTEBOOK OVERVIEW............................................................................................ 15
1.2.1 Notebook Source Overview.........................................................................16
2. SELINUX OVERVIEW........................................................................................ 17
2.1 INTRODUCTION........................................................................................................17
2.1.1 Is SELinux useful.........................................................................................17
2.2 CORE SELINUX COMPONENTS..................................................................................19
2.3 MANDATORY ACCESS CONTROL (MAC)...................................................................22

Page 5
The SELinux Notebook

2.4 SELINUX USERS....................................................................................................24
2.5 ROLE-BASED ACCESS CONTROL (RBAC)................................................................ 24
2.6 TYPE ENFORCEMENT (TE).......................................................................................25
2.6.1 Constraints..................................................................................................26
2.6.2 Bounds.........................................................................................................26
2.7 SECURITY CONTEXT................................................................................................ 27
2.8 SUBJECTS...............................................................................................................29
2.9 OBJECTS................................................................................................................29
2.9.1 Object Classes and Permissions................................................................. 29
2.9.2 Allowing a Process Access to Resources....................................................30
2.9.3 Labeling Objects......................................................................................... 31
2.9.3.1 Labeling Extended Attribute Filesystems............................................ 32
2.9.3.1.1 Copying and Moving Files............................................................32
2.9.3.2 Labeling Subjects................................................................................. 33
2.9.4 Object Reuse............................................................................................... 34
2.10 COMPUTING SECURITY CONTEXTS ...........................................................................34
2.10.1 Security Context Computation for Kernel Objects................................... 34
2.10.1.1 Process................................................................................................35
2.10.1.2 Files.................................................................................................... 35
2.10.1.3 File Descriptors.................................................................................. 36
2.10.1.4 Filesystems.........................................................................................36
2.10.1.5 Network File System (nfsv4)............................................................. 37
2.10.1.6 INET Sockets..................................................................................... 37
2.10.1.7 IPC......................................................................................................37
2.10.1.8 Message Queues.................................................................................37
2.10.1.9 Semaphores........................................................................................ 38
2.10.1.10 Shared Memory................................................................................38
2.10.1.11 Keys..................................................................................................38
2.10.2 Using libselinux Functions....................................................................... 38
2.10.2.1 avc_compute_create and security_compute_create........................... 38
2.10.2.2 avc_compute_member and security_compute_member.................... 40
2.10.2.3 security_compute_relabel ..................................................................41
2.11 COMPUTING ACCESS DECISIONS..............................................................................42
2.12 DOMAIN AND OBJECT TRANSITIONS.........................................................................43
2.12.1 Domain Transition....................................................................................43
2.12.1.1 Type Enforcement Rules....................................................................45
2.12.2 Object Transition...................................................................................... 47
2.13 MULTI-LEVEL SECURITY AND MULTI-CATEGORY SECURITY.......................................48
2.13.1 Security Levels..........................................................................................49
2.13.1.1 MLS / MCS Range Format................................................................ 50
2.13.1.2 Translating Levels..............................................................................51
2.13.2 Managing Security Levels via Dominance Rules......................................51
2.13.3 MLS Labeled Network and Database Support..........................................53
2.13.4 Common Criteria Certification.................................................................53
2.14 TYPES OF SELINUX POLICY ...................................................................................54
2.14.1 Example Policy......................................................................................... 54
2.14.2 Reference Policy....................................................................................... 54
2.14.3 Policy Functionality Based on Name or Type.......................................... 55
2.14.4 Custom Policy........................................................................................... 55
2.14.5 Monolithic Policy......................................................................................55

Page 6
The SELinux Notebook

2.14.6 Loadable Module Policy...........................................................................56
2.14.6.1 Optional Policy...................................................................................56
2.14.7 Conditional Policy.................................................................................... 56
2.14.8 Binary Policy............................................................................................ 57
2.14.9 Policy Versions......................................................................................... 57
2.15 SELINUX PERMISSIVE AND ENFORCING MODES........................................................59
2.16 AUDITING SELINUX EVENTS................................................................................. 59
2.16.1 AVC Audit Events......................................................................................60
2.16.2 General SELinux Audit Events..................................................................63
2.17 POLYINSTANTIATION SUPPORT.................................................................................65
2.17.1 Polyinstantiated Objects .......................................................................... 65
2.17.2 Polyinstantiation support in PAM............................................................ 65
2.17.2.1 namespace.conf Configuration File....................................................66
2.17.2.2 Example Configurations.....................................................................67
2.17.3 Polyinstantiation support in X-Windows.................................................. 68
2.17.4 Polyinstantiation support in the Reference Policy....................................68
2.18 PAM LOGIN PROCESS..........................................................................................68
2.19 LINUX SECURITY MODULE AND SELINUX............................................................... 70
2.19.1 The LSM Module.......................................................................................71
2.19.2 The SELinux Module.................................................................................73
2.19.2.1 Fork System Call Walk-thorough...................................................... 74
2.19.2.2 Process Transition Walk-thorough.....................................................76
2.19.2.3 SELinux Filesystem........................................................................... 81
2.20 LIBSELINUX LIBRARY.............................................................................................86
2.21 SELINUX NETWORKING SUPPORT........................................................................... 88
2.21.1 SECMARK.................................................................................................89
2.21.2 NetLabel - Fallback Peer Labeling...........................................................91
2.21.3 NetLabel - CIPSO..................................................................................... 92
2.21.4 Labeled IPSec........................................................................................... 92
2.21.4.1 Configuration Examples.....................................................................94
2.22 SELINUX VIRTUAL MACHINE SUPPORT...................................................................96
2.22.1 KVM / QEMU Support..............................................................................96
2.22.2 libvirt Support...........................................................................................97
2.22.3 VM Image Labeling...................................................................................97
2.22.3.1 Dynamic Labeling..............................................................................98
2.22.3.2 Shared Image......................................................................................98
2.22.3.3 Static Labeling..................................................................................101
2.22.4 Xen Support.............................................................................................103
2.23 SANDBOX SERVICES............................................................................................ 104
2.24 X-WINDOWS SELINUX SUPPORT......................................................................... 106
2.24.1 Infrastructure Overview..........................................................................106
2.24.1.1 Polyinstantiation...............................................................................108
2.24.2 Configuration Information......................................................................109
2.24.2.1 Enable/Disable the OM from Policy Decisions............................... 109
2.24.2.2 Determine OM X-extension Opcode................................................109
2.24.2.3 Configure OM Enforcement Mode.................................................. 109
2.24.2.4 The x_contexts File.......................................................................... 110
2.24.3 SELinux Extension Functions................................................................. 112
2.25 SE-POSTGRESQL..............................................................................................114
2.25.1 sepgsql Overview....................................................................................114

Page 7
The SELinux Notebook

2.25.2 Installing SE-PostgreSQL.......................................................................115
2.25.3 SECURITY LABEL SQL Command........................................................116
2.25.4 Additional SQL Functions.......................................................................116
2.25.5 Additional postgresql.conf Entries..........................................................117
2.25.6 Logging Security Events......................................................................... 118
2.25.7 Internal Tables........................................................................................118
2.26 APACHE SELINUX SUPPORT................................................................................ 119
2.26.1 mod_selinux Overview...........................................................................119
2.26.2 Bounds Overview....................................................................................120
2.26.2.1 Notebook Examples......................................................................... 121
3. SELINUX CONFIGURATION FILES..............................................................122
3.1 INTRODUCTION......................................................................................................122
3.1.1 Policy Store Migration..............................................................................122
3.1.1.1 The priority Option.............................................................................123
3.1.1.2 Converting policy packages to CIL....................................................124
3.2 GLOBAL CONFIGURATION FILES..............................................................................124
3.2.1 /etc/selinux/config File..............................................................................125
3.2.2 /etc/selinux/semanage.conf File................................................................126
3.2.3 /etc/selinux/restorecond.conf and restorecond-user.conf Files................131
3.2.4 /etc/selinux/newrole_pam.conf..................................................................131
3.2.5 /etc/sestatus.conf File................................................................................132
3.2.6 /etc/security/sepermit.conf File.................................................................132
3.3 POLICY STORE CONFIGURATION FILES..................................................................... 133
3.3.1 modules/ Files........................................................................................... 134
3.3.2 modules/active/base.pp File......................................................................134
3.3.3 modules/active/base.linked File................................................................134
3.3.4 modules/active/commit_num File............................................................. 134
3.3.5 modules/active/file_contexts.template File...............................................134
3.3.6 modules/active/file_contexts File..............................................................138
3.3.7 modules/active/homedir_template File.....................................................139
3.3.8 modules/active/file_contexts.homedirs File..............................................139
3.3.9 modules/active/netfilter_contexts & netfilter.local File........................... 140
3.3.10 modules/active/policy.kern File..............................................................140
3.3.11 modules/active/seusers.final and seusers Files.......................................141
3.3.12 modules/active/users_extra, users_extra.local and users.local Files.....143
3.3.13 modules/active/booleans.local File.........................................................145
3.3.14 modules/active/file_contexts.local File...................................................145
3.3.15 modules/active/interfaces.local File.......................................................146
3.3.16 modules/active/nodes.local File..............................................................146
3.3.17 modules/active/ports.local File...............................................................146
3.3.18 modules/active/preserve_tunables File...................................................146
3.3.19 modules/active/disable_dontaudit File................................................... 146
3.3.20 modules/active/modules Directory Contents.......................................... 146
3.4 POLICY CONFIGURATION FILES............................................................................... 147
3.4.1 seusers File .............................................................................................. 148
3.4.2 booleans and booleans.local File.............................................................148
3.4.3 booleans.subs_dist File.............................................................................149
3.4.4 setrans.conf File........................................................................................150
3.4.5 secolor.conf File....................................................................................... 152

Page 8
The SELinux Notebook

3.4.6 policy/policy.<ver> File...........................................................................153
3.4.7 contexts/customizable_types File..............................................................154
3.4.8 contexts/default_contexts File ..................................................................154
3.4.9 contexts/dbus_contexts File......................................................................156
3.4.10 contexts/default_type File....................................................................... 156
3.4.11 contexts/failsafe_context File..................................................................157
3.4.12 contexts/initrc_context File.....................................................................158
3.4.13 contexts/lxc_contexts File.......................................................................158
3.4.14 contexts/netfilter_contexts File...............................................................159
3.4.15 contexts/removable_context File............................................................ 159
3.4.16 contexts/securetty_types File.................................................................. 160
3.4.17 contexts/sepgsql_contexts File................................................................160
3.4.18 contexts/systemd_contexts File ..............................................................161
3.4.19 contexts/userhelper_context File ........................................................... 162
3.4.20 contexts/virtual_domain_context File.....................................................162
3.4.21 contexts/virtual_image_context File.......................................................163
3.4.22 contexts/x_contexts File .........................................................................163
3.4.23 contexts/files/file_contexts File...............................................................165
3.4.24 contexts/files/file_contexts.local File......................................................165
3.4.25 contexts/files/file_contexts.homedirs File...............................................166
3.4.26 contexts/files/file_contexts.subs and file_contexts.subs_dist File...........166
3.4.27 contexts/files/media File ........................................................................ 167
3.4.28 contexts/users/[seuser_id] File...............................................................167
3.4.29 logins/<linuxuser_id> File.....................................................................168
3.4.30 users/local.users File.............................................................................. 169
4. SELINUX POLICY LANGUAGES................................................................... 170
4.1 INTRODUCTION......................................................................................................170
4.1.1 CIL Overview............................................................................................170
4.2 KERNEL POLICY LANGUAGE...................................................................................172
4.2.1 Policy Source Files...................................................................................172
4.2.2 Conditional, Optional and Require Statement Rules................................175
4.2.3 MLS Statements and Optional MLS Components.....................................175
4.2.4 General Statement Information.................................................................175
4.2.5 Section Contents........................................................................................178
4.3 POLICY CONFIGURATION STATEMENTS..................................................................... 179
4.3.1 policycap ..................................................................................................179
4.4 DEFAULT OBJECT RULES....................................................................................... 180
4.4.1 default_user ..............................................................................................180
4.4.2 default_role ..............................................................................................181
4.4.3 default_type ..............................................................................................182
4.4.4 default_range ........................................................................................... 183
4.5 USER STATEMENTS............................................................................................... 184
4.5.1 user ...........................................................................................................184
4.6 ROLE STATEMENTS............................................................................................... 186
4.6.1 role ...........................................................................................................186
4.6.2 attribute_role ........................................................................................... 187
4.6.3 roleattribute ............................................................................................. 188
4.6.4 allow .........................................................................................................189
4.6.5 role_transition ..........................................................................................189

Page 9
The SELinux Notebook

4.6.6 dominance ................................................................................................191
4.7 TYPE STATEMENTS................................................................................................192
4.7.1 type ...........................................................................................................192
4.7.2 attribute ....................................................................................................194
4.7.3 typeattribute ............................................................................................. 194
4.7.4 typealias ................................................................................................... 195
4.7.5 permissive ................................................................................................ 196
4.7.6 type_transition ......................................................................................... 197
4.7.7 type_change ............................................................................................. 200
4.7.8 type_member ............................................................................................201
4.8 BOUNDS RULES....................................................................................................201
4.8.1 typebounds ............................................................................................... 202
4.9 ACCESS VECTOR RULES........................................................................................ 203
4.9.1 allow .........................................................................................................204
4.9.2 dontaudit .................................................................................................. 205
4.9.3 auditallow ................................................................................................ 205
4.9.4 neverallow ................................................................................................205
4.10 OBJECT CLASS AND PERMISSION STATEMENTS........................................................ 206
4.10.1 class ........................................................................................................206
4.10.2 Associating Permissions to a Class........................................................ 207
4.10.3 common ..................................................................................................207
4.10.4 class ........................................................................................................207
4.11 CONDITIONAL POLICY STATEMENTS.......................................................................209
4.11.1 bool ........................................................................................................ 209
4.11.2 if ............................................................................................................. 210
4.12 CONSTRAINT STATEMENTS................................................................................... 212
4.12.1 constrain ................................................................................................ 212
4.12.2 validatetrans .......................................................................................... 215
4.12.3 mlsconstrain ...........................................................................................216
4.12.4 mlsvalidatetrans .....................................................................................217
4.13 MLS STATEMENTS.............................................................................................219
4.13.1 sensitivity ................................................................................................220
4.13.2 dominance ..............................................................................................221
4.13.3 category ..................................................................................................222
4.13.4 level ........................................................................................................222
4.13.5 range_transition .....................................................................................223
4.13.5.1 MLS range Definition...................................................................... 224
4.13.6 mlsconstrain ...........................................................................................225
4.13.7 mlsvalidatetrans .....................................................................................225
4.14 SECURITY ID (SID) STATEMENT..........................................................................225
4.14.1 sid ...........................................................................................................225
4.14.2 sid context .............................................................................................. 226
4.15 FILE SYSTEM LABELING STATEMENTS....................................................................227
4.15.1 fs_use_xattr ............................................................................................227
4.15.2 fs_use_task ............................................................................................. 228
4.15.3 fs_use_trans ........................................................................................... 228
4.15.4 genfscon ................................................................................................. 229
4.16 NETWORK LABELING STATEMENTS........................................................................230
4.16.1 IP Address Formats................................................................................ 231
4.16.1.1 IPv4 Address Format........................................................................231

Page 10
The SELinux Notebook

4.16.1.2 IPv6 Address Formats...................................................................... 231
4.16.2 netifcon ...................................................................................................231
4.16.3 nodecon ..................................................................................................232
4.16.4 portcon ...................................................................................................234
4.17 MODULAR POLICY SUPPORT STATEMENTS..............................................................235
4.17.1 module ....................................................................................................235
4.17.2 require ....................................................................................................235
4.17.3 optional .................................................................................................. 237
4.18 XEN STATEMENTS...............................................................................................238
4.18.1 iomemcon ............................................................................................... 238
4.18.2 ioportcon ................................................................................................239
4.18.3 pcidevicecon ...........................................................................................240
4.18.4 pirqcon ...................................................................................................240
5. THE REFERENCE POLICY............................................................................. 242
5.1 INTRODUCTION......................................................................................................242
5.2 REFERENCE POLICY OVERVIEW...............................................................................242
5.2.1 Distributing Policies................................................................................. 244
5.2.2 Policy Functionality..................................................................................245
5.2.3 Reference Policy Module Files.................................................................245
5.2.4 Reference Policy Documentation..............................................................248
5.3 REFERENCE POLICY SOURCE.................................................................................. 249
5.3.1 Source Layout........................................................................................... 249
5.3.2 Reference Policy Files and Directories....................................................249
5.3.3 Source Configuration Files.......................................................................252
5.3.3.1 Reference Policy Build Options - build.conf..................................... 252
5.3.3.2 Reference Policy Build Options - policy/modules.conf.....................253
5.3.3.2.1 Building the modules.conf File................................................... 256
5.3.4 Source Installation and Build Make Options............................................256
5.3.5 Booleans, Global Booleans and Tunable Booleans..................................258
5.3.6 Modular Policy Build Structure................................................................259
5.3.7 Creating Additional Layers.......................................................................261
5.4 INSTALLING AND BUILDING THE REFERENCE POLICY SOURCE......................................261
5.4.1 Building Standard Reference Policy.........................................................261
5.4.2 Building the Fedora Policy.......................................................................263
5.5 REFERENCE POLICY HEADERS.................................................................................266
5.5.1 Building and Installing the Header Files..................................................266
5.5.2 Using the Reference Policy Headers........................................................ 267
5.5.3 Using Fedora Supplied Headers...............................................................268
5.6 MIGRATING COMPILED MODULES TO CIL............................................................... 268
5.7 REFERENCE POLICY SUPPORT MACROS....................................................................268
5.7.1 Loadable Policy Macros...........................................................................270
5.7.1.1 policy_module Macro........................................................................ 270
5.7.1.2 gen_require Macro............................................................................. 271
5.7.1.3 optional_policy Macro....................................................................... 272
5.7.1.4 gen_tunable Macro.............................................................................273
5.7.1.5 tunable_policy Macro.........................................................................274
5.7.1.6 interface Macro.................................................................................. 275
5.7.1.7 template Macro...................................................................................277
5.7.2 Miscellaneous Macros..............................................................................279

Page 11
The SELinux Notebook

5.7.2.1 gen_context Macro.............................................................................279
5.7.2.2 gen_user Macro..................................................................................281
5.7.2.3 gen_bool Macro..................................................................................282
5.7.3 MLS and MCS Macros..............................................................................283
5.7.3.1 gen_cats Macro.................................................................................. 283
5.7.3.2 gen_sens Macro..................................................................................284
5.7.3.3 gen_levels Macro............................................................................... 285
5.7.3.4 System High/Low Parameters............................................................286
5.7.4 ifdef / ifndef Parameters............................................................................286
5.7.4.1 hide_broken_symptoms .................................................................... 286
5.7.4.2 enable_mls and enable_mcs .............................................................. 287
5.7.4.3 enable_ubac .......................................................................................287
5.7.4.4 direct_sysadm_daemon ..................................................................... 288
5.8 MODULE EXPANSION PROCESS............................................................................... 288
6. IMPLEMENTING SELINUX-AWARE APPLICATIONS.............................290
6.1 INTRODUCTION......................................................................................................290
6.1.1 Implementing SELinux-aware Applications............................................. 290
6.1.2 Implementing Object Managers................................................................292
6.1.3 Reference Policy Changes........................................................................ 293
6.1.4 Adding New Object Classes and Permissions.......................................... 294
7. SECURITY ENHANCEMENTS FOR ANDROID.......................................... 296
7.1 INTRODUCTION......................................................................................................296
7.1.1 Terminology..............................................................................................296
7.1.2 Useful Links.............................................................................................. 297
7.1.3 Document Sections....................................................................................297
7.2 SE FOR ANDROID PROJECT UPDATES...................................................................... 298
7.3 KERNEL LSM / SELINUX SUPPORT....................................................................... 301
7.4 SE FOR ANDROID CLASSES & PERMISSIONS.............................................................302
7.5 SELINUX COMMANDS...........................................................................................304
7.6 SELINUX PUBLIC METHODS.................................................................................. 305
7.7 ANDROID INIT LANGUAGE SELINUX EXTENSIONS.....................................................307
7.8 DEVICE POLICY FILE LOCATIONS............................................................................308
7.9 BUILDING THE POLICY...........................................................................................309
7.9.1 SELinux MAC Policy Files....................................................................... 309
7.9.1.1 Policy Build Files...............................................................................309
7.9.1.2 Policy Configuration Files................................................................. 310
7.9.2 Install-time MMAC Policy File.................................................................312
7.9.3 Device Specific Policy...............................................................................312
7.9.3.1 Managing Device Policy File.............................................................313
7.9.4 Build Tools................................................................................................315
7.9.5 Miscellaneous Information....................................................................... 316
7.9.5.1 SELinux Policy Versions................................................................... 316
7.9.5.2 SELinux Policy Booleans...................................................................316
7.9.5.3 Setting Permissive / Enforcing Mode.................................................316
7.9.5.4 Checking File Labels..........................................................................317
7.10 UPDATING POLICY FILES..................................................................................... 317
7.10.1.1 Local Policy Update.........................................................................317
7.11 LOGGING AND AUDITING..................................................................................... 318

Page 12
The SELinux Notebook

7.12 POLICY FILE CONFIGURATION DETAIL................................................................... 319
7.12.1 SELinux MAC Configuration Files.........................................................319
7.12.1.1 seapp_contexts File.......................................................................... 319
7.12.1.1.1 Default Entries...........................................................................319
7.12.1.1.2 Entry Definitions.......................................................................320
7.12.1.1.3 Computing a Context................................................................ 321
7.12.1.2 property_contexts File......................................................................326
7.12.1.3 service_contexts File........................................................................327
7.12.2 Install-time MMAC Configuration File.................................................. 328
7.12.2.1 Policy Rules......................................................................................329
7.12.3 EOps MMAC Configuration File............................................................330
7.12.4 Intent Firewall MMAC Configuration File.............................................331
7.13 POLICY BUILD TOOLS......................................................................................... 332
7.13.1 checkfc.....................................................................................................332
7.13.2 checkseapp.............................................................................................. 333
7.13.3 insertkeys.py............................................................................................333
7.13.3.1 keys.conf File................................................................................... 334
7.13.4 Build Bundle Tools..................................................................................335
7.13.4.1 buildsebundle................................................................................... 335
7.13.4.1.1 Using an Intent Example...........................................................336
7.13.4.2 buildeopbundle.................................................................................337
7.13.4.2.1 Eops Example............................................................................338
7.13.4.3 buildifwbundle................................................................................. 339
7.13.4.3.1 IFW Example............................................................................ 339
7.13.5 post_process_mac_perms.......................................................................340
7.13.6 sepolicy_check........................................................................................ 341
7.13.7 sepolicy-analyze......................................................................................341
7.13.7.1 Type Equivalence.............................................................................341
7.13.7.2 Type Difference................................................................................342
7.13.7.3 Duplicate Allow Rules..................................................................... 342
7.13.8 setool.......................................................................................................343
7.14 SELINUX-NETWORK.SH CONFIGURATION.................................................................. 344
7.15 UID TO USERNAME UTILITY..................................................................................345
8. APPENDIX A - OBJECT CLASSES AND PERMISSIONS...........................347
8.1 INTRODUCTION......................................................................................................347
8.2 DEFINING OBJECT CLASSES AND PERMISSIONS.......................................................... 347
8.3 COMMON PERMISSIONS..........................................................................................348
8.3.1 Common File Permissions........................................................................ 348
8.3.2 Common Socket Permissions.................................................................... 348
8.3.3 Common IPC Permissions........................................................................349
8.3.4 Common Database Permissions............................................................... 349
8.3.5 Common X_Device Permissions...............................................................350
8.4 FILE OBJECT CLASSES...........................................................................................350
8.5 NETWORK OBJECT CLASSES...................................................................................353
8.5.1 IPSec Network Object Classes..................................................................355
8.5.2 Netlink Object Classes.............................................................................. 356
8.5.3 Miscellaneous Network Object Classes....................................................358
8.6 IPC OBJECT CLASSES...........................................................................................359
8.7 PROCESS OBJECT CLASS........................................................................................359

Page 13
The SELinux Notebook

8.8 SECURITY OBJECT CLASS.......................................................................................360
8.9 SYSTEM OPERATION OBJECT CLASS........................................................................ 361
8.10 KERNEL SERVICE OBJECT CLASS.......................................................................... 361
8.11 CAPABILITY OBJECT CLASSES...............................................................................362
8.12 X WINDOWS OBJECT CLASSES.............................................................................363
8.13 DATABASE OBJECT CLASSES................................................................................ 368
8.14 MISCELLANEOUS OBJECT CLASSES........................................................................370
9. APPENDIX B - LIBSELINUX LIBRARY FUNCTIONS................................373
10. APPENDIX C - SELINUX COMMANDS.......................................................389
11. APPENDIX D - DOCUMENT REFERENCES.............................................. 390
12. APPENDIX E - POLICY VALIDATION EXAMPLE...................................391
13. APPENDIX F - GNU FREE DOCUMENTATION LICENSE.....................393

Page 14
The SELinux Notebook

1. The SELinux Notebook

1.1 Introduction
This Notebook should help with explaining:
a) SELinux and its purpose in life.
b) The LSM / SELinux architecture, its supporting services and how they are
implemented within GNU / Linux.
c) SELinux Networking, Virtual Machine, X-Windows, PostgreSQL and
Apache/SELinux-Plus SELinux-aware capabilities.
d) The core SELinux kernel policy language and how basic policy modules can
be constructed for instructional purposes.
e) An introduction to the new Common Intermediate Language (CIL)
implementation.
f) The core SELinux policy management tools with examples of usage.
g) The Reference Policy architecture, its supporting services and how it is
implemented.
h) The integration of SELinux within Android - SE for Android.
Note that this Notebook will not explain how the SELinux implementations are
managed for each GNU / Linux distribution as they have their own supporting
documentation.
While the majority of this Notebook is based on Fedora 20, all additional
developments as seen on the SELinux mail list (selinux@tycho.nsa.gov) up to
September '14 have been added.

1.2 Notebook Overview
This volume has the following major sections:
SELinux Overview - Gives a description of SELinux and its major components
to provide Mandatory Access Control services for GNU / Linux. Hopefully it will
show how all the SELinux components link together and how SELinux-aware
applications / object manager have been implemented (such as Networking, X-
Windows, PostgreSQL and virtual machines).
SELinux Configuration Files - Describes all known SELinux configuration files
with samples. Also lists any specific SELinux commands or libselinux APIs
used by them.
SELinux Policy Language - Gives a brief description of each policy language
statement, with supporting examples taken from the Reference Policy source. Also
an introduction to the new CIL language (Common Intermediate Language).
The Reference Policy - Describes the Reference Policy and its supporting
macros.
SE for Android - An overview of the SELinux services used to support Android.

Page 15
The SELinux Notebook

Object Classes and Permissions - Describes the SELinux object classes and
permissions.
libselinux Functions - Describes the libselinux library functions.

1.2.1 Notebook Source Overview
To demonstrate some of the SELinux capabilities a supporting Notebook source
tarball is available (notebook-source-4.0.tar.gz). The tarball contains
directories and READMEs covering the following:
Building a Basic Policy - Describes how to build monolithic, base and loadable
policy modules using core policy language statements and SELinux commands.
Note that these policies should not to be used in a live environment, they are
examples to show simple policy construction. These can be extended with
additional modules in kernel policy language and CIL.
Example libselinux applications - This contains over 100 samples that use
the libselinux 2.2.1-6 functions. To save typing long context strings it makes
use of a configuration file. There are also some supporting policy modules for the
F-20 targeted policy to show how the functions work.
Example Android emulator device - This replaces the kernel policy language
version with a CIL policy using namespaces. This is built using Android 4.4
AOSP master and will show processes as u:r:kernel.process:s0,
u:r:untrusted_app.process:s0:c512,c768. and files as
u:r:bluetooth.data_file:s0,
u:r:app.data_file:s0:c512,c768 etc..

Page 16
The SELinux Notebook

2. SELinux Overview

2.1 Introduction
SELinux is the primary Mandatory Access Control (MAC) mechanism built into a
number of GNU / Linux distributions. SELinux originally started as the Flux
Advanced Security Kernel (FLASK) development by the Utah university Flux team
and the US Department of Defence. The development was enhanced by the NSA and
released as open source software. The history of SELinux can be found at the Flux
and NSA websites.
Each of the sections that follow will describe a component of SELinux, and hopefully
they are is some form of logical order.
Note: When SELinux is installed, there are three well defined directory locations
referenced. Two of these will change with the old and new locations as follows:

Description Old Location New Location
The SELinux filesystem that /selinux /sys/fs/selinux
interfaces with the kernel
based security server.
The new location has been
available since Fedora 17.
The SELinux configuration /etc/selinux No change
directory that holds the sub-
system configuration files and
policies.
The SELinux policy store that /etc/selinux/ /var/lib/selinux/
holds policy modules and <SELINUXTYPE>/module <SELINUXTYPE>/module
configuration details (see
https://github.com/SELinuxPro
ject/selinux/wiki/Policy-Store-
Migration and Policy Store
Migration).

2.1.1 Is SELinux useful
There are many views on the usefulness of SELinux on Linux based systems, this
section gives a brief view of what SELinux is good at and what it is not (because its
not designed to do it).
SELinux is not just for military or high security systems where Multi-Level Security
(MLS) is required (for functionality such as 'no read up' and 'no write down'), as using
the 'type enforcement' (TE) functionality applications can be confined (or contained)
within domains and limited to the mimimum privileges required to do their job, so in
a 'nutshell':
1. If SELinux is enabled, the policy defines what access to resources and
operations on them (e.g. read, write) are allowed (i.e. SELinux stops all access

Page 17
The SELinux Notebook

unless allowed by policy). This is why SELinux is called a 'mandatory access
control' (MAC) system.
2. The policy design, implementation and testing against a defined security
policy or requirements is important, otherwise there could be 'a false sense of
security'.
3. SELinux can confine an application within its own 'domain' and allow it to
have the minimum priviledges required to do its job. Should the application
require access to networks or other applications (or their data), then (as part of
the security policy design), this access would need to be granted (so at least it
is known what interactions are allowed and what are not - a good security
goal).
4. Should an application 'do something' it is not allowed by policy (intentional or
otherwise), then SELinux would stop these actions.
5. Should an application 'do something' it is allowed by policy, then SELinux
may contain any damage that maybe done intentional or otherwise. For
example if an application is allowed to delete all of its data files or database
entries and the bug, virus or malicious user gains these priviledges then it
would be able to do the same, however the good news is that if the policy
'confined' the application and data, all your other data should still be there.
6. User login sessions can be confined to their own domains. This allows clients
they run to be given only the priviledges they need (e.g. admin users, sales
staff users, HR staff users etc.). This again will confine/limit any damage or
leakage of data.
7. Some applications (X-Windows for example) are difficult to confine as they
are generally designed to have total access to all resources. SELinux can
generally overcome these issues by providing sandboxing services.
8. SELinux will not stop memory leaks or buffer over-runs (because its not
designed to do this), however it may contain the damage that may be done.
9. SELinux will not stop all viruses/malware getting into the system (as there are
many ways they could be introduced (including by legitimate users), however
it should limit the damage or leaks they cause.
10. SELinux will not stop kernel vulnerabilities, however it may limit their
effects.
11. It is easy to add new rules to an SELinux policy using tools such as
audit2allow(1) if a user has the relevant permissions, however be aware
that this may start opening holes, so check what rules are really required.
12. Finally, SELinux cannot stop anything allowed by the security policy, so good
design is important.
The following maybe useful in providing a practical view of SELinux:
1. A discussion regarding Apache servers and SELinux that may look negative at
first but highlights the containment points above. This is the initial study:
http://blog.ptsecurity.com/2012/08/selinux-in-practice-dvwa-test.html, and
this is a response to the study: http://danwalsh.livejournal.com/56760.html.

Page 18
The SELinux Notebook

However with careful design and known security goals the SELinux Apache /
SELinux Plus services could be used to build a more secure web service (also
see http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus).
2. SELinux services have been added to Andriod, producing SE for Android. The
presentation "The Case for Security Enhanced (SE)Android" [20] gives use-
cases and types of Android exploits that SELinux could have overcome. The
presentation and others are available at:
http://seandroid.bitbucket.org/PapersandPresentation.html#3

2.2 Core SELinux Components
Figure 2.1 shows a high level diagram of the SELinux core components that manage
enforcement of the policy and comprise of the following:
1. A subject that must be present to cause an action to be taken by an object
(such as read a file as information only flows when a subject is involved).
2. An Object Manager that knows the actions required of the particular resource
(such as a file) and can enforce those actions (i.e. allow it to write to a file if
permitted by the policy).
3. A Security Server that makes decisions regarding the subjects rights to
perform the requested action on the object, based on the security policy rules.
4. A Security Policy that describes the rules using the SELinux policy language.
5. An Access Vector Cache (AVC) that improves system performance by
caching security server decisions.

Subject
Requests access.

Security Server
Object Manager Access Vector
Q u e ry If answe r not
Makes decisions
Knows what objects it pe rm issions Cache based on the
in cache , ask
manages, so queries if the Stores decisions se cu rity se rve r security policy.
action is allowed and then made by the
enforces the security Security Server. Add answe r
Security Policy
Answe r from
policy decision. to cach e
C ach e

Figure 2.1: High Level Core SELinux Components - Decisions by the Security
Server are cached in the AVC to enhance performance of future requests. Note that it
is the kernel and userspace Object Managers that enforce the policy.

Page 19
The SELinux Notebook

checkmodule semodule_package semodule
Reference Policy l
Compiles the policy Package the policy modules Manages the policy store by installing, loading, updating
Headers i
source into with optional configuration and removing modules and their supporting configuration
b SELinux Policy
Or intermediate format. files. files. Also builds the binary policy file.
s
Reference Policy e ---- Policy Store -----
Policy Object Optional
Policy Files p /var/lib/selinux/<SELINUXTYPE>/
Source Files Configuration
o modules:
Files
Or semanage l semanage.read.LOCK
Linux commands semanage.trans.LOCK
Custom Policy SELinux-aware Applications Configures elements of / modules/active:
Linux commands modified to base.pp
Source support SELinux, such as ls,
the policy such as login, commit_num
Userspace Object Managers users, and ports. l file_contexts
ps, pam. file_contexts.homedirs
i file_contexts.template
homedir_template
Acce ss T hese may use the b netfilter_contexts
Ve ctor policycoreutils s seusers.final
libselinux AVC users_extra
C ach e SElinux utilities, such as secon, e
services or build their
audit2allow and system- T hese
T hese libraries
libraries m modules/active/modules:
amavis.pp
libselinux own.
config-selinux. are linked
linked into
into a amtu.pp
are ...
SELinux n zabbix.pp
File Labeling Utilities SELinux aware
aware
applications asas a
applications
Utilities that initialise or update g ---- Active Policy ----
required.
required. /etc/selinux/<SELINUXTYPE>/
file security contexts, such as e
setfiles and restorecon. setrans.conf

S ELin ux Use r policy:
policy.29
S pace Se rvice s
libselinux (supports security policy, xattr file attribute and process APIs) contexts:
dbus_contexts
netfilter_contexts

Audit Log Audit /proc/self/task/ contexts/files:
file_contexts
Services <tid>/attr/<attr> /selinux or /sys/fs/selinux (selinuxfs) file_contexts.homedirs
-----------------------
L
Labeled File S
SELinux Configuration Files
Systems M SELinux /etc/selinux/config
Kernel /etc/selinux/semanage.conf
(xattr) H
Access
/etc/selinux/restorecond.conf
Linux Kernel o Services Security Loaded
/etc/sestatus

o Vector Cache
Network, USB etc. Services k Server Policy

Connectivity s

Figure 2.2: High Level SELinux Architecture - Showing the major supporting services

Page 20
The SELinux Notebook

Figure 2.2 shows a more complex diagram of kernel and userspace with a number of
supporting services that are used to manage the SELinux environment. This diagram
will be referenced a number of times to explain areas of SELinux, therefore starting
from the bottom:
a) In the current implementation of SELinux the security server is embedded in
the kernel with the policy being loaded from userspace via a series of
functions contained in the libselinux library (see SELinux Userspace
Libraries for details).
The object managers (OM) and access vector cache (AVC) can reside in:
kernel space - These object manages are for the kernel services such as
files, directory, socket, IPC etc. and are provided by hooks into the
SELinux sub-system via the Linux Security Module (LSM) framework
(shown as LSM Hooks in Figure 2.2) that is discussed in the LSM section.
The SELinux kernel AVC service is used to cache the security servers
response to the kernel based object managers thus speeding up access
decisions should the same request be asked in future.
userspace - These object managers are provided with the application or
service that requires support for MAC and are known as 'SELinux-aware'
applications or services. Examples of these are: X-Windows, D-bus
messaging (used by the Gnome desktop), PostgreSQL database, Name
Service Cache Daemon (nscd), and the GNU / Linux passwd command.
Generally, these OMs use the AVC services built into the SELinux library
(libselinux), however they could, if required supply their own AVC
or not use an AVC at all (see Implementing SELinux-aware Applications
for details).
b) The SELinux security policy (right hand side of Figure 2.2) and its supporting
configuration files are contained in the /etc/selinux directory. This
directory contains the main SELinux configuration file (config) that has the
name of the policy to be loaded (via the SELINUXTYPE entry) and the initial
enforcement mode1 of the policy at load time (via the SELINUX entry). The
/etc/selinux/<SELINUXTYPE> directories contain policies that can be
activated along with their configuration files (e.g.
'SELINUXTYPE=targeted' will have its policy and associated
configuration files located at /etc/selinux/targeted). All known
configuration files are shown in the SELinux Configuration Files section.
c) SELinux supports a 'modular policy', this means that a policy does not have to
be one large source policy but can be built from modules. A modular policy
consists of a base policy that contains the mandatory information (such as
object classes, permissions etc.), and zero or more policy modules where
generally each supports a particular application or service. These modules are
1
When SELinux is enabled, the policy can be running in 'permissive mode'
(SELINUX=permissive), where all accesses are allowed. The policy can also be run in
'enforcing mode' (SELINUX=enforcing), where any access that is not defined in the policy is
denied and an entry placed in the audit log. SELinux can also be disabled (at boot time only) by
setting SELINUX=disabled. There is also support for the permissive statement that allows
a domain to run in permissive mode while the others are still confined (instead of the all or nothing
set by SELINUX=).

Page 21
The SELinux Notebook

compiled, linked, and held in a 'policy store' where they can be built into a
binary format that is then loaded into the security server (in the diagram the
binary policy is located at
/etc/selinux/targeted/policy/policy.29). The types of policy
and their construction are covered in the Types of SELinux Policy section.
d) To be able to build the policy in the first place, policy source is required (top
left hand side of Figure 2.2). This can be supplied in three basic ways:
i) as source code written using the SELinux Policy Language. This is
how the simple policies have been written to support the examples in
this Notebook, however it is not recommended for large policy
developments such as the Reference Policy, although the smaller SE
for Android policy is written this way with some m4 macro support.
ii) using the Reference Policy that has high level macros to define policy
rules. This is the standard way policies are now built for SELinux
distributions such as Red Hat and Debian and is discussed in the
Reference Policy section. Note that SE for Android also uses high level
macros to define policy rules but the overall policy is much less
complex.
iii) using CIL (Common Intermediate Language). An overview can be
found at https://github.com/SELinuxProject/cil/wiki and the CIL
Overview section.
e) To be able to compile and link the policy source then load it into the security
server requires a number of tools (top of Figure 2.2).
f) To enable system administrators to manage policy, the SELinux environment
and label file systems, tools and modified GNU / Linux commands are used.
These are mentioned throughout the Notebook as needed and summarised in
Appendix C - SELinux Commands. Note that there are many other
applications to manage policy, however this Notebook only concentrates on
the core services.
g) To ensure security events are logged, GNU / Linux has an audit service that
captures policy violations. The Auditing SELinux Events section describes the
format of these security events.
h) SELinux supports network services that are described in the SELinux
Networking Support section.
The Linux Security Module and SELinux section goes into greater detail of the LSM /
SELinux modules with a walk through of a fork and exec process.

2.3 Mandatory Access Control (MAC)
Mandatory Access Control (MAC) is a type of access control in which the operating
system is used to constrain a user or process (the subject) from accessing or
performing an operation on an object (such as a file, disk, memory etc.).
Each of the subjects and objects have a set of security attributes that can be
interrogated by the operating system to check if the requested operation can be
performed or not. For SELinux the:

Page 22
The SELinux Notebook

• subjects are processes.
• objects are system resources such as files, sockets, etc.
• security attributes are the security context.
• Security Server within the Linux kernel authorizes access (or not) using the
security policy (or policy) that describes rules that must be enforced.
Note that the subject (and therefore the user) cannot decide to bypass the policy rules
being enforced by the MAC policy with SELinux enabled. Contrast this to standard
Linux Discretionary Access Control (DAC), which also governs the ability of subjects
to access objects, however it allows users to make policy decisions. The steps in the
decision making chain for DAC and MAC are shown in Figure 2.3.

User-space Process makes a System Call
User Space

Service System Call Kernel Space
Failed Denied Allowed
Check for Errors

DAC Checks

Allow or Deny Linux
LSM Hook Security SELinux Security
Access Module Server, AVC and
Policy

Return from System
Call

Figure 2.3: Processing a System Call - The DAC checks are carried out first, if they
pass then the Security Server is consulted for a decision.
SELinux supports two forms of MAC:
Type Enforcement - Where processes run in domains and the actions on objects
are controlled by the policy. This is the implementation used for general purpose
MAC within SELinux along with Role Based Access Control. The Type
Enforcement and Role Based Access Control sections covers these in more detail.
Multi-Level Security - This is an implementation based on the Bell-La Padula
(BLP) model, and used by organizations where different levels of access are
required so that restricted information is separated from classified information to
maintain confidentiality. This allows enforcement rules such as 'no write down'
and 'no read up' to be implemented in a policy by extending the security context to
include security levels. The MLS section covers this in more detail along with a
variant called Multi-Category Security (MCS).
The MLS / MCS services are now more generally used to maintain application
separation, for example SELinux enabled:

Page 23
The SELinux Notebook

• virtual machines use MCS categories to allow each VM to run within its
own domain to isolate VMs from each other (see the SELinux Virtual
Machine Support section).
• Android devices use dynamically generated MCS categories so that an app
running on behalf of one user cannot read or write files created by the
same app running on behalf of another user (see the Security
Enhancements for Android - Computing a Process Context section).

2.4 SELinux Users
Users in GNU / Linux are generally associated to human users (such as Alice and
Bob) or operator/system functions (such as admin), while this can be implemented in
SELinux, SELinux user names are generally groups or classes of user. For example
all the standard system users could be assigned an SELinux user name of user_u
and administration staff under staff_u.
There is one special SELinux user defined that must never be associated to a GNU /
Linux user as it a special identity for system processes and objects, this user is
system_u.
The SELinux user name is the first component of a 'security context' and by
convention SELinux user names end in '_u', however this is not enforced by any
SELinux service (i.e. it is only to identify the user component), although CIL with
namespaces does make identification of an SELinux user easier for example a 'user'
could be declared as unconfined.user.
It is possible to add constraints and bounds on SELinux users as discussed in the Type
Enforcement section.

2.5 Role-Based Access Control (RBAC)
To further control access to TE domains SELinux makes use of role-based access
control (RBAC). This feature allows SELinux users to be associated to one or more
roles, where each role is then associated to one or more domain types as shown in
Figure 2.4.
The SELinux role name is the second component of a 'security context' and by
convention SELinux roles end in '_r', however this is not enforced by any SELinux
service (i.e. it is only used to identify the role component), although CIL with
namespaces does make identification of a role easier for example a 'role' could be
declared as unconfined.role.
It is possible to add constraints and bounds on roles as discussed in the Type
Enforcement section.

Page 24
The SELinux Notebook

In the basic policy, the SELinux
SELinux User user unconfined_u is
unconfined_u associated to all GNU / Linux users
by default.

Role Role
unconfined_r message_filter_r

TE Domain TE Domain TE Domain TE Domain
unconfined_t ext_gateway_t int_gateway_t move_file_t
This domain includes most These domains are entered from the unconfined_t domain by
processes started at boot
performing domain transitions using SELinux facilities. This can be done
time and logins.
because unconfined_u is associated to roles unconfined_r and
message_filter_r within the policy.

Figure 2.4: Role Based Access Control - Showing how SELinux controls access via
user, role and domain type association.

2.6 Type Enforcement (TE)
SELinux makes use of a specific style of type enforcement 2 (TE) to enforce
mandatory access control. For SELinux it means that all subjects and objects have a
type identifier associated to them that can then be used to enforce rules laid down by
policy.
The SELinux type identifier is a simple variable-length string that is defined in the
policy and then associated to a security context. It is also used in the majority of
SELinux language statements and rules used to build a policy that will, when loaded
into the security server, enforce policy via the object managers.
Because the type identifier (or just 'type') is associated to all subjects and objects, it
can sometimes be difficult to distinguish what the type is actually associated with (it's
not helped by the fact that by convention, type identifiers end in '_t'). In the end it
comes down to understanding how they are allocated in the policy itself and how they
are used by SELinux services (although CIL policies with namespaces do help in that
a domain process 'type' could be declared as msg_filter.ext_gateway.process
with object types being any others (such as msg_filter.ext_gateway.exec).
Basically if the type identifier is used to reference a subject it is referring to a Linux
process or collection of processes (a domain or domain type). If the type identifier is
used to reference an object then it is specifying its object type (i.e. file type).
While SELinux refers to a subject as being an active process that is associated to a
domain type, the scope of an SELinux type enforcement domain can vary widely. For
example in the simple policy built in the basic-selinux-policy directory of
the source tarball, all the processes on the system run in the unconfined_t domain
(or for the CIL version in the unconfined.process domain), therefore every

2
There are various 'type enforcement' technologies.

Page 25
The SELinux Notebook

process is 'of type unconfined_t' (that means it can do whatever it likes within the
limits of the standard Linux DAC policy as all access is allowed by SELinux).
It is only when additional policy statements are added to the simple policy that areas
start to be confined. For example, an external gateway is run in its own isolated
domain (ext_gateway_t) that cannot be 'interfered' with by any of the
unconfined_t processes (except to run or transition the gateway process into its
own domain). This scenario is similar to the 'targeted' policy delivered as standard in
Red Hat Fedora where the majority of user space processes run under the
unconfined_t domain (although don't think the simple policies implemented in
source tarball are equivalent to the Reference Policy, they are not - so do not use them
as live implementations).
The SELinux type is the third component of a 'security context' and by convention
SELinux types end in '_t', however this is not enforced by any SELinux service (i.e.
it is only used to identify the type component), although as explained above CIL with
namespaces does make identification of types easier.

2.6.1 Constraints
It is possible to add constraints on users, roles, types and MLS ranges, for example
within a TE environment, the way that subjects are allowed to access an object is via a
TE allow rule, for example:

allow unconfined_t ext_gateway_t : process transition;

This states that a process running in the unconfined_t domain has permission to
transition a process to the ext_gateway_t domain. However it could be that the
policy writer wants to constrain this further and state that this can only happen if the
role of the source domain is the same as the role of the target domain. To achieve this
a constraint can be imposed using a constrain statement:

constrain process transition ( r1 == r2 );

This states that a process transition can only occur if the source role is the same as the
target role, therefore a constraint is a condition that must be satisfied in order for one
or more permissions to be granted (i.e. a constraint imposes additional restrictions on
TE rules). Note that the constraint is based on an object class (process in this case)
and one or more of its permissions.
The kernel policy language constraints are defined in the Constraint Statements
section).

2.6.2 Bounds
It is possible to add bounds to users, roles and types, however currently only types are
enforced by the kernel using the typebounds rule as described in the Bounds
Overview section (although user and role bounds may be declared using CIL,
however they are validated at compile time).

Page 26
The SELinux Notebook

2.7 Security Context
SELinux requires a security context to be associated with every process (or subject)
and object that are used by the security server to decide whether access is allowed or
not as defined by the policy.
The security context is also known as a 'security label' or just label that can cause
confusion as there are many types of label depending on the context.
Within SELinux, a security context is represented as variable-length strings that
define the SELinux user3, their role, a type identifier and an optional MCS / MLS
security range or level as follows:
user:role:type[:range]

Where:
user The SELinux user identity. This can be associated to one or more
roles that the SELinux user is allowed to use.
role The SELinux role. This can be associated to one or more types the
SELinux user is allowed to access.
type When a type is associated with a process, it defines what processes
(or domains) the SELinux user (the subject) can access.
When a type is associated with an object, it defines what access
permissions the SELinux user has to that object.
range This field can also be know as a level and is only present if the
policy supports MCS or MLS. The entry can consist of:
• A single security level that contains a sensitivity level and
zero or more categories (e.g. s0, s1:c0, s7:c10.c15).
• A range that consists of two security levels (a low and
high) separated by a hyphen (e.g. s0 - s15:c0.c1023).
These components are discussed in the Security Levels section.

However note that:
1. Access decisions regarding a subject make use of all the components of the
security context.
2. Access decisions regarding an object make use of the components as follows:
a) the user is either set to a special user called system_u or it is set to
the SELinux user id of the creating process. It is possible to add
contraints on users within policy based on their object class (an
example of this is the Reference Policy UBAC (User Based Access
Control) option.
b) the role is generally set to a special SELinux internal role of
object_r, although policy version 26 with kernel 2.6.39 and above
do support role transitions on any object class. It is then possible to add
contraints on the role within policy based on their object class.
3
An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is
mapped to the SELinux user id by configuration files.

Page 27
The SELinux Notebook

The Computing Security Contexts section decribes how SELinux computes the
security context components based on a source context, target context and object
class.
The examples below show security contexts for processes, directories and files (note
that the policy did not support MCS or MLS, therefore no level field):

Example Process Security Context:
# These are process security contexts taken from a ps -Z command
# (edited for clarity) that show four processes:

LABEL PID TTY CMD
unconfined_u:unconfined_r:unconfined_t 2539 pts/0 bash
unconfined_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server
unconfined_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server
unconfined_u:unconfined_r:unconfined_t 3146 pts/0 ps

# Note the bash and ps processes are running under the
# unconfined_t domain, however the secure_server has two instances
# running under two different domains (ext_gateway_t and
# int_gateway_t). Also note that they are using the
# message_filter_r role whereas bash and ps use unconfined_r.
#
# These results were obtained by running the system in permissive
# mode (as in enforcing mode the gateway processes would not
# be shown).

Example Object Security Context:
# These are the message queue directory object security contexts
# taken from an ls -Zd command (edited for clarity):

system_u:object_r:in_queue_t /usr/message_queue/in_queue
system_u:object_r:out_queue_t /usr/message_queue/out_queue

# Note that they are instantiated with system_u and object_r

# These are the message queue file object security contexts
# taken from an ls -Z command (edited for clarity):

/usr/message_queue/in_queue:
unconfined_u:object_r:in_file_t Message-1
unconfined_u:object_r:in_file_t Message-2

/usr/message_queue/out_queue:
unconfined_u:object_r:out_file_t Message-10
unconfined_u:object_r:out_file_t Message-11

# Note that they are instantiated with unconfined_u as that was
# the SELinux user id of the process that created the files
# (see the process example above). The role remained as
# object_r.

Page 28
The SELinux Notebook

2.8 Subjects
A subject is an active entity generally in the form of a person, process, or device that
causes information to flow among objects or changes the system state.
Within SELinux a subject is an active process and has a security context associated
with it, however a process can also be referred to as an object depending on the
context in which it is being taken, for example:
1. A running process (i.e. an active entity) is a subject because it causes
information to flow among objects or can change the system state.
2. The process can also be referred to as an object because each process has an
associated object class4 called 'process'. This process 'object', defines what
permissions the policy is allowed to grant or deny on the active process.
An example is given of the above scenarios in the Allowing a Process Access to an
Object section.
In SELinux subjects can be:
Trusted - Generally these are commands, applications etc. that have been written
or modified to support specific SELinux functionality to enforce the security
policy (e.g. the kernel, init, pam, xinetd and login). However, it can also cover any
application that the organisation is willing to trust as a part of the overall system.
Although (depending on your paranoia level), the best policy is to trust nothing
until it has been verified that it conforms to the security policy. Generally these
trusted applications would run in either their own domain (e.g. the audit daemon
could run under auditd_t) or grouped together (e.g. the semanage(8) and
semodule(8) commands could be grouped under semanage_t).
Untrusted - Everything else.

2.9 Objects
Within SELinux an object is a resource such as files, sockets, pipes or network
interfaces that are accessed via processes (also known as subjects). These objects are
classified according to the resource they provide with access permissions relevant to
their purpose (e.g. read, receive and write), and assigned a security context as
described in the following sections.

2.9.1 Object Classes and Permissions
Each object consists of a class identifier that defines its purpose (e.g. file, socket)
along with a set of permissions 5 that describe what services the object can handle
(read, write, send etc.). When an object is instantiated it will be allocated a name
(e.g. a file could be called config or a socket my_connection) and a security
context (e.g. system_u:object_r:selinux_config_t) as shown in Figure
2.5.

4
The object class and its associated permissions are explained in the Process Object Class section.
5
Also known in SELinux as Access Vectors (AV).

Page 29
The SELinux Notebook

Object – of the ‘file’ object class
read

Permissions
File name: write
/etc/selinux/config
Security Context: append
system_u:object_r:selinux_config_t
etc.

Figure 2.5: Object Class = 'file' and permissions - the policy rules would define
those permissions allowed for each process that needs access to the
/etc/selinux/config file.
The objective of the policy is to enable the user of the object (the subject) access to
the minimum permissions needed to complete the task (i.e. do not allow write
permission if only reading information).
These object classes and their associated permissions are built into the GNU / Linux
kernel and user space object managers by developers and are therefore not generally
updated by policy writers.
The object classes consist of kernel object classes (for handling files, sockets etc.)
plus userspace object classes for userspace object managers (for services such as X-
Windows or dbus). The number of object classes and their permissions can vary
depending on the features configured in the GNU / Linux release. All the known
object classes and permissions are described in Appendix A - Object Classes and
Permissions.

2.9.2 Allowing a Process Access to Resources
This is a simple example that attempts to explain two points:
1. How a process is given permission to use an objects resource.
2. By using the 'process' object class, show that a process can be described as a
process or object.
An SELinux policy contains many rules and statements, the majority of which are
allow rules that (simply) allows processes to be given access permissions to an
objects resources.
The following allow rule and Figure 2.6 illustrates 'a process can also be an object'
as it allows processes running in the unconfined_t domain, permission to
'transition' the external gateway application to the ext_gateway_t domain
once it has been executed:
allow Rule | source_domain | target_type : class | permission
-----------▼---------------▼------------------------▼------------
allow unconfined_t ext_gateway_t : process transition;

Where:
allow The SELinux language allow rule.
unconfined_t The source domain (or subject) identifier - in this case the

Page 30
The SELinux Notebook

shell that wants to exec the gateway application.
ext_gateway_t The target object identifier - the object instance of the
gateway application process.
process The target object class - the 'process' object class.
transition The permission granted to the source domain on the
targets object - in this case the unconfined_t domain
has transition permission on the ext_gateway_t
'process' object.

transition
unconfined_t ext_gateway_t
(Permission)

Subject – the
process Object Instance – of the
‘process’ object class

Figure 2.6: The allow rule - Showing that the subject (the processes running
in the unconfined_t domain) has been given the transition permission on the
ext_gateway_t 'process' object.
It should be noted that there is more to a domain transition than described above, for a
more detailed explanation, see the Domain Transition section.

2.9.3 Labeling Objects
Within a running SELinux enabled GNU / Linux system the labeling of objects is
managed by the system and generally unseen by the users (until labeling goes
wrong !!). As processes and objects are created and destroyed, they either:
1. Inherit their labels from the parent process or object.
2. The policy type, role and range transition statements allow a different label to
be assigned as discussed in the Domain and Object Transitions section.
3. SELinux-aware applications can enforce a new label (with the policies
approval of course) using the libselinux API functions.
4. An object manager (OM) can enforce a default label that can either be built
into the OM or obtained via a configuration file (such as those used by X-
Windows).
5. Use an 'initial security identifier' (or initial SID). These are defined in all base
and monolithic policies and are used to either set an initial context during the
boot process, or if an object requires a default (i.e. the object does not already
have a valid context).
The Computing Security Contexts section gives detail on how some of the kernel
based objects are computed.

Page 31
The SELinux Notebook

The SELinux policy language supports object labeling statements for file and network
services that are defined in the File System Labeling Statements and Network
Labeling Statements sections.
An overview of the process required for labeling file systems that use extended
attributes (such as ext3 and ext4) is discussed in the Labeling Extended Attribute
Filesystems section.

2.9.3.1 Labeling Extended Attribute Filesystems
The labeling of file systems that implement extended attributes 6 is supported by
SELinux using:
1. The fs_use_xattr statement within the policy to identify what file
systems use extended attributes. This statement is used to inform the security
server how to label the filesystem.
2. A 'file contexts' file that defines what the initial contexts should be for each
file and directory within the filesystem. The format of this file is described in
the modules/active/file_contexts.template file7 section.
3. A method to initialise the filesystem with these extended attributes. This is
achieved by SELinux utilities such as fixfiles(8) and setfiles(8).
There are also commands such as chcon(1), restorecon(8) and
restorecond(8) that can be used to relabel files.
Extended attributes containing the SELinux context of a file can be viewed by the ls
-Z or getfattr(1) commands as follows:

ls -Z myfile
-rw-r--r-- rch rch unconfined_u:object_r:user_home:s0 myfile

getfattr -n security.selinux myfile
# file_name: myfile
security.selinux="unconfined_u:object_r:user_home:s0

# Where -n security.selinux is the name of the extended
# attribute and 'myfile' is a file name. The security context
# (or label) held for the file is displayed.

2.9.3.1.1 Copying and Moving Files
Assuming that the correct permissions have been granted by the policy, the effects on
the security context of a file when copied or moved differ as follows:
• copy a file - takes on label of new directory.
• move a file - retains the label of the file.
However, if the restorecond daemon is running and the restorecond.conf
file is correctly configured, then other security contexts can be associated to the file as
6
These file systems store the security context in an attribute associated with the file.
7
Note that this file contains the contexts of all files in all extended attribute filesystems for the
policy. However within a modular policy each module describes its own file context information,
that is then used to build this file.

Page 32
The SELinux Notebook

it is moved or copied (provided it is a valid context and specified in the
file_contexts file). Note that there is also the install(1) command that
supports a -Z option to specify the target context.
The examples below show the effects of copying and moving files:
# These are the test files in the /root directory and their current security
# context:
#
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file

# These are the commands used to copy / move the files:
# Standard copy file:
cp copied-file /usr/message_queue/in_queue

# Standard move file:
mv moved-file /usr/message_queue/in_queue

# The target directory (/usr/message_queue/in_queue) is labeled "in_queue_t".
# The results of "ls -Z" on the target directory are:
#
-rw-r--r-- root root unconfined_u:object_r:in_queue_t copied-file
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file

However, if the restorecond daemon is running:
# If the restorecond daemon is running with a restorecond.conf file entry of:
#
/usr/message_queue/in_queue/*

# AND the file_context file has an entry of:
#
/usr/message_queue/in_queue(/.*)? -- system_u:object_r:in_file_t

# Then all the entries would be set as follows when the daemon detects the files
# creation:
#
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file
-rw-r--r-- root root unconfined_u:object_r:in_file_t moved-file

# This is because the restorecond process will set the contexts defined in
# the file_contexts file to the context specified as it is created in the
# new directory.

This is because the restorecond process will set the contexts defined in the
file_contexts file to the context specified as it is created in the new directory.

2.9.3.2 Labeling Subjects
On a running GNU / Linux system, processes inherit the security context of the parent
process. If the new process being spawned has permission to change its context, then
a 'type transition' is allowed that is discussed in the Domain Transition section.
The policy language supports a number of statements to assign components to
security contexts such as:
user, role and type statements.
and manage their scope:
role_allow and constrain
and manage their transition:
type_transition, role_transition and range_transition

Page 33
The SELinux Notebook

2.9.4 Object Reuse
As GNU / Linux runs it creates instances of objects and manages the information they
contain (read, write, modify etc.) under the control of processes, and at some stage
these objects may be deleted or released allowing the resource (such as memory
blocks and disk space) to be available for reuse.
GNU / Linux handles object reuse by ensuring that when a resource is re-allocated it
is cleared. This means that when a process releases an object instance (e.g. release
allocated memory back to the pool, delete a directory entry or file), there may be
information left behind that could prove useful if harvested. If this should be an issue,
then the process itself should clear or shred the information before releasing the object
(which can be difficult in some cases unless the source code is available).

2.10 Computing Security Contexts
SELinux uses a number of policy language statements and libselinux functions
to compute a security context via the kernel security server.
When security contexts are computed, the different kernel, userspace tools and policy
versions can influence the outcome. This is because patches have been applied over
the years that give greater flexiblity in computing contexts. For example a 2.6.39
kernel with SELinux userspace services supporting policy version 26 can influence
the computed role.
The security context is computed for an object using the following components: a
source context, a target context and an object class.
The libselinux userspace functions used to compute a security context are:
avc_compute_create(3) and security_compute_create(3)
avc_compute_member(3) and security_compute_member(3)
security_compute_relabel(3)
Note that these libselinux functions actually call the kernel equivalent functions
in the security server (see kernel source security/selinux/ss/services.c:
security_compute_sid, security_member_sid and
security_change_sid) that actually compute the security context.
The kernel policy language statements that influence a computed security context are:
type_transition, role_transition, range_transition,
type_member and type_change, default_user, default_role,
default_type and default_range statements (their corresponding CIL
statements exclude the underscore).
The sections that follow give an overview of how security contexts are computed for
some kernel classes and also when using the userspace libselinux functions.

2.10.1 Security Context Computation for Kernel Objects
Using a combination of the email thread:
http://www.spinics.net/lists/selinux/msg10746.html and kernel 3.14 source, this is
how contexts are computed by the security server for various kernel objects (also see

Page 34
The SELinux Notebook

the Linux Security Module and SELinux section and "Implementing SELinux as a
Linux Security Module" [1]).

2.10.1.1 Process
The initial task starts with the kernel security context, but the "init" process will
typically transition into its own unique context (e.g. init_t) when the init binary is
executed after the policy has been loaded. Some init programs re-exec themselves
after loading policy, while in other cases the initial policy load is performed by the
initrd/initramfs script prior to mounting the real root and executing the real
init program.
Processes inherit their security context as follows:
1. On fork a process inherits the security context of its creator/parent.
2. On exec, a process may transition to another security context based on policy
statements: type_transition, range_transition,
role_transition (policy version 26), default_user,
default_role, default_range (policy versions 27) and
default_type (policy version 28) or if a security-aware process, by calling
setexeccon(3) if permitted by policy prior to invoking exec.
3. At any time, a security-aware process may invoke setcon(3) to switch its
security context (if permitted by policy) although this practice is generally
discouraged - exec-based transitions are preferred.

2.10.1.2 Files
The default behavior for labeling files (actually inodes that consist of the following
classes: files, symbolic links, directories, socket files, fifo's and block/character) upon
creation for any filesystem type that supports labeling is as follows:
1. The user component is inherited from the creating process (policy version 27
allows a default_user of source or target to be defined for each object
class).
2. The role component generally defaults to the object_r role (policy version
26 allows a role_transition and version 27 allows a default_role
of source or target to be defined for each object class).
3. The type component defaults to the type of the parent directory if no matching
type_transition rule was specified in the policy (policy version 25
allows a filename type_transition rule and version 28 allows a
default_type of source or target to be defined for each object class).
4. The range/level component defaults to the low/current level of the
creating process if no matching range_transition rule was specified in
the policy (policy version 27 allows a default_range of source or target
with the selected range being low, high or low-high to be defined for each
object class).
Security-aware applications can override this default behavior by calling
setfscreatecon(3) prior to creating the file, if permitted by policy.

Page 35
The SELinux Notebook

For existing files the label is determined from the xattr value associated with the
file. If there is no xattr value set on the file, then the file is treated as being labeled
with the default file security context for the filesystem. By default, this is the "file"
initial SID, which is mapped to a context by the policy. This default may be
overridden via the defcontext= mount option on a per-mount basis as described in
mount(8).

2.10.1.3 File Descriptors
Inherits the label of its creator/parent.

2.10.1.4 Filesystems
Filesystems are labeled using the appropriate fs_use kernel policy language
statement as they are mounted, they are based on the filesystem type name (e.g.
ext4) and their behaviour (e.g. xattr). For example if the policy specifies the
following:
fs_use_task pipefs system_u:object_r:fs_t:s0

then as the pipefs filesystem is being mounted, the SELinux LSM security hook
selinux_set_mnt_opts will call security_fs_use that will:
a) Look for the filesystem name within the policy (pipefs)
b) If present, obtain its behaviour (fs_use_task)
c) Then obtain the allocated security context
(system_u:object_r:fs_t:s0)
Should the behaviour be defined as fs_use_task, then the filesystem will be
labeled as follows:
1. The user component is inherited from the creating process (policy version 27
allows a default_user of source or target to be defined).
2. The role component generally defaults to the object_r role (policy version
26 allows a role_transition and version 27 allows a default_role
of source or target to be defined).
3. The type component defaults to the type of the target type if no matching
type_transition rule was specified in the policy (policy version 28
allows a default_type of source or target to be defined).
4. The range/level component defaults to the low/current level of the
creating process if no matching range_transition rule was specified in
the policy (policy version 27 allows a default_range of source or target
with the selected range being low, high or low-high to be defined).
Notes:
1. Filesystems that support xattr extended attributes can be identified via the
mount command as there will be a 'seclabel' keyword present.

Page 36
The SELinux Notebook

2. There are mount options for allocating various context types: context=,
fscontext=, defcontext= and rootcontext=. They are fully
described in the mount(8) man page.

2.10.1.5 Network File System (nfsv4)
If labeled NFS is implemented with xattr support, then the creation of inodes are
treated as described in the Files section.

2.10.1.6 INET Sockets
If a socket is created by the socket(3) call they are labeled as follows:
1. The user component is inherited from the creating process (policy version 27
allows a default_user of source or target to be defined for each socket
object class).
2. The role component is inherited from the creating process (policy version 26
allows a role_transition and version 27 allows a default_role of
source or target to be defined for each socket object class).
3. The type component is inherited from the creating process if no matching
type_transition rule was specified in the policy and version 28 allows a
default_type of source or target to be defined for each socket object
class).
4. The range/level component is inherited from the creating process if no
matching range_transition rule was specified in the policy (policy
version 27 allows a default_range of source or target with the selected
range being low, high or low-high to be defined for each socket object class).
Security-aware applications may use setsockcreatecon(3) to explicitly label
sockets they create if permitted by policy.
If created by a connection they are labeled with the context of the listening process.
Some sockets may be labeled with the kernel SID to reflect the fact that they are
kernel-internal sockets that are not directly exposed to applications.

2.10.1.7 IPC
Inherits the label of its creator/parent.

2.10.1.8 Message Queues
Inherits the label of its sending process. However if sending a message that is
unlabeled, compute a new label based on the current process and the message queue it
will be stored in as follows:
1. The user component is inherited from the sending process (policy version 27
allows a default_user of source or target to be defined for the message
object class).

Page 37
The SELinux Notebook

2. The role component is inherited from the sending process (policy version 26
allows a role_transition and version 27 allows a default_role of
source or target to be defined for the message object class).
3. The type component is inherited from the sending process if no matching
type_transition rule was specified in the policy and version 28 allows a
default_type of source or target to be defined for the message object
class).
4. The range/level component is inherited from the sending process if no
matching range_transition rule was specified in the policy (policy
version 27 allows a default_range of source or target with the selected
range being low, high or low-high to be defined for the message object class).

2.10.1.9 Semaphores
Inherits the label of its creator/parent.

2.10.1.10 Shared Memory
Inherits the label of its creator/parent.

2.10.1.11 Keys
Inherits the label of its creator/parent.
Security-aware applications may use setkeycreatecon(3) to explicitly label
keys they create if permitted by policy.

2.10.2 Using libselinux Functions

2.10.2.1 avc_compute_create and security_compute_create
The table below8 shows how the components from the source context scon, target
context tcon and class tclass are used to compute the new context newcon
(referenced by SIDs for avc_compute_create(3)). The following notes also
apply:
a) Any valid policy role_transition, type_transition and
range_transition enforcement rules will influence the final outcome as
shown.
b) For kernels less than 2.6.39 the context generated will depend on whether the
class is process or any other class.
c) For kernels 2.6.39 and above the following also applies:
i. Those classes suffixed by socket will also be included in the
process class outcome.
ii. If a valid role_transition rule for tclass, then use that instead
of the default object_r. Also requires policy version 26 or greater -
see security_policyvers(3).
8
The table only contains the kernel version, the text gives the policy version also required.

Page 38
The SELinux Notebook

iii. If the type_transition rule is classed as the 'file name transition
rule' (i.e. it has an object_name parameter), then provided the
object name in the rule matches the last component of the objects name
(in this case a file or directory name), then use the rules
default_type . Also requires policy version 25 or greater.
d) For kernels 3.5 and above with policy version 27 or greater, the
default_user, default_role, default_range statements will
influence the user, role and range of the computed context for the
specified class tclass. With policy version 28 or greater the
default_type statement can also influence the type in the computed
context.

user role type range
If kernel >= 3.5 with a If kernel >=2.6.39, and If there is a valid If there is a valid
default_user tclass there is a valid type_transition range_transition
target rule then use tcon role_transition rule then use the rules rule then use the rules new_range
user rule then use the rules default_type OR
ELSE new_role OR If kernel >= 3.5 with
Use scon user OR If kernel >= 3.5 with default_range tclass
If kernel >= 3.5 with default_type tclass source low rule then use
default_role tclass source rule then use scon scon low
source rule then use scon type OR
role OR If kernel >= 3.5 with
OR If kernel >= 3.5 with default_range tclass
If kernel >= 3.5 with default_type tclass source high rule then use
default_role tclass target rule then use tcon scon high
target rule then use tcon type OR
role OR If kernel >= 3.5 with
OR If kernel >= 2.6.39 and default_range tclass
If kernel >= 2.6.39 and tclass is process or source low_high rule then
tclass is process or *socket, then use scon use scon range
*socket, then use scon type OR
role OR If kernel >= 3.5 with
OR If kernel <= 2.6.38 and default_range tclass
If kernel <= 2.6.38 and tclass is process, then target low rule then use
tclass is process, then use scon type tcon low
use scon role ELSE OR
ELSE Use tcon type If kernel >= 3.5 with
Use object_r default_range tclass
target high rule then use
tcon high
OR
If kernel >= 3.5 with
default_range tclass
target low_high rule then
use tcon range
OR
If kernel >= 2.6.39 and tclass
is process or *socket, then
use scon range
OR
If kernel <= 2.6.38 and tclass
is process, then use scon
range
ELSE
Use scon low

Page 39
The SELinux Notebook

2.10.2.2 avc_compute_member and security_compute_member
The table below9 shows how the components from the source context, scon target
context, tcon and class, tclass are used to compute the new context newcon
(referenced by SIDs for avc_compute_member(3)). The following notes also
apply:
a) Any valid policy type_member enforcement rules will influence the final
outcome as shown.
b) For kernels less than 2.6.39 the context generated will depend on whether the
class is process or any other class.
c) For kernels 2.6.39 and above, those classes suffixed by socket are also
included in the process class outcome.
d) For kernels 3.5 and above with policy version 28 or greater, the
default_role, default_range statements will influence the role and
range of the computed context for the specified class tclass. With policy
version 28 or greater the default_type statement can also influence the
type in the computed context.

9
The table only contains the kernel version, the text gives the policy version also required.

Page 40
The SELinux Notebook

user role type range
Always uses tcon user If kernel >= 3.5 with If there is a valid If kernel >= 3.5 with
default_role tclass type_member default_range tclass
source rule then use scon rule then use the rules source low rule then use
role member_type scon low
OR OR OR
If kernel >= 3.5 with If kernel >= 3.5 with If kernel >= 3.5 with
default_role tclass default_type tclass default_range tclass
target rule then use tcon source rule then use scon source high rule then use
role type scon high
OR OR OR
If kernel >= 2.6.39 and If kernel >= 3.5 with If kernel >= 3.5 with
tclass is process or default_type tclass default_range tclass
*socket, then use scon target rule then use tcon source low_high rule then
role type use scon range
OR OR OR
If kernel <= 2.6.38 and If kernel >= 2.6.39 and If kernel >= 3.5 with
tclass is process, then tclass is process or default_range tclass
use scon role *socket, then use scon target low rule then use
ELSE type tcon low
Use object_r OR OR
If kernel <= 2.6.38 and If kernel >= 3.5 with
tclass is process, then default_range tclass
use scon type target high rule then use
ELSE tcon high
Use tcon type OR
If kernel >= 3.5 with
default_range tclass
target low_high rule then
use tcon range
OR
If kernel >= 2.6.39 and tclass
is process or *socket, then
use scon range
OR
If kernel <= 2.6.38 and tclass
is process, then use scon
range
ELSE
Use scon low

2.10.2.3 security_compute_relabel
The table below10 shows how the components from the source context, scon target
context, tcon and class, tclass are used to compute the new context newcon for
security_compute_relabel(3). The following notes also apply:
a) Any valid policy type_change enforcement rules will influence the final
outcome shown in the table.
b) For kernels less than 2.6.39 the context generated will depend on whether the
class is process or any other class.
c) For kernels 2.6.39 and above, those classes suffixed by socket are also
included in the process class outcome.

10
The table only contains the kernel version, the text gives the policy version also required.

Page 41
The SELinux Notebook

d) For kernels 3.5 and above with policy version 28 or greater, the
default_user, default_role, default_range statements will
influence the user, role and range of the computed context for the
specified class tclass. With policy version 28 or greater the
default_type statement can also influence the type in the computed
context.
user role type range
If kernel >= 3.5 with a If kernel >= 3.5 with If there is a valid If kernel >= 3.5 with
default_user tclass default_role tclass type_change default_range tclass
target rule then use tcon source rule then use scon rule then use the rules source low rule then use
user role change_type scon low
ELSE OR OR OR
Use scon user If kernel >= 3.5 with If kernel >= 3.5 with If kernel >= 3.5 with
default_role tclass default_type tclass default_range tclass
target rule then use tcon source rule then use scon source high rule then use
role type scon high
OR OR OR
If kernel >= 2.6.39 and If kernel >= 3.5 with If kernel >= 3.5 with
tclass is process or default_type tclass default_range tclass
*socket, then use scon target rule then use tcon source low_high rule then
role type use scon range
OR OR OR
If kernel <= 2.6.38 and If kernel >= 2.6.39 and If kernel >= 3.5 with
tclass is process, then tclass is process or default_range tclass
use scon role *socket, then use scon target low rule then use
ELSE type tcon low
Use object_r OR OR
If kernel <= 2.6.38 and If kernel >= 3.5 with
tclass is process, then default_range tclass
use scon type target high rule then use
ELSE tcon high
Use tcon type OR
If kernel >= 3.5 with
default_range tclass
target low_high rule then
use tcon range
OR
If kernel >= 2.6.39 and tclass
is process or *socket, then
use scon range
OR
If kernel <= 2.6.38 and tclass
is process, then use scon
range
ELSE
Use scon low

2.11 Computing Access Decisions
There are a number of ways to compute access decisions within userspace SELinux-
aware applications or object managers:
1. Use functions that do not cache access decisions (i.e. they do not use the
libselinux AVC services). These require a call to the kernel for every
decision using security_compute_av(3) or

Page 42
The SELinux Notebook

security_compute_av_flags(3). The avc_netlink_*(3)
functions can be used to detect policy change events. Auditing would need to
be implemented if required.
2. Use functions that utilise the libselinux userspace AVC services that are
initialised with avc_open(3). These can be built in various configurations
such as:
a) Using the default single threaded mode where avc_has_perm(3)
will automatically cache entries, audit the decision and manage the
handling of policy change events.
b) Implementing threads or a similar service that will handle policy
change events and auditing in real time with avc_has_perm(3) or
avc_has_perm_noaudit(3) handling decisions and caching.
This has the advantage of better performance, which can be further
increased by caching the entry reference.
3. Implement custom caching services with security_compute_av(3) or
security_compute_av_flags(3) for computing access decisions. The
avc_netlink_*(3) functions can then be used to detect policy change
events. Auditing would need to be implemented if required.
4. Use of the selinux_check_access(3) function is generally the
recommended option provided only one permission requires the check. This
utilises the AVC services defined in bullet 2, in a single call with the option to
add supplemental auditing information (that is handled as described in
avc_audit(3)).
Where performance is important when making policy decisions, then the
selinux_status_open(3), selinux_status_updated(3),
selinux_status_getenforce(3), selinux_status_policyload(3)
and selinux_status_close(3) functions could be used to detect policy
updates etc. as these do not require kernel system call over-heads once set up. Note
that these functions are only available from libselinux 2.0.99, with Linux kernel
2.6.37 and above.

2.12 Domain and Object Transitions
This section discusses the type_transition statement that is used to:
1. Transition a process from one domain to another (a domain transition).
2. Transition an object from one type to another (an object transition).
These transitions can also be achieved using the libselinux API functions for
SELinux-aware applications.

2.12.1 Domain Transition
A domain transition is where a process in one domain starts a new process in another
domain under a different security context. There are two ways a process can define a
domain transition:

Page 43
The SELinux Notebook

1. Using a type_transition statement, where the exec system call will
automatically perform a domain transition for programs that are not
themselves SELinux-aware. This is the most common method and would be in
the form of the following statement:
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

2. SELinux-aware applications can specify the domain of the new process using
the libselinux API call setexeccon(3). To achieve this the SELinux-
aware application must also have the setexec permission, for example:

allow crond_t self : process setexec;

However, before any domain transition can take place the policy must specify that:
1. The source domain has permission to transition into the target domain.
2. The application binary file needs to be executable in the source domain.
3. The application binary file needs an entry point into the target domain.
The following is a type_transition statement taken from the example loadable
module message filter ext_gateway.conf (described in the source tarball) that
will be used to explain the transition process11:
type_transition | source_domain | target_type : class | target_domain;
----------------▼---------------▼---------------------------------▼----------------
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

This type_transition statement states that when a process running in the
unconfined_t domain (the source domain) executes a file labeled
secure_services_exec_t, the process should be changed to ext_gateway_t (the target
domain) if allowed by the policy (i.e. transition from the unconfined_t domain to the
ext_gateway_t domain).
However as stated above, to be able to transition to the ext_gateway_t domain, the
following minimum permissions must be granted in the policy using allow rules,
where (note that the bullet numbers correspond to the numbers shown in Figure 2.7):
1. The domain needs permission to transition into the ext_gateway_t (target)
domain:
allow unconfined_t ext_gateway_t : process transition;

2. The executable file needs to be executable in the unconfined_t (source)
domain, and therefore also requires that the file is readable:
allow unconfined_t secure_services_exec_t : file { execute read getattr };

3. The executable file needs an entry point into the ext_gateway_t (target)
domain:

11
For reference, the external gateway uses a server application called secure_server that is
transitioned to the ext_gateway_t domain from the unconfined_t domain. The
secure_server executable is labeled secure_services_exec_t.

Page 44
The SELinux Notebook

allow ext_gateway_t secure_services_exec_t : file entrypoint;

These are shown in Figure 2.7 where unconfined_t forks a child process, that
then exec's the new program into a new domain called ext_gateway_t. Note that
because the type_transition statement is being used, the transition is
automatically carried out by the SELinux enabled kernel.

Process
system_u:system_r:unconfined_t

unconfined_t
Pare nt Proce ss 1

fork ()

system_u:system_r:unconfined_t

allow unconfined_t ext_gateway_t : process transition

unconfined_t 2
C hild Proce ss

execve () type_transition unconfined_t
secure_services_exec_t : process ext_gateway_t;

system_u:system_r:ext_gateway_t execute
allow unconfined_t secure_services_exec_t : file read
getattr
allow ext_gateway_t secure_services_exec_t : file entrypoint

ext_gateway_t
Ne w program 3
(secure_server)

Figure 2.7: Domain Transition - Where the secure_server is executed within the
unconfined_t domain and then transitioned to the ext_gateway_t domain.

2.12.1.1 Type Enforcement Rules
When building the ext_gateway.conf and int_gateway.conf modules the
intention was to have both of these transition to their respective domains via
type_transition statements. The ext_gateway_t statement would be:
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

and the int_gateway_t statement would be:
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;

However, when linking these two loadable modules into the policy, the following
error was given:

Page 45
The SELinux Notebook

semodule -v -s modular-test -i int_gateway.pp -i ext_gateway.pp
Attempting to install module 'int_gateway.pp':
Ok: return value of 0.
Attempting to install module 'ext_gateway.pp':
Ok: return value of 0.
Committing changes:
libsepol.expand_terule_helper: conflicting TE rule for (unconfined_t,
secure_services_exec_t:process): old was ext_gateway_t, new is int_gateway_t
libsepol.expand_module: Error during expand
libsemanage.semanage_expand_sandbox: Expand module failed
semodule: Failed!

This happened because the type enforcement rules will only allow a single 'default'
type for a given source and target (see the Type Rules section). In the above case
there were two type_transition statements with the same source and target, but
different default domains. The ext_gateway.conf module had the following
statements:
# Allow the client/server to transition for the gateways:
allow unconfined_t ext_gateway_t : process { transition };
allow unconfined_t secure_services_exec_t : file { read execute getattr };
allow ext_gateway_t secure_services_exec_t : file { entrypoint };
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

And the int_gateway.conf module had the following statements:
# Allow the client/server to transition for the gateways:
allow unconfined_t int_gateway_t : process { transition };
allow unconfined_t secure_services_exec_t : file { read execute getattr };
allow int_gateway_t secure_services_exec_t : file { entrypoint };
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;

While the allow rules are valid to enable the transitions to proceed, the two
type_transition statements had different 'default' types (or target domains), that
breaks the type enforcement rule.
It was decided to resolve this by:
1. Keeping the type_transition rule for the 'default' type of
ext_gateway_t and allow the secure server process to be exec'd from
unconfined_t as shown in Figure 2.7, by simply running the command
from the prompt as follows:
# Run the external gateway 'secure server' application on port 9999 and
# let the policy transition the process to the ext_gateway_t domain:

secure_server 99999

2. Use the SELinux runcon(1) command to ensure that the internal gateway
runs in the correct domain by running runcon from the prompt as follows:
# Run the internal gateway 'secure server' application on port 1111 and
# use runcon to transition the process to the int_gateway_t domain:

runcon -t int_gateway_t -r message_filter_r secure_server 1111

# Note - The role is required as a role transition that is defined in the
# policy.

The runcon command makes use of a number of libselinux API functions to
check the current context and set up the new context (for example getfilecon(3)

Page 46
The SELinux Notebook

is used to get the executable files context and setexeccon(3) is used to set the
new process context). If all contexts are correct, then the execvp(2) system call is
executed that exec's the secure_server application with the argument of '1111'
into the int_gateway_t domain with the message_filter_r role. The
runcon source can be found in the coreutils package.
Other ways to resolve this issue are:
1. Use the runcon command for both gateways to transition to their respective
domains. The type_transition statements are therefore not required.
2. Use different names for the secure server executable files and ensure they have
a different type (i.e. instead of secure_service_exec_t label the
external gateway ext_gateway_exec_t and the internal gateway
int_gateway_exec_t. This would involve making a copy of the
application binary (which has already been done as part of the module testing
by calling the server 'server' and labeling it unconfined_t and then
making a copy called secure_server and labeling it
secure_services_exec_t).
3. Implement the policy using the Reference Policy utilising the template
interface principles discussed in the template Macro section.
It was decided to use runcon as it demonstrates the command usage better than
reading the man pages.

2.12.2 Object Transition
An object transition is where a new object requires a different label to that of its
parent. For example a file is being created that requires a different label to that of its
parent directory. This can be achieved automatically using a type_transition
statement as follows:
type_transition ext_gateway_t in_queue_t:file in_file_t;

The following details an object transition used in the ext_gateway.conf loadable
module (see the source tarball) where by default, files would be labeled
in_queue_t when created by the gateway application as this is the label attached to
the parent directory as shown:
ls -Za /usr/message_queue/in_queue
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .
drwxr-xr-x root root system_u:object_r:unconfined_t ..

However the requirement is that files in the in_queue directory must be labeled
in_file_t. To achieve this the files created must be relabeled to in_file_t by
using a type_transition rule as follows:
# type_transition | source_domain | target_type : object | default_type;
------------------▼---------------▼-----------------------▼---------------
type_transition ext_gateway_t in_queue_t : file in_file_t;

Page 47
The SELinux Notebook

This type_transition statement states that when a process running in the
ext_gateway_t domain (the source domain) wants to create a file object in the
directory that is labeled in_queue_t, the file should be relabeled in_file_t if allowed by
the policy (i.e. label the file in_file_t).
However as stated abov,e to be able to create the file, the following minimum
permissions need to be granted in the policy using allow rules, where:
1. The source domain needs permission to add file entries into the directory:
allow ext_gateway_t in_queue_t : dir { write search add_name };

2. The source domain needs permission to create file entries:
allow ext_gateway_t in_file_t : file { write create getattr };

3. The policy can then ensure (via the SELinux kernel services) that files created
in the in_queue are relabeled:

type_transition ext_gateway_t in_queue_t : file in_file_t;

An example output from a directory listing shows the resulting file labels:
ls -Za /usr/message_queue/in_queue
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .
drwxr-xr-x root root system_u:object_r:unconfined_t ..
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-1
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-2

2.13 Multi-Level Security and Multi-Category Security
As stated in the Mandatory Access Control (MAC) section as well as supporting Type
Enforcement (TE), SELinux also supports MLS and MCS by adding an optional
level or range entry to the security context. This section gives a brief introduction
to MLS and MCS.
Figure 2.8 shows a simple diagram where security levels represent the classification
of files within a file server. The security levels are strictly hierarchical and conform to
the Bell-La & Padula model (BLP) in that (in the case of SELinux) a process (running
at the 'Confidential' level) can read / write at their current level but only read down
levels or write up levels (the assumption here is that the process is authorised).
This ensures confidentiality as the process can copy a file up to the secret level, but
can never re-read that content unless the process 'steps up to that level', also the
process cannot write files to the lower levels as confidential information would then
drift downwards.

Page 48
The SELinux Notebook

Security Files Data Flows Process
Levels (each with a different label)

File A Write only
Secret
Label = Secret

File B Read and Write Process
Confidential
Label = Confidential Label = Confidential
No No
Write Read
File C Read only
Restricted Down Up
Label = Restricted

X
Unclassified
File D Read only X
Label = Unclassified

Figure 2.8: Security Levels and Data Flows - This shows how the process can only
'Read Down' and 'Write Up' within an MLS enabled system.
To achieve this level of control, the MLS extensions to SELinux make use of
constraints similar to those described in the type enforcement Constraints section,
except that the statement is called mlsconstrain.
However, as always life is not so simple as:
1. Processes and objects can be given a range that represents the low and high
security levels.
2. The security level can be more complex, in that it is a hierarchical sensitivity
and zero or more non-hierarchical categories.
3. Allowing a process access to an object is managed by 'dominance' rules
applied to the security levels.
4. Trusted processes can be given privileges that will allow them to bypass the
BLP rules and basically do anything (that the security policy allowed of
course).
5. Some objects do not support separate read / write functions as they need to
read / respond in cases such as networks.
The sections that follow discuss the format of a security level and range, and how
these are managed by the constraints mechanism within SELinux using dominance
rules.

2.13.1 Security Levels
Table 1 shows the components that make up a security level and how two security
levels form a range for the fourth and optional [:range] of the security context
within an MLS / MCS environment.
The table also adds terminology in general use as other terms can be used that have
the same meanings.

Page 49
The SELinux Notebook

Security Level (or Level) Note that SELinux uses level, sensitivity and
category in the language statements (see the MLS
Consisting of a sensitivity and zero or Language Statements section), however when
more category entries: discussing these the following terms can also be used:
labels, classifications, and compartments.
sensitivity [: category, ... ]

also known as:
Sensitivity Label
Consisting of a classification and
compartment.

 Range 
Low High
sensitivity [: category, ... ] - sensitivity [: category, ... ]

For a process or subject this is the For a process or subject this is the
current level or sensitivity Clearance

For an object this is the current level or For an object this is the maximum range
sensitivity

SystemLow SystemHigh

This is the lowest level or classification for This is the highest level or classification for
the system (for SELinux this is generally the system (for SELinux this is generally
's0', note that there are no categories). 's15:c0,c255', although note that they will
be the highest set by the policy).

Table 1: Level, Label, Category or Compartment - this table shows the meanings
depending on the context being discussed.
The format used in the policy language statements is fully described in the MLS
Statements section, however a brief overview follows.

2.13.1.1 MLS / MCS Range Format
The following components (shown in bold) are used to define the MLS / MCS
security levels within the security context:
user:role:type:sensitivity[:category,...] - sensitivity [:category,...]
---------------▼------------------------▼-----▼-------------------------▼
| level | - | level |
| |
| range |

Where:
sensitivity Sensitivity levels are hierarchical with (traditionally) s0
being the lowest. These values are defined using the
sensitivity statement. To define their hierarchy, the
dominance statement is used.

Page 50
The SELinux Notebook

For MLS systems the highest sensitivity is the last one
defined in the dominance statement (low to high).
Traditionally the maximum for MLS systems is s15
(although the maximum value for the Reference Policy is a
build time option).
For MCS systems there is only one sensitivity defined, and
that is s0.
category Categories are optional (i.e. there can be zero or more
categories) and they form unordered and unrelated lists of
'compartments'. These values are defined using the
category statement, where for example c0.c3 represents
a range (c0 c1 c3) and c0, c3, c7 represent an unordered
list. Traditionally the values are between c0 and c255
(although the maximum value for the Reference Policy is a
build time option).
level The level is a combination of the sensitivity and
category values that form the actual security level. These
values are defined using the level statement.

2.13.1.2 Translating Levels
When writing policy for MLS / MCS security level components it is usual to use an
abbreviated form such as s0, s1 etc. to represent sensitivities and c0, c1 etc. to
represent categories. This is done simply to conserve space as they are held on files as
extended attributes and also in memory. So that these labels can be represented in
human readable form, a translation service is provided via the setrans.conf
configuration file that is used by the mcstransd(8) daemon. For example s0 =
Unclassified, s15 = Top Secret and c0 = Finance, c100 = Spy Stories. The
semanage(8) command can be used to set up this translation and is shown in the
setrans.conf configuration file section.

2.13.2 Managing Security Levels via Dominance Rules
As stated earlier, allowing a process access to an object is managed by 'dominance'
rules applied to the security levels. These rules are as follows:
Security Level 1 dominates Security Level 2 - If the sensitivity of Security
Level 1 is equal to or higher than the sensitivity of Security Level 2 and the
categories of Security Level 1 are the same or a superset of the categories of
Security Level 2.
Security Level 1 is dominated by Security Level 2 - If the sensitivity of
Security Level 1 is equal to or lower than the sensitivity of Security Level 2 and
the categories of Security Level 1 are a subset of the categories of Security Level
2.
Security Level 1 equals Security Level 2 - If the sensitivity of Security Level 1
is equal to Security Level 2 and the categories of Security Level 1 and Security
Level 2 are the same set (sometimes expressed as: both Security Levels dominate
each other).

Page 51
The SELinux Notebook

Security Level 1 is incomparable to Security Level 2 - If the categories of
Security Level 1 and Security Level 2 cannot be compared (i.e. neither Security
Level dominates the other).
To illustrate the usage of these rules, Table 2 lists the security level attributes in a
table to show example files (or documents) that have been allocated labels such as
s3:c0. The process that accesses these files (e.g. an editor) is running with a range
of s0 - s3:c1.c5 and has access to the files highlighted within the grey box area.
As the MLS dominance statement is used to enforce the sensitivity hierarchy, the
security levels now follow that sequence (lowest = s0 to highest = s3) with the
categories being unordered lists of 'compartments'. To allow the process access to
files within its scope and within the dominance rules, the process will be constrained
by using the mlsconstrain statement as illustrated in Figure 2.9.
Category  c0 c1 c2 c3 c4 c5 c6 c7
s3 Secret s3:c0 s3:c5 s3:c6
s2 Confidential s2:c1 s2:c2 s2:c3 s2:c4 s2:c7
s1 Restricted s1:c0 s1:c1 s1:c7
s0 Unclassified s0:c0 s0:c3 s0:c7
   File Labels 
Sensitivity Security Level A process running with a range of s0 - s3:c1.c5 has access to the files
(sensitivity:category) within the grey boxed area.
aka: classification

Table 2: MLS Security Levels - Showing the scope of a process running at a
security range of s0 - s3:c1.c5.

mlsconstrain file write ( l1 domby l2 ); # Write Up

s3:c5 Incomparable

s2:c1, c2, c3, c4 Dominates

s1:c1 Dominated By

s0:c3 Dominated By

mlsconstrain file read ( l1 dom l2 ); # Read Down

Figure 2.9: Showing the mlsconstrain Statements controlling Read Down &
Write Up - This ties in with Table 2 that shows a process running with a security
range of s0 - s3:c1.c5.

Page 52
The SELinux Notebook

Using Figure 2.9:
1. To allow write-up, the source level (l1) must be dominated by the target
level (l2):
Source level = s0:c3 or s1:c1
Target level = s2:c1.c4
As can be seen, either of the source levels are dominated by the target level.
2. To allow read-down, the source level (l1) must dominate the target level
(l2):
Source level = s2:c1.c4
Target level = s0:c3
As can be seen, the source level does dominate the target level.
However in the real world the SELinux MLS Reference Policy does not allow the
write-up unless the process has a special privilege (by having the domain type added
to an attribute), although it does allow the read-down. The default is to use l1 eq
l2 (i.e. the levels are equal). The reference policy MLS source file (policy/mls)
shows these mlsconstrain statements.

2.13.3 MLS Labeled Network and Database Support
Networking for MLS is supported via the NetLabel CIPSO (commercial IP security
option) service as discussed in the SELinux Networking Support section.
PostgreSQL supports labeling for MLS database services as discussed in the SE-
PostgreSQL section.

2.13.4 Common Criteria Certification
While the Common Criteria certification process is beyond the scope of this
Notebook, it is worth highlighting that specific Red Hat GNU / Linux versions of
software, running on specific hardware platforms with SELinux / MLS policy
enabled, have passed the Common Criteria evaluation process. Note, for the
evaluation (and deployment) the software and hardware are tied together, therefore
whenever an update is carried out, an updated certificate should be obtained.
The Red Hat evaluation process cover the:
• Labeled Security Protection Profile (LSPP ) - This describes how systems that
implement security labels (i.e. MLS) should function.
• Controlled Access Protection Profile (CAPP) - This describes how systems
that implement DAC should function.
An interesting point:
• Both Red Hat Linux 5.1 and Microsoft Server 2003 (with XP) have both been
certified to EAL4+ , however while the evaluation levels may be the same the
Protection Profiles that they were evaluated under were: Microsoft CAPP
only, Red Hat CAPP and LSPP. Therefore always look at the protection
profiles as they define what was actually evaluated.

Page 53
The SELinux Notebook

2.14 Types of SELinux Policy
This section describes the different type of policy descriptions and versions that can
be found within SELinux.
The type of SELinux policy can described in a number of ways:
1. Source code - These can be described as: Example, Reference Policy or
Custom. They are generally written using either kernel policy language, m4
macro support with kernel policy language, or CIL.
2. They can also be classified as: Monolithic, Base Module or Loadable Module.
3. Policies can also be described by the type of policy functionality they provide
such as: targeted, mls, mcs, standard, strict or minimum.
4. Classified using language statements - These can be described as Modular,
Optional or Conditional.
5. Binary policy (or kernel policy) - These can be described as Monolithic,
Kernel Policy or Binary file.
6. Classification can also be on the 'policy version' used (examples are version
22, 23 and 24).
As can be seen the description of a policy can vary depending on the context.

2.14.1 Example Policy
The Example policy is the name used to describe the original SELinux policy source
used to build a monolithic12 policy produced by the NSA and is now superseded by
the Reference Policy.

2.14.2 Reference Policy
Note that this section only gives an introduction to the Reference Policy, the
installation, configuration and building of a policy using this is contained in The
Reference Policy section.
The Reference Policy is now the standard policy source used to build Linux based
SELinux policies, and its main aim is to provide a single source tree with supporting
documentation that can be used to build policies for different purposes such as
confining important daemons, supporting MLS / MCS and locking down systems so
that all processes are under SELinux control.
The Reference Policy is now used by all major distributions of Linux, however each
distribution makes its own specific changes to support their 'version of the Reference
Policy'. For example, the F-20 distribution is based on a specific build of the standard
Reference Policy that is then modified and distributed by Red Hat as a number of
RPMs.

12
The term 'monolithic' generally means a single policy source is used to create the binary policy file
that is then loaded as the 'policy' using the checkpolicy(8) command. However the term is
sometimes used to refer to the binary policy file (as it is one file that describes the policy).

Page 54
The SELinux Notebook

2.14.3 Policy Functionality Based on Name or Type
Generally a policy is installed with a given name such as targeted, mls,
refpolicy or minimum that attempts to describes its functionality. This name then
becomes the entry in:
1. The directory pointing to the policy location (e.g. if the name is targeted,
then the policy will be installed in /etc/selinux/targeted).
2. The SELINUXTYPE entry in the /etc/selinux/config file when it is
the active policy (e.g. if the name is targeted, then a
SELINUXTYPE=targeted entry would be in the
/etc/selinux/config file).
This is how the reference policies distributed with F-20 are named, where:
minimum - supports a minimal set of confined daemons within their own
domains. The remainder run in the unconfined_t space. Red Hat pre-
configure MCS support within this policy.
targeted - supports a greater number of confined daemons and can also
confine other areas and users. Red Hat pre-configure MCS support within this
policy.
mls - supports server based MLS systems.
The Reference Policy also has a TYPE description that describes the type of policy
being built by the build process, these are:
standard - supports confined daemons and can also confine other areas and
users (this is an amalgamated version of the older 'targeted' and 'strict' versions).
mcs - As standard but supports MCS labels.
mls - supports server based MLS systems.
The NAME and TYPE entries are defined in the reference policy build.conf file
that is described in the Source Configuration Files section.

2.14.4 Custom Policy
This generally refers to a policy source that is either:
1. A customised version of the Example policy.
2. A customised version of the Reference Policy (i.e. not the standard
distribution version e.g. Red Hat policies).
3. A policy that has been built using policy language statements to build a
specific policy such as the basic policy built in the Notebook source tarball.

2.14.5 Monolithic Policy
A Monolithic policy is an SELinux policy that is compiled from one source file called
(by convention) policy.conf (i.e. it does not use the Loadable Module Policy
statements and infrastructure which therefore makes it suitable for embedded systems
as there is no policy store overhead).

Page 55
The SELinux Notebook

An example monolithic policy is the NSAs original Example Policy.
Monolithic policies are compiled using the checkpolicy (8) SELinux command.
The Reference Policy supports the building of monolithic policies.
In some cases the kernel policy binary file (see the Binary Policy section) is also
called a monolithic policy.

2.14.6 Loadable Module Policy
The loadable module infrastructure allows policy to be managed on a modular basis,
in that there is a base policy module that contains all the core components of the
policy (i.e. the policy that should always be present), and zero or more modules that
can be loaded and unloaded as required (for example if there is a module to enforce
policy for ftp, but ftp is not used, then that module could be unloaded).
There are number of components that form the infrastructure:
1. Policy source code that is constructed for a modular policy with a base module
and optional loadable modules.
2. Utilities to compile and link modules and place them into a 'policy store'.
3. Utilities to manage the modules and associated configuration files within the
'policy store'.
Figure 2.2 shows these components along the top of the diagram. The files contained
in the policy store are detailed in the Policy Store Configuration Files section.
The policy language was extended to handle loadable modules as detailed in the
Policy Support Statements section. For a detailed overview on how the modular
policy is built into the final binary policy for loading into the kernel, see "SELinux
Policy Module Primer" [3].

2.14.6.1 Optional Policy
The loadable module policy infrastructure supports an optional policy statement that
allows policy rules to be defined but only enabled in the binary policy once the
conditions have been satisfied.

2.14.7 Conditional Policy
Conditional policies can be implemented in monolithic or loadable module policies
and allow parts of the policy to be enabled or not depending on the state of a boolean
flag at run time. This is often used to enable or disable features within the policy (i.e.
change the policy enforcement rules).
The boolean flag status is held in kernel and can be changed using the
setsebool(8) command either persistently across system re-boots or temporarily
(i.e. only valid until a re-boot). The following example shows a persistent conditional
policy change:
setsebool -P ext_gateway_audit false

Page 56
The SELinux Notebook

The conditional policy language statements are the bool Statement that defines the
boolean flag identifier and its initial status, and the if Statement that allows certain
rules to be executed depending on the state of the boolean value or values.

2.14.8 Binary Policy
This is also know as the kernel policy and is the policy file that is loaded into the
kernel and is located at
/etc/selinux/<SELINUXTYPE>/policy/policy.<version>. Where
<SELINUXTYPE> is the policy name specified in the SELinux configuration file
/etc/selinux/config and <version> is the SELinux policy version.
The binary policy can be built from source files supplied by the Reference Policy or
custom built source files.
An example /etc/selinux/config file is shown below where the
SELINUXTYPE=targeted entry identifies the policy name that will be used to
locate and load the active policy:
SELINUX=permissive

SELINUXTYPE=targeted

From the above example, the actual binary policy file would be located at
/etc/selinux/targeted/policy and be called policy.29 (as version 29
is supported by F-20):
/etc/selinux/targeted/policy/policy.29

2.14.9 Policy Versions
SELinux has a policy database (defined in the libsepol library) that describes the
format of data held within a binary policy, however, if any new features are added to
SELinux (generally language extensions) this can result in a change to the policy
database. Whenever the policy database is updated, the policy version is incremented.
The sestatus(8) command will show the maximum policy version supported by
the kernel in its output as follows:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
Loaded policy name targeted
Current mode: enforcing
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 29

Table 3 describes the different versions, although note that there is also another
version that applies to the modular policy, however the main policy database version
is the one that is generally quoted (some SELinux utilities give both version
numbers).

Page 57
The SELinux Notebook

policy db modular db
Version Version
Description
15 4 The base version when SELinux was merged into the
kernel.
16 - Added Conditional Policy support (the bool feature).
17 - Added support for IPv6.
18 - Added Netlink support.
19 5 Added MLS support, plus the validatetrans
Statement.
20 - Reduced the size of the access vector table.
21 6 Added support for the MLS range_transition
Statement.
22 7 Added policy capabilities that allows various kernel options
to be enabled as described in the SELinux Filesystem
section.
23 8 Added support for the permissive statement. This
allows a domain to run in permissive mode while the others
are still confined (instead of the all or nothing set by the
SELINUX entry in the /etc/selinux/config file).
24 9 / 10 Add support for the typebounds statement. This was
added to support a hierarchical relationship between two
domains in multi-threaded web servers as described in "A
secure web application platform powered by SELinux"
[16].
25 11 Add support for file name transition in the
type_transition rule. Requires kernel 2.6.39
minimum.
26 12/13 Add support for a class parameter in the
role_transition rule.
Add support for the attribute_role and
roleattribute statements.
These require kernel 2.6.39 minimum.
- 14 Separate tunables.
27 15 Support setting object defaults for the user, role and range
components when computing a new context. Requires
kernel 3.5 minimum.
28 16 Support setting object defaults for the type component
when computing a new context. Requires kernel 3.5
minimum.
29 17 Support attribute names within constraints. This allows
attributes as well as the types to be retrieved from a kernel
policy to assist audit2allow(8) etc. to determine what
attribute needs to be updated. Note that the attribute does
not determine the constraint outcome, it is still the list of

Page 58
The SELinux Notebook

policy db modular db
Version Version
Description
types associated to the constraint. Requires kernel 3.14
minimum.
Table 3: Policy version descriptions

2.15 SELinux Permissive and Enforcing Modes
SELinux has three major modes of operation:
Enforcing - SELinux is enforcing the loaded policy.
Permissive - SELinux has loaded the policy, however it is not enforcing the
policy rules. This is generally used for testing as the audit log will contain the
AVC denied messages as defined in the Auditing SELinux Events section. The
SELinux utilities such as audit2allow(1) and audit2why(8) can then be
used to determine the cause and possible resolution by generating the appropriate
allow rules.
Disabled - The SELinux infrastructure is not enabled, therefore no policy can be
loaded.
These flags are set in the /etc/selinux/config file as described in the Global
Configuration Files section.
There is another method for running specific domains in permissive mode using the
permissive statement. This can be used directly in a user written module or
semanage(8) will generate the appropriate module and load it using the following
example command:
# This example will add a new module in
# /etc/selinux/<SELINUXTYPE>/modules/active/modules/permissive_unconfined_t.pp
# and then reload the policy:

semanage permissive -a unconfined_t

It is also possible to set permissive mode on a userspace object manager using the
libselinux function avc_open(3), for example the X-Windows object
manager uses avc_open to set whether it will always run permissive, enforcing or
follow the current SELinux enforcement mode.
The sestatus(8) command will show the current SELinux enforcement mode in
its output, however it does not display individual domain or object manager
enforcement modes.

2.16 Auditing SELinux Events
For SELinux there are two main types of audit event:
1. AVC Audit Events - These are generated by the AVC subsystem as a result of
access denials, or where specific events have requested an audit message (i.e.
where an auditallow rule has been used in the policy).
2. SELinux-aware Application Events - These are generated by the SELinux
kernel services and SELinux-aware applications for events such as system

Page 59
The SELinux Notebook

errors, initialisation, policy load, changing boolean states, setting of
enforcing / permissive mode, relabeling etc.
The audit and event messages are generally stored in one of the following logs (in F-
20 anyway):
1. The SELinux kernel boot events are logged in the /var/log/dmesg log.
2. The system log /var/log/messages contains messages generated by
SELinux before the audit daemon has been loaded, although some kernel
messages continue to be logged here as well13.
3. The audit log /var/log/audit/audit.log contains events that take
place after the audit daemon has been loaded. The AVC audit messages of
interest are described in the AVC Audit Events section with others described
in the General SELinux Audit Events section. F-20 uses the audit framework
auditd(8) as standard.
Notes:
a) It is not mandatory for SELinux-aware applications to audit events or even log
them in the audit log. The decision is made by the application designer.
b) The format of audit messages do not need to conform to any format, however
where possible applications should use the
audit_log_user_avc_message(3) function with a suitably formatted
message if using auditd(8). The type of audit events possible are defined
in the include/libaudit.h and include/linux/audit.h files.
c) Those libselinux library functions that output messages do so to stderr by
default, however this can be changed by calling
selinux_set_callback(3) and specifying an alternative log handler.

2.16.1 AVC Audit Events
Table 4 describes the general format of AVC audit messages in the audit.log
when access has been denied or an audit event has been specifically requested. Other
types of events are shown in the section that follows.
Keyword Description
type For SELinux AVC events this can be:
type=AVC - for kernel events
type=USER_AVC - for user-space object manager events
Note that once the AVC event has been logged, another event with
type=SYSCALL may follow that contains further information
regarding the event.
The AVC event can always be tied to the relevant SYSCALL event
as they have the same serial_number in the
msg=audit(time:serial_number) field as shown in the
13
For example if the iptables are loaded and there are SECMARK security contexts present, but the
contexts are invalid (i.e. not in the policy), then the event is logged in the messages log not the
audit log.

Page 60
The SELinux Notebook

Keyword Description
following example:
type=AVC msg=audit(1243332701.744:101): avc: denied
{ getattr } for pid=2714 comm="ls"
path="/usr/lib/locale/locale-archive" dev=dm-0 ino=353593
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:locale_t:s0 tclass=file

type=SYSCALL msg=audit(1243332701.744:101): arch=40000003
syscall=197 success=yes exit=0 a0=3 a1=553ac0 a2=552ff4
a3=bfc5eab0 items=0 ppid=2671 pid=2714 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="ls"
exe="/bin/ls" subj=system_u:object_r:unlabeled_t:s0 key=(null)

msg This will contain the audit keyword with a reference number (e.g.
msg=audit(1243332701.744:101))
avc This will be either denied when access has been denied or
granted when an auditallow rule has been defined by the
policy.
The entries that follow the avc= field depend on what type of
event is being audited. Those shown below are generated by the
kernel AVC audit function, however the user space AVC audit
function will return fields relevant to the application being
managed by their Object Manager.
pid If a task, then log the process id (pid) and the name of the
comm executable file (comm).

capability If a capability event then log the identifier.
path If a File System event then log the relevant information. Note that
name the name field may not always be present.

dev
ino
laddr If a Socket event then log the Source / Destination addresses and
lport ports for IP4 or IP6 sockets (AF_INET).

faddr
fport
path If a File Socket event then log the path (AF_UNIX).
saddr If a Network event then log the Source / Destination addresses and
src ports with the network interface for IP4 or IP6 networks
(AF_INET).
daddr
dest
netif
sauid IPSec security association identifiers
hostname

Page 61
The SELinux Notebook

Keyword Description
addr
terminal
resid X-Windows resource ID and type.
restype
scontext The security context of the source or subject.
tcontext The security context of the target or object.
tclass The object class of the target or object.

Table 4: AVC Audit Message Description - The keywords in bold are in all AVC
audit messages, the others depend on the type of event being audited.
Example audit.log denied and granted events are shown in the following
examples:
# This is an example denied message - note that there are two
# type=AVC calls, but only one corresponding type=SYSCALL entry.
type=AVC msg=audit(1242575005.122:101): avc: denied { rename } for pid=2508
comm="canberra-gtk-pl" name="c73a516004b572d8c845c74c49b2511d:runtime.tmp"
dev=dm-0 ino=188999 scontext=test_u:staff_r:oddjob_mkhomedir_t:s0
tcontext=test_u:object_r:gnome_home_t:s0 tclass=lnk_file

type=AVC msg=audit(1242575005.122:101): avc: denied { unlink } for pid=2508
comm="canberra-gtk-pl" name="c73a516004b572d8c845c74c49b2511d:runtime" dev=dm-0
ino=188578 scontext=test_u:staff_r:oddjob_mkhomedir_t:s0
tcontext=system_u:object_r:gnome_home_t:s0 tclass=lnk_file

type=SYSCALL msg=audit(1242575005.122:101): arch=40000003 syscall=38 success=yes
exit=0 a0=82d2760 a1=82d2850 a2=da6660 a3=82cb550 items=0 ppid=2179 pid=2508
auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=(none) ses=1 comm="canberra-gtk-pl" exe="/usr/bin/canberra-gtk-play"
subj=test_u:staff_r:oddjob_mkhomedir_t:s0 key=(null)

# These are example X-Windows object manager audit message:
type=USER_AVC msg=audit(1267534171.023:18): user pid=1169 uid=0 auid=4294967295
ses=4294967295 subj=system_u:unconfined_r:unconfined_t msg='avc: denied
{ getfocus } for request=X11:GetInputFocus comm=X-setest xdevice="Virtual core
keyboard" scontext=unconfined_u:unconfined_r:x_select_paste_t
tcontext=system_u:unconfined_r:unconfined_t tclass=x_keyboard :
exe="/usr/bin/Xorg" sauid=0 hostname=? addr=? terminal=?'

type=USER_AVC msg=audit(1267534395.930:19): user pid=1169 uid=0 auid=4294967295
ses=4294967295 subj=system_u:unconfined_r:unconfined_t msg='avc: denied { read
} for request=SELinux:SELinuxGetClientContext comm=X-setest resid=3c00001
restype=<unknown> scontext=unconfined_u:unconfined_r:x_select_paste_t
tcontext=unconfined_u:unconfined_r:unconfined_t tclass=x_resource :
exe="/usr/bin/Xorg" sauid=0 hostname=? addr=? terminal=?'

# This is an example granted audit message:
type=AVC msg=audit(1239116352.727:311): avc: granted { transition } for
pid=7687 comm="bash" path="/usr/move_file/move_file_c" dev=dm-0 ino=402139
scontext=unconfined_u:unconfined_r:unconfined_t
tcontext=unconfined_u:unconfined_r:move_file_t tclass=process

type=SYSCALL msg=audit(1239116352.727:311): arch=40000003 syscall=11 success=yes
exit=0 a0=8a6ea98 a1=8a56fa8 a2=8a578e8 a3=0 items=0 ppid=2660 pid=7687 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1

Page 62
The SELinux Notebook

comm="move_file_c" exe="/usr/move_file/move_file_c"
subj=unconfined_u:unconfined_r:move_file_t key=(null)

2.16.2 General SELinux Audit Events
This section shows a selection of non-AVC SELinux-aware services audit events
taken from the audit.log. For a list of valid type= entries, the following include
files should be consulted: include/libaudit.h and
include/linux/audit.h.
Note that there can be what appears to be multiple events being generated for the
same event. For example the kernel security server will generate a
MAC_POLICY_LOAD event to indicate that the policy has been reloaded, but then
each userspace object manager could then generate a USER_MAC_POLICY_LOAD
event to indicate that it had also processed the event.
Policy reload - MAC_POLICY_LOAD, USER_MAC_POLICY_LOAD - These events
were generated when the policy was reloaded.
type=MAC_POLICY_LOAD msg=audit(1336662937.117:394): policy loaded auid=0 ses=2
type=SYSCALL msg=audit(1336662937.117:394): arch=c000003e syscall=1 success=yes
exit=4345108 a0=4 a1=7f0a0c547000 a2=424d14 a3=7fffe3450f20 items=0 ppid=3845
pid=3848 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2
ses=2 comm="load_policy" exe="/sbin/load_policy"
subj=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 key=(null)

type=USER_MAC_POLICY_LOAD msg=audit(1336662938.535:395): pid=0 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:xserver_t:s0-s0:c0.c1023
msg='avc: received policyload notice (seqno=2) : exe="/usr/bin/Xorg" sauid=0
hostname=? addr=? terminal=?'

Change enforcement mode - MAC_STATUS - This was generated when the SELinux
enforcement mode was changed:
type=MAC_STATUS msg=audit(1336836093.835:406): enforcing=1 old_enforcing=0
auid=0 ses=2
type=SYSCALL msg=audit(1336836093.835:406): arch=c000003e syscall=1 success=yes
exit=1 a0=3 a1=7fffe743f9e0 a2=1 a3=0 items=0 ppid=2047 pid=5591 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2
comm="setenforce" exe="/usr/sbin/setenforce"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Change boolean value - MAC_CONFIG_CHANGE - This event was generated when
setsebool(8) was run to change a boolean. Note that the bolean name plus new
and old values are shown in the MAC_CONFIG_CHANGE type event with the
SYSCALL event showing what process executed the change.
type=MAC_CONFIG_CHANGE msg=audit(1336665376.629:423):
bool=domain_paste_after_confirm_allowed val=0 old_val=1 auid=0 ses=2
type=SYSCALL msg=audit(1336665376.629:423): arch=c000003e syscall=1 success=yes
exit=2 a0=3 a1=7fff42803200 a2=2 a3=7fff42803f80 items=0 ppid=2015 pid=4664
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2
comm="setsebool" exe="/usr/sbin/setsebool"
subj=unconfined_u:unconfined_r:setsebool_t:s0-s0:c0.c1023 key=(null)

Page 63
The SELinux Notebook

NetLabel - MAC_UNLBL_STCADD - Generated when adding a static non-mapped
label. There are many other NetLabel events possible, such as: MAC_MAP_DEL,
MAC_CIPSOV4_DEL ...
type=MAC_UNLBL_STCADD msg=audit(1336664587.640:413): netlabel: auid=0 ses=2
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 netif=lo
src=127.0.0.1 sec_obj=system_u:object_r:unconfined_t:s0-s0:c0,c100 res=1
type=SYSCALL msg=audit(1336664587.640:413): arch=c000003e syscall=46 success=yes
exit=96 a0=3 a1=7fffde77f160 a2=0 a3=666e6f636e753a72 items=0 ppid=2015 pid=4316
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2
comm="netlabelctl" exe="/sbin/netlabelctl"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Labeled IPSec - MAC_IPSEC_EVENT - Generated when running setkey(8) to
load IPSec configuration:
type=MAC_IPSEC_EVENT msg=audit(1336664781.473:414): op=SAD-add auid=0 ses=2
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 sec_alg=1 sec_doi=1
sec_obj=system_u:system_r:postgresql_t:s0-s0:c0,c200 src=127.0.0.1 dst=127.0.0.1
spi=592(0x250) res=1
type=SYSCALL msg=audit(1336664781.473:414): arch=c000003e syscall=44 success=yes
exit=176 a0=4 a1=7fff079d5100 a2=b0 a3=0 items=0 ppid=2015 pid=4356 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="setkey"
exe="/sbin/setkey" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key=(null)

SELinux kernel errors - SELINUX_ERR - These example events were generated by
the kernel security server. These were generated by the kernel security server because
anon_webapp_t has been give privileges that are greater than that given to the
process that started the new thread (this is not allowed).
type=SELINUX_ERR msg=audit(1311948547.151:138): op=security_compute_av
reason=bounds scontext=system_u:system_r:anon_webapp_t:s0-s0:c0,c100,c200
tcontext=system_u:object_r:security_t:s0 tclass=dir perms=ioctl,read,lock

type=SELINUX_ERR msg=audit(1311948547.151:138): op=security_compute_av
reason=bounds scontext=system_u:system_r:anon_webapp_t:s0-s0:c0,c100,c200
tcontext=system_u:object_r:security_t:s0 tclass=file
perms=ioctl,read,write,getattr,lock,append,open

These were generated by the kernel security server when an SELinux-aware
application was trying to use setcon(3) to create a new thread. To fix this a
typebounds statement is required in the policy.
type=SELINUX_ERR msg=audit(1311947138.440:126): op=security_bounded_transition
result=denied oldcontext=system_u:system_r:httpd_t:s0-s0:c0.c300
newcontext=system_u:system_r:anon_webapp_t:s0-s0:c0,c100,c200

type=SYSCALL msg=audit(1311947138.440:126): arch=c000003e syscall=1 success=no
exit=-1 a0=b a1=7f1954000a10 a2=33 a3=6e65727275632f72 items=0 ppid=3295
pid=3473 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=system_u:system_r:httpd_t:s0-s0:c0.c300 key=(null)

Role changes - USER_ROLE_CHANGE - Used newrole(1) to set a new role that
was not valid.

Page 64
The SELinux Notebook

type=USER_ROLE_CHANGE msg=audit(1336837198.928:429): pid=0 uid=0 auid=0 ses=2
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='newrole: old-
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 new-context=?:
exe="/usr/bin/newrole" hostname=? addr=? terminal=/dev/pts/0 res=failed'

2.17 Polyinstantiation Support
GNU / Linux supports the polyinstantiation of directories that can be utilised by
SELinux via the Pluggable Authentication Module (PAM) that is explained in the
next section. The "Polyinstantiation of directories in an SELinux system" [4] also
gives a more detailed overview of the subject.
Polyinstantiation of objects is also supported for X-windows selections and properties
that are discussed in the X-windows section. Note that sockets are not yet supported.
To clarify polyinstantiation support:
1. SELinux has libselinux functions and a policy rule to support
polyinstantiation.
2. The polyinstantiation of directories is a function of GNU / Linux not SELinux
(as more correctly, the GNU / Linux services such as PAM have been
modified to support polyinstantiation of directories and have also been made
SELinux-aware. Therefore their services can be controlled via policy).
3. The polyinstantiation of X-windows selections and properties is a function of
the XSELinux Object Manager and the supporting XACE service.

2.17.1 Polyinstantiated Objects
Determining a polyinstantiated context for an object is supported by SELinux using
the policy language type_member statement and the
avc_compute_member(3) and security_compute_member(3)
libselinux API functions. These are not limited to specific object classes,
however only dir, x_selection and x_property objects are currently
supported.

2.17.2 Polyinstantiation support in PAM
PAM supports polyinstantiation (namespaces) of directories at login time using the
Shared Subtree / Namespace services available within GNU / Linux (the
namespace.conf(5) man page is a good reference). Note that PAM and
Namespace services are SELinux-aware.
The default installation of F-20 does not enable polyinstantiated directories, therefore
this section will show the configuration required to enable the feature and some
examples.
To implement polyinstantiated directories PAM requires the following files to be
configured:
1. A pam_namespace module entry added to the appropriate /etc/pam.d/
login configuration file (e.g. login, sshd, gdm etc.). F-20 already has these

Page 65
The SELinux Notebook

entries configured, with an example /etc/pam.d/gdm-password file
being:
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth substack password-auth
auth optional pam_gnome_keyring.so
auth include postlogin

account required pam_nologin.so
account include password-auth

password include password-auth

session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
-session optional pam_ck_connector.so
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session include password-auth
session optional pam_gnome_keyring.so auto_start
session include postlogin

2. Entries added to the /etc/security/namespace.conf file that defines
the directories to be polyinstantiated by PAM (and other services that may
need to use the namespace service). The entries are explained in the
namespace.conf Configuration File section, with the default entries in F-
20 being (note that the entries are commented out in the distribution):
#polydir instance-prefix method list_of_uids
/tmp /tmp-inst/ level root,adm
/var/tmp /var/tmp/tmp-inst/ level root,adm
$HOME $HOME/$USER.inst/ level

Once these files have been configured and a user logs in (although not root or adm
in the above example), the PAM pam_namespace module would unshare the
current namespace from the parent and mount namespaces according to the rules
defined in the namespace.conf file. The F-20 configuration also includes an
/etc/security/namespace.init script that is used to initialise the
namespace every time a new directory instance is set up. This script receives four
parameters: the polyinstantiated directory path, the instance directory path, a flag to
indicate if a new instance, and the user name. If a new instance is being set up, the
directory permissions are set and the restorecon(8) command is run to set the
correct file contexts.

2.17.2.1 namespace.conf Configuration File
Each line in the namespace.conf file is formatted as follows:

polydir instance_prefix method list_of_uids

Where:
polydir The absolute path name of the directory to
polyinstantiate. The optional strings $USER and $HOME
will be replaced by the user name and home directory

Page 66
The SELinux Notebook

respectively.
instance_prefix A string prefix used to build the pathname for the
polyinstantiated directory. The optional strings $USER
and $HOME will be replaced by the user name and home
directory respectively.
method This is used to determine the method of
polyinstantiation with valid entries being:
user - Polyinstantiation is based on user name.
level - Polyinstantiation is based on the user name
and MLS level.
context - Polyinstantiation is based on the user
name and security context.
Note that level and context are only valid for
SELinux enabled systems.
list_of_uids A comma separated list of user names that will not have
polyinstantiated directories. If blank, then all users are
polyinstantiated. If the list is preceded with an '~'
character, then only the users in the list will have
polyinstantiated directories.
There are a number of optional flags available that are
described in the namespace.conf(5) man page.

2.17.2.2 Example Configurations
This section shows two sample namespace.conf configurations, the first uses the
method=user and the second method=context. It should be noted that while
polyinstantiation is enabled, the full path names will not be visible, it is only when
polyinstantiation is disabled that the directories become visible.

Example 1 - method=user:
1. Set the /etc/security/namespace.conf entries as follows:

#polydir instance-prefix method list_of_uids
/tmp /tmp-inst/ user root,adm
/var/tmp /var/tmp/tmp-inst/ user root,adm
$HOME $HOME/$USER.inst/ user

2. Login as a normal user (rch in this example) and the PAM / Namespace
process will build the following polyinstantiated directories:
# The directories will contain the user name as a part of
# the polyinstantiated directory name as follows:

# /tmp
/tmp/tmp-inst/rch

# /var/tmp:

Page 67
The SELinux Notebook

/var/tmp/tmp-inst/rch

# $HOME
/home/rch/rch.inst/rch

Example 2 - method=context:
1. Set the /etc/security/namespace.conf entries as follows:

#polydir instance-prefix method list_of_uids
/tmp /tmp-inst/ context root,adm
/var/tmp /var/tmp/tmp-inst/ context root,adm
$HOME $HOME/$USER.inst/ context

2. Login as a normal user (rch in this example) and the PAM / Namespace
process will build the following polyinstantiated directories:
# The directories will contain the security context and
# user name as a part of the polyinstantiated directory
# name as follows:

# /tmp
/tmp/tmp-inst/unconfined_u:unconfined_r:unconfined_t_rch

# /var/tmp:
/var/tmp/tmp-inst/unconfined_u:unconfined_r:unconfined_t_rch

# $HOME
/home/rch/rch.inst/unconfined_u:unconfined_r:unconfined_t_rch

2.17.3 Polyinstantiation support in X-Windows
The X-Windows SELinux object manager and XACE (X Access Control Extension)
supports x_selection and x_property polyinstantiated objects as discussed in
the SELinux X-windows Support section.

2.17.4 Polyinstantiation support in the Reference Policy
The reference policy files.te and files.if modules (in the kernel layer)
support polyinstantiated directories. There is also a global tunable (a boolean called
allow_polyinstantiation) that can be used to set this functionality on or off
during login. By default this boolean is set false (off).
The polyinstantiation of X-Windows objects (x_selection and x_property)
are not currently supported by the reference policy.

2.18 PAM Login Process
Applications used to provide login services (such as gdm and ssh) in F-20 use the
PAM (Pluggable Authentication Modules) infrastructure to provide the following
services:

Page 68
The SELinux Notebook

Account Management - This manages services such as password expiry, service
entitlement (i.e. what services the login process is allowed to access).
Authentication Management - Authenticate the user or subject and set up the
credentials. PAM can handle a variety of devices including smart-cards and
biometric devices.
Password Management - Manages password updates as needed by the specific
authentication mechanism being used and the password policy.
Session Management - Manages any services that must be invoked before the
login process completes and / or when the login process terminates. For SELinux
this is where hooks are used to manage the domains the subject may enter.
The pam and pam.conf man pages describe the services and configuration in detail
and only a summary is provided here covering the SELinux services.
The PAM configuration for F-20 is managed by a number of files located in the
/etc/pam.d directory which has configuration files for login services such as:
gdm, gdm-autologin, login, remote and sshd, and at various points in this
Notebook the gdm configuration file has been modified to allow root login and the
pam_namespace.so module used to manage polyinstantiated directories for users.
There are also a number of PAM related configuration files in /etc/security,
although only one is directly related to SELinux that is described in the
/etc/security/sepermit.conf file section.
The main login service related PAM configuration files (e.g. gdm) consist of multiple
lines of information that are formatted as follows:
service type control module-path arguments

Where:
service The service name such as gdm and login reflecting the
login application. If there is a /etc/pam.d directory, then
this is the name of a configuration file name under this
directory. Alternatively, a configuration file called
/etc/pam.conf can be used. F-20 uses the /etc/pam.d
configuration.
type These are the management groups used by PAM with valid
entries being: account, auth, password and session
that correspond to the descriptions given above. Where there
are multiple entries of the same 'type', the order they appear
could be significant.
control This entry states how the module should behave when the
requested task fails. There can be two formats: a single
keyword such as required, optional, and include; or
multiple space separated entries enclosed in square brackets
consisting of :
[value1=action1 value2=action2 ..]

Page 69
The SELinux Notebook

Both formats are shown in the example file below, however
see the pam.conf man pages for the gory details.
module-path Either the full path name of the module or its location relative
to /lib/security (but does depend on the system
architecture).
arguments A space separated list of the arguments that are defined for
the module.

An example PAM configuration file is as follows, although note that the 'service'
parameter is actually the file name because F-20 uses the /etc/pam.d directory
configuration (in this case gdm-password for the Gnome login service).
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth substack password-auth
auth optional pam_gnome_keyring.so
auth include postlogin

account required pam_nologin.so
account include password-auth

password include password-auth

session required pam_selinux.so close debug
session required pam_loginuid.so
session optional pam_console.so
-session optional pam_ck_connector.so
session required pam_selinux.so open debug
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session include password-auth
session optional pam_gnome_keyring.so auto_start
session include postlogin

The core services are provided by PAM, however other library modules can be
written to manage specific services such as support for SELinux. The SELinux PAM
modules use the libselinux API to obtain its configuration information and the
three SELinux PAM entries highlighted in the above configuration file perform the
following functions:
pam_selinux_permit.so - Allows pre-defined users the ability to logon
without a password provided that SELinux is in enforcing mode (see the
/etc/security/sepermit.conf file section).
pam_selinux.so open - Allows a security context to be set up for the user at
initial logon (as all programs exec'ed from here will use this context). How the
context is retrieved is described in the seusers configuration file section.
pam_selinux.so close - This will reset the login programs context to the
context defined in the policy.

2.19 Linux Security Module and SELinux
This section gives a high level overview of the LSM and SELinux internal kernel
structure and workings as enabled in kernel 3.14. A more detailed view can be found
in the "Implementing SELinux as a Linux Security Module" [1] that was used

Page 70
The SELinux Notebook

extensively to develop this section (and also using the SELinux kernel source code).
The major areas covered are:
1. How the LSM and SELinux modules work together.
2. The major SELinux internal services.
3. The fork and exec system calls are followed through as an example to tie in
with the transition process covered in the Domain Transition section.
4. The SELinux filesystem /sys/fs/selinux.
5. The /proc filesystem area most applicable to SELinux.

2.19.1 The LSM Module
The LSM is the Linux security framework that allows 3 rd party access control
mechanisms to be linked into the GNU / Linux kernel. Currently there are five 3 rd
party services that utilise the LSM:
1. SELinux - the subject of this Notebook.
2. AppArmor is a MAC service based on pathnames and does not require
labeling or relabeling of filesystems. See http://wiki.apparmor.net for details.
3. Simplified Mandatory Access Control Kernel (SMACK). See
http://www.schaufler-ca.com/ for details.
4. Tomoyo that is a name based MAC and details can be found at
http://sourceforge.jp/projects/tomoyo/docs.
5. Yama extends the DAC support for ptrace. See
Documentation/security/Yama.txt for further details.
The basic idea behind LSM is to:
• Insert security function hooks and security data structures in the various kernel
services to allow access control to be applied over and above that already
implemented via DAC. The type of service that have hooks inserted are shown
in Table 5 with an example task and program execution shown in the Fork
Walk-thorough and Process Transition Walk-thorough sections.
• Allow registration and initialisation services for the 3rd party security modules.
• Allow process security attributes to be available to userspace services by
extending the /proc filesystem with a security namespace as shown in Table
6. These are located at:
/proc/<self | pid>/attr/<attr>
/proc/<self | pid>/task/<tid>/attr/<attr>
Where <pid> is the process id, <tid> is the thread id and <attr> is the
entry described in Table 6.
• Support filesystems that use extended attributes (SELinux uses
security.selinux as explained in the Labeling Extended Attribute
Filesystems section).
• Consolidate the Linux capabilities into an optional module.

Page 71
The SELinux Notebook

It should be noted that the LSM does not provide any security services itself, only the
hooks and structures for supporting 3rd party modules. If no 3rd party module is
loaded, the capabilities module becomes the default module thus allowing standard
DAC access control.
Program execution Filesystem operations Inode operations
File operations Task operations Netlink messaging
Unix domain networking Socket operations XFRM operations
Key Management operations IPC operations Memory Segments
Semaphores Capability Sysctl
Syslog Audit

Table 5: LSM Hooks - These are the kernel services that LSM has inserted security
hooks and structures to allow access control to be managed by 3rd party modules (see
./linux-3.14/include/linux/security.h).
/proc/self/attr/ Permissions Function
File Name
current -rw-rw-rw- Contains the current process security context.
exec -rw-rw-rw- Used to set the security context for the next exec call.
fscreate -rw-rw-rw- Used to set the security context of a newly created file.
keycreate -rw-rw-rw- Used to set the security context for keys that are cached in the
kernel.
prev -r--r--r-- Contains the previous process security context.
sockcreate -rw-rw-rw- Used to set the security context of a newly created socket.

Table 6: /proc Filesystem attribute files - These files are used by the kernel services
and libselinux (for userspace) to manage setting and reading of security contexts
within the LSM defined data structures.
The major kernel source files (relative to ./linux-3.14/security) that form
the LSM are shown in Table 7. However there is one major header file
(include/linux/security.h) that describes all the LSM security hooks and
structures.
Name Function
capability.c Some capability functions were in various kernel modules have been
consolidated into these source files.
commoncap.c
device_cgroup.c
inode.c This allows the 3rd party security module to initialise a security filesystem.
In the case of SELinux this would be /sys/fs/selinux that is defined
in the selinux/selinuxfs.c source file.
security.c Contains the LSM framework initialisation services that will set up the
hooks described in security.h and those in the capability source files.
It also provides functions to initialise 3rd party modules.
lsm_audit.c Contains common LSM audit functions.

Page 72
The SELinux Notebook

Name Function
min_addr.c Minimum VM address protection from userspace for DAC and LSM.

Table 7: The core LSM source modules.

2.19.2 The SELinux Module
This section does not go into detail of all the SELinux module functionality as the
Implementing SELinux as a Linux Security Module [1] does this (although a bit
dated), however it attempts to highlight the way some areas work by using the fork
and transition process example described in the Domain Transition section.
The major kernel SELinux source files (relative to ./linux-
3.14/security/selinux) that form the SELinux security module are shown
inTable 8. The diagrams shown in Figure 2.2 and Figure 2.12 can be used to see how
some of these kernel source modules fit together.
Name Function
avc.c Access Vector Cache functions and structures. The function calls are for
the kernel services, however they have been ported to form the
libselinux userspace library.
exports.c Exported SELinux services for SECMARK (as there is SELinux specific
code in the netfilter source tree).
hooks.c Contains all the SELinux functions that are called by the kernel resources
via the security_ops function table (they form the kernel resource
object managers). There are also support functions for managing process
exec's, managing SID allocation and removal, interfacing into the AVC
and Security Server.
netif.c These manage the mapping between labels and SIDs for the net*
language statements when they are declared in the active policy.
netnode.c
netport.c
netlabel.c The interface between NetLabel services and SELinux.
netlink.c Manages the notification of policy updates to resources including
userspace applications via libselinux.
nlmsgtab.c
selinuxfs.c The selinuxfs pseudo filesystem (/sys/fs/selinux) that
imports/exports security policy information to/from userspace services.
The services exported are shown in the SELinux Filesystem section.
xfrm.c Contains the IPSec XFRM (transform) hooks for SELinux.
include/classmap.h classmap.h contains all the kernel security classes and permissions.
include/initial_si initial_sid_to_string.h contains the initial SID contexts.
d_to_string.h These are used to build the flask.h and av_permissions.h
kernel configuration files when the kernel is being built (using the
genheaders script defined in the selinux/Makefile).
These files are built this way now to support the new dynamic security
class mapping structure to remove the need for fixed class to SID
mapping.
ss/avtab.c AVC table functions for inserting / deleting entries.
ss/conditional.c Support boolean statement functions and implements a conditional AV

Page 73
The SELinux Notebook

Name Function
table to hold entries.
ss/ebitmap.c Bitmaps to represent sets of values, such as types, roles, categories, and
classes.
ss/hashtab.c Hash table.
ss/mls.c Functions to support MLS.
ss/policydb.c Defines the structure of the policy database. See the "SELinux Policy
Module Primer" [3] article for details on the structure.
ss/services.c This contains the supporting services for kernel hooks defined in
hooks.c, the AVC and the Security Server.
For example the security_transition_sid that computes the
SID for a new subject / object shown in Figure 2.12.
ss/sidtab.c The SID table contains the security context indexed by its SID value.
ss/status.c Interface for selinuxfs/status. Used by the libselinux
selinux_status_*(3) functions.
ss/symtab.c Maintains associations between symbol strings and their values.

Table 8: The core SELinux source modules - The .h files and those in the
include directory have a number of useful comments.

2.19.2.1 Fork System Call Walk-thorough
This section walks through the the fork(2) system call shown in Figure 2.7 starting
at the kernel hooks that link to the SELinux services. The way the SELinux hooks are
initialised into the LSM security_ops function table are also described.
Using Figure 2.10, the major steps to check whether the unconfined_t process
has permission to use the fork permission are:
1. The kernel/fork.c has a hook that links it to the LSM function
security_task_create() that is called to check access permissions.
2. Because the SELinux module has been initialised as the security module, the
security_ops table has been set to point to the SELinux
selinux_task_create() function in hooks.c.
3. The selinux_task_create() function check whether the task has
permission via the current_has_perm(current, PROCESS__FORK)
function.
4. This will result in a call to the AVC via the avc_has_perm() function in
avc.c that checks whether the permission has been granted or not. First (via
avc_has_perm_noaudit()) the cache is checked for an entry. Assuming
that there is no entry in the AVC, then the security_compute_av()
function in services.c is called.
5. The security_compute_av() function will search the SID table for
source and target entries, and if found will then call the
context_struct_compute_av() function.

Page 74
The SELinux Notebook

The context_struct_compute_av() function carries out many checks
to validate whether access is allowed. The steps are (assuming the access is
valid):
a) Initialise the AV structure so that it is clear.
b) Check the object class and permissions are correct. It also checks the
status of the allow_unknown flag (see the SELinux Filesystem,
/etc/selinux/semanage.conf file and Reference Policy
Build Options - build.conf - UNK_PERMS sections).
c) Checks if there are any type enforcement rules (ALLOW,
AUDIT_ALLOW, AUDIT_DENY).
d) Check whether any conditional statements are involved via the
cond_compute_av() function in conditional.c.
e) Remove permissions that are defined in any constraint via the
constraint_expr_eval() function call (in services.c).
This function will also check any MLS constraints.
f) context_struct_compute_av() checks if a process transition
is being requested (it is not). If it were, then the TRANSITION and
DYNTRANSITION permissions are checked and whether the role is
changing.
g) Finally check whether there are any constraints applied via the
typebounds rule.
6. Once the result has been computed it is returned to the kernel/fork.c
system call via the initial selinux_task_create() function. In this case
the fork call is allowed.
7. The End.

Page 75
The SELinux Notebook

kernel/fork.c
/*
* This creates a new process as a copy of the old one, but does not actually
* start it yet. It copies the registers, and all the appropriate parts of the
* process environment (as per the clone flags). The actual kick-off is left to
* the caller.
*/
static struct task_struct *copy_process(unsigned long clone_flags, ...)
{
int retval;
struct task_struct *p;
int cgroup_callbacks_done = 0;

if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
6 .....
.....
retval = security_task_create(clone_flags);
if (retval)
goto fork_out;

security_ops function pointer structure
T his contains a pointer to the SELinux function in hooks.c that was built when the
SELinux module was initialised:
1
security_task_create->selinux_task_create

selinux/hooks.c selinux/ss/services.c
T his contains the SELinux functions. T his contains the Security Server functions.
2 T he call to security_compute_av will
static int selinux_task_create (unsigned long result in the security server checking whether
clone_flags) the requested access is allowed or not and
{ return the result to the calling function.
return current_has_perm (current,
PROCESS__FORK); 5
} 4
....
....
3 selinux/avc.c
T his contains the AVC functions.
T he call to avc_has_perm will result in a
static int current_has_perm (struct task_struct *tsk, call to avc_has_perm_noaudit that
u32 perms)
will actually check the AVC. If not in cache,
{
u32 sid, tsid; there will be a call to the security server
function security_compute_av that
sid = current_sid(); will check and return the decision. T he AVC
tsid = task_sid(tsk); code will then insert the decision into the
return avc_has_perm (sid, tsid, cache and return the result to the calling
SECCLASS_PROCESS, perms, NULL); function.
}

Figure 2.10: Hooks for the fork system call - This describes the steps required to
check access permissions for Object Class 'process' and permission 'fork'.

2.19.2.2 Process Transition Walk-thorough
This section walks through the execve(2) and checking whether a process
transition to the ext_gateway_t domain is allowed, and if so obtain a new SID for
the context (unconfined_u:message_filter_r:ext_gateway_t) as
shown in Figure 2.7.
The process starts with the Linux operating system issuing a do_execve14 call from
the CPU specific architecture code to execute a new program (for example, from

14
This function call will pass over the file name to be run and its environment + arguments.

Page 76
The SELinux Notebook

arch/ia64/kernel/process.c). The do_execve() function is located in
the fs/exec.c source code module and does the loading and final exec as
described below.
do_execve() has a number of calls to security_bprm_* functions that are a
part of the LSM (see include/linux/security.h), and are hooked by SELinux
during the initialisation process (in security/selinux/hooks.c). Table 9
briefly describes these security_bprm functions that are hooks for validating
program loading and execution (although see security.h for greater detail).
LSM / SElinux Function Name Description
security_bprm_set_creds-> Set up security information in the bprm->security field
selinux_bprm_set_creds based on the file to be exec'ed contained in bprm->file.
SELinux uses this hook to check for domain transitions and
the whether the appropriate permissions have been granted,
and obtaining a new SID if required.
security_bprm_committing_creds-> Prepare to install the new security attributes of the process
selinux_bprm_committing_creds being transformed by an execve operation. SELinux uses
this hook to close any unauthorised files, clear parent signal
and reset resource limits if required.
security_bprm_committed_creds-> Tidy up after the installation of the new security attributes of
selinux_bprm_ committed_creds a process being transformed by an execve operation.
SELinux uses this hook to check whether signal states can
be inherited if new SID allocated.
security_bprm_secureexec-> Called when loading libraries to check AT_SECURE flag for
selinux_bprm_secureexec glibc secure mode support. SELinux uses this hook to check
the process class noatsecure permission if
appropriate.
security_bprm_check-> This hook is not used by SELinux.
selinux_bprm_check_security

Table 9: The LSM / SELinux Program Loading Hooks
Therefore starting at the do_execve() function and using Figure 2.11, the
following major steps will be carried out to check whether the unconfined_t
process has permission to transition the secure_server executable to the
ext_gateway_t domain:
1. The executable file is opened, a call issued to the sched_exec() function
and the bprm structure is initialised with the file parameters (name,
environment and arguments).
2. Via the prepare_binprm() function call the UID and GIDs are checked
and a call issued to security_bprm_set_creds() that will carry out
the following:
3. Call cap_bprm_set_creds function in commoncap.c, that will set up
credentials based on any configured capabilities.
If setexeccon(3) has been called prior to the exec, then that context will
be used otherwise call security_transition_sid() function in
services.c. This function will then call security_compute_sid()

Page 77
The SELinux Notebook

to check whether a new SID needs to be computed. This function will
(assuming there are no errors):
i. Search the SID table for the source and target SIDs.
ii. Sets the SELinux user identity.
iii. Set the source role and type.
iv. Checks that a type_transition rule exists in the AV table and /
or the conditional AV table (see Figure 2.12).
v. If a type_transition, then also check for a
role_transition (there is a role change in the
ext_gateway.conf policy module), set the role.
vi. Check if any MLS attributes by calling mls_compute_sid() in
mls.c. It also checks whether MLS is enabled or not, if so sets up
MLS contexts.
vii. Check whether the contexts are valid by calling
compute_sid_handle_invalid_context() that will also log
an audit message if the context is invalid.
viii. Finally obtains a SID for the new context by calling
sidtab_context_to_sid() in sidtab.c that will search the
SID table (see Figure 2.12) and insert a new entry if okay or log a
kernel event if invalid.
4. The selinux_bprm_set_creds() function will continue by checking
via the avc_has_perm() functions (in avc.c) whether the file class
file_execute_no_trans is set (in this case it is not), therefore the
process class transition and file class file_entrypoint
permissions are checked (in this case they are allowed), therefore the new SID
is set, and after checking various other permissions, control is passed back to
the do_execve function.
5. The exec_binprm function will ultimately commit the credentials calling
the SELinux selinux_bprm_committing_creds and
selinux_bprm_committed_creds.
6. Various strings are copied (args etc.) and a check is made to see if the exec
succeeded or not (in this case it did), therefore the
security_bprm_free() function is ultimately called to free the bprm
security structure.
7. The End.

Page 78
The SELinux Notebook

Figure 2.11: Process Transition - This shows the major steps required to check if a
transition is allowed from the unconfined_t domain to the ext_gateway_t
domain.

Page 79
The SELinux Notebook

libselinux
/proc /sys/fs/selinux (selinuxfs.c)

Security Services
Kernel Services Linux Security Module Framework (selinux/ss/services.c)
NetLink Services
These are the (selinux/netlink.c)
Linux kernel
include/ SELinux Security Module The SELinux Security Server authorises (or not) access
linux/
resources such as security.h
(selinux/hooks.c) Informs of policy reloads decisions.
policydb.h
files, sockets, Conditional AV table permissions
memory security.c This module is the main interface Access Vector Expression class
management that between the kernel resources for Cache State role
need access managing SELinux access (selinux/avc.c) IF list role_transition
decisions made. decisions. Acts as the resource (linked to AV T able) role_allow
Object Manager. ELSE list type
(linked to AV T able) user
boolean
fork.c Constraints Table level
security_task_create (clone_flags)
selinux_task_create avc_has_perms security_compute_av Expression T ype category
Constraint Attribute range_transition
load new Constraint Operator
(linked to AV T able)
program avc_insert
services.c
AV table
Manages the allow Rules:
permissions granted source_type, target_type, class, permissions;
capabilities.c or denied in a cache ----------------------------------------------------
selinux_bprm_set_creds to speed decisions type_transition Rules:
selinux_bprm_committing_creds source_type, target_type, class, default_type;

exec.c selinux_bprm_committed_creds
do_execve (...) selinux_bprm_secureexec
SID & Context Tables
selinux_bprm_cred_free Linked
SID=1:system_u:system_r:kernel_t
security_transition_sid
execute new SID=2:system_u:object_r:security_t
program selinux_inode_permission .....
SID=n+1:user_u:message_filter_r:ext_gateway_t

Figure 2.12: The Main LSM / SELinux Modules - The fork and exec functions link to Figure 2.7 where the transition process is described.

Page 80
The SELinux Notebook

2.19.2.3 SELinux Filesystem
Table 10 shows the information contained in the SELinux filesystem (selinuxfs) /sys/fs/selinux (or /selinux on older systems)
where the SELinux kernel exports information regarding its configuration and active policy. selinuxfs is a read/write interface used by
SELinux library functions for userspace SELinux-aware applications and object managers. Note: while it is possible for userspace applications
to read/write to this interface, it is not recommended - use the libselinux library.
selinuxfs Directory and File Names Permissions Comments
/sys/fs/selinux Directory This is the root directory where the SELinux kernel exports relevant information regarding its
configuration and active policy for use by the libselinux library.
access -rw-rw-rw- Compute access decision interface that is used by the security_compute_av(3),
security_compute_av_flags(3), avc_has_perm(3)and
avc_has_perm_noaudit(3) functions.
The kernel security server (see services.c) converts the contexts to SIDs and then calls the
security_compute_av_user function to compute the new SID that is then converted to
a context string.
Requires security {compute_av} permission.
checkreqprot -rw-r--r-- 0 = Check requested protection applied by kernel.
1 = Check protection requested by application. This is the default.
These apply to the mmap and mprotect kernel calls. Default value can be changed at boot
time via the checkreqprot= parameter.
Requires security {setcheckreqprot} permission.
commit_pending_bools --w------- Commit new boolean values to the kernel policy.
Requires security {setbool} permission.
context -rw-rw-rw- Validate context interface used by the security_check_context(3) function.
Requires security {check_context} permission.

Page 81
The SELinux Notebook

selinuxfs Directory and File Names Permissions Comments
create -rw-rw-rw- Compute create labeling decision interface that is used by the
security_compute_create(3) and avc_compute_create(3) functions.
The kernel security server (see services.c) converts the contexts to SIDs and then calls the
security_transition_sid_user function to compute the new SID that is then
converted to a context string.
Requires security {compute_create} permission.
deny_unknown -r--r--r-- These two files export deny_unknown (read by security_deny_unknown(3)
reject_unknown -r--r--r-- function) and reject_unknown status to user space.
These are taken from the handle-unknown parameter set15 in the
/etc/selinux/semanage.conf file when policy is being built and are set as follows:
deny:reject
0:0 = Allow unknown object class / permissions. This will set the returned AV with all
1's.
1:0 = Deny unknown object class / permissions (the default). This will set the returned
AV with all 0's.
1:1 = Reject loading the policy if it does not contain all the object classes / permissions.
disable --w------- Disable SELinux until next reboot.
enforce -rw-r--r-- Get or set enforcing status.
Requires security {setenforce} permission.
load -rw------- Load policy interface.
Requires security {load_policy} permission.
member -rw-rw-rw- Compute polyinstantiation membership decision interface that is used by the
security_compute_member(3) and avc_compute_member(3) functions.
The kernel security server (see services.c) converts the contexts to SIDs and then calls the
security_member_sid function to compute the new SID that is then converted to a
context string.
Requires security {compute_member} permission.
mls -r--r--r-- Returns 1 if MLS policy is enabled or 0 if not.

15
This is also set in the UNK_PERMS entry of the Reference Policy build.conf file. The entry in semanage.conf will over-ride the build.conf entry.

Page 82
The SELinux Notebook

selinuxfs Directory and File Names Permissions Comments
null crw-rw-rw- The SELinux equivalent of /dev/null for file descriptors that have been redirected by
SELinux.
policy -r--r--r-- Interface to upload the current running policy in kernel binary format. This is useful to check
the running policy using apol(1) , dispol/sedispol etc. (e.g. cat
/sys/fs/selinux/policy > current-policy then load it into the required tool).
policyvers -r--r--r-- Returns supported policy version for kernel. Read by security_policyvers(3)
function.
relabel -rw-rw-rw- Compute relabeling decision interface that is used by the
security_compute_relabel(3) function.
The kernel security server (see services.c) converts the contexts to SIDs and then calls the
security_change_sid function to compute the new SID that is then converted to a
context string.
Requires security {compute_relabel} permission.
status -r--r--r-- This can be used to obtain enforcing mode and policy load changes with much less over-head
than using the libselinux netlink / call backs. This was added for Object Managers that
have high volumes of AVC requests so they can quickly check whether to invalidate their
cache or not.
The status structure indicates the following:
version - Version number of the status structure. This will increase as other entries are
added.
sequence - This is incremented for each event with an even number meaning that the
events are stable. An odd number indicates that one of the events is changing and therefore
the userspace application should wait before reading the status of any event.
enforcing - 0 = Permissive mode, 1 = enforcing mode.
policyload - This contains the policy load sequence number and should be read and
stored, then compared to detect a policy reload.
deny_unknown - 0 = Allow and 1 = Deny unknown object classes / permissions. This is
the same as the deny_unknown entry above.

Page 83
The SELinux Notebook

selinuxfs Directory and File Names Permissions Comments
user -rw-rw-rw- Compute reachable user contexts interface that is used by the
security_compute_user(3) function.
The kernel security server (see services.c) converts the contexts to SIDs and then calls the
security_get_user_sids function to compute the user SIDs that are then converted to
context strings.
Requires security {compute_user} permission.
/sys/fs/selinux/avc Directory This directory contains information regarding the kernel AVC that can be displayed by the
avcstat command.
cache_stats -r--r--r-- Shows the kernel AVC lookups, hits, misses etc.
cache_threshold -rw-r--r-- The default value is 512, however caching can be turned off (but performance suffers) by:
echo 0 > /selinux/avc/cache_threshold
Requires security {setsecparam} permission.
hash_stats -r--r--r-- Shows the number of kernel AVC entries, longest chain etc.
/sys/fs/selinux/booleans Directory This directory contains one file for each boolean defined in the active policy.
secmark_audit -rw-r--r-- Each file contains the current and pending status of the boolean (0 = false or 1 = true). The
...... getsebool(8), setsebool(8) and sestatus(8) -b commands use this interface via
...... the libselinux library functions.
/sys/fs/selinux/initial_contexts Directory This directory contains one file for each initial SID defined in the active policy. The file name
is the initial SID name with the contents containing its security context.
any_socket -r--r--r-- Each file contains the initial context of the initial SID as defined in the active policy (e.g.
devnull any_socket was assigned system_u:object_r:unconfined_t).
.....
/sys/fs/selinux/policy_capabilities Directory This directory contains the policy capabilities that have been configured by default in the
kernel via the policycap statement in the active policy. These are generally new features
that can be enabled by using the policycap statement in policy. Their default values are
false.
always_check_network -r--r--r-- If true SECMARK and peer labeling are always enabled even if there are no SECMARK,
NetLabel or Labeled IPsec rules configured. This forces checking of the packet class to
protect the system should any rules fail to load or they get maliciously flushed. Requires kernel
3.14 minimum.

Page 84
The SELinux Notebook

selinuxfs Directory and File Names Permissions Comments
network_peer_controls -r--r--r-- If true the following network_peer_controls are enabled:
node: sendto recvfrom
netif: ingress egress
peer: recv
open_perms -r--r--r-- If true the open permissions are enabled by default on the following object classes: dir,
file, fifo_file, chr_file, blk_file.
redhat1 -r--r--r-- Available in kernel 3.4 to allow finer control of ptrace (this will be named correctly one
day). Requires policy support and the security class permission ptrace_child.
/sys/fs/selinux/class Directory This directory contains a list of classes and their permissions as defined by the policy (for the
Reference Policy the order in the security_classes and access_vectors files).
/sys/fs/selinux/class/appletalk_socket Directory Each class has its own directory where each one is named using the appropriate class statement
from the policy (i.e. class appletalk_socket). Each directory contains the following:
index -r--r--r-- This file contains the allocated class number (e.g. appletalk_socket is the 56th entry in
the policy security_classes file).
/sys/fs/selinux/class/appletalk_socket/perms Directory This directory contains one file for each permission defined in the policy.
accept -r--r--r-- Each file is named by the permission assigned in the policy and contains a number that
append represents its position in the list (e.g. accept is the 14th permission listed in the policy
bind access_vector file for the appletalk_socket and therefore contains '14'.
....

Table 10: selinux filesystem Information
Notes:
1. Kernel SIDs are not passed to userspace only the context strings.
2. The /proc filesystem exports the process security context string to userspace via /proc/<self|pid>/attr and /proc/<self|
pid>/task/<tid>/attr/<attr> interfaces.

Page 85
The SELinux Notebook

2.20 libselinux Library
libselinux contains all the SELinux functions necessary to build userspace
SELinux-aware applications and object managers using 'C', Python, Ruby and PHP
languages.
The library hides the low level functionality of (but not limited to):
• The SELinux filesystem that interfaces to the SELinux kernel security server.
• The proc filesystem that maintains process state information and security
contexts - see proc(5).
• Extended attribute services that manage the extended attributes associated to
files, sockets etc. - see attr(5).
• The SELinux policy and its associated configuration files.
The general category of functions available in libselinux are shown in Table 11,
with Appendix B giving a complete list of functions.
Function Category Description

Access Vector Cache Services Allow access decisions to be cached and
audited.

Boolean Services Manage booleans.

Class and Permission Management Class / permission string conversion and
mapping.

Compute Access Decisions Determine if access is allowed or denied.

Compute Labeling Compute labels to be applied to new
instances of on object.

Default File Labeling Obtain default contexts for file operations.

File Creation Labeling Get and set file creation contexts.

File Labeling Get and set file and file descriptor extended
attributes.

General Context Management Check contexts are valid, get and set context
components.

Key Creation Labeling Get and set kernel key creation contexts.

Label Translation Management Translate to/from, raw/readable contexts.

Netlink Services Used to detect policy reloads and
enforcement changes.

Process Labeling Get and set process contexts.

SELinux Management Services Load policy, set enforcement mode, obtain
SELinux configuration information.

SELinux-aware Application Labeling Retrieve default contexts for applications
such as database and X-Windows.

Socket Creation Labeling Get and set socket creation contexts.

Page 86
The SELinux Notebook

User Session Management Retrieve default contexts for user sessions.

Table 11: libselinux function types
Other SELinux userspace libraries are:
libsepol - To build and manipulate the contents of SELinux kernel binary
policy files.
libsemanage - To manage the policy infrastructure.
Details of the libraries, core SELinux utilities and commands with source code are
available at:
https://github.com/SELinuxProject/selinux/wiki
The versions of kernel and SELinux tools and libraries influence the features
available, therefore it is important to establish what level of functionality is required
for the application. The Policy Versions section shows the policy versions and the
additional features they support.
Writing kernel based object managers is a more specialised subject and is not covered
in this section.
The libselinux functions make use of a number of files within the SELinux sub-
system:
1. The SELinux configuration file config that is described in the
/etc/selinux/config File section.
2. The SELinux filesystem interface between userspace and kernel that is
generally mounted as /selinux or /sys/fs/selinux and described in
the SELinux Filesystem section.
3. The proc filesystem that maintains process state information and security
contexts - see proc(5).
4. The extended attribute services that manage the extended attributes associated
to files, sockets etc. - see attr(5).
5. The SELinux kernel binary policy that describes the enforcement policy.
6. A number of libselinux functions have their own configuration files that
in conjunction with the policy, allow additional levels of configuration. These
are described in the Policy Configuration Files section and also in the
following man pages:
booleans(5), customizable_types(5),
default_contexts(5), default_type(5),
failsafe_context(5), file_contexts(5),
local.users(5), media(5), removable_context(5),
securetty_type(5), selabel_db(5), selabel_file(5),
selabel_media(5), selabel_x(5), sepgsql_contexts(5),
service_seusers(5), seusers(5), user_contexts(5),
virtual_domain_context(5),
virtual_image_context(5), x_contexts(5)

Page 87
The SELinux Notebook

2.21 SELinux Networking Support
SELinux supports the following types of network labeling:
Internal labeling - This is where network objects are labeled and managed
internally within a single machine (i.e. their labels are not transmitted as part of
the session with remote systems). There are two types supported: SECMARK and
NetLabel. There was a service known as 'compat_net' controls, however that
was removed in kernel 2.6.30.
Labeled Networking - This is where labels are passed to/from remote systems
where they can be interpreted and a MAC policy enforced on each system. There
are two types supported: Labeled IPSec and CIPSO (Commercial IP Security
Option).
There are two policy capability options that can be set within policy using the
policycap statement that affect networking configuration:
network_peer_controls - This is always enabled in the latest Reference
Policy source. Figure 2.14 shows the differences between the policy capability
being set to 0 and 1.
always_use_network - This capability would normally be set to false. If true
SECMARK and NetLabel peer labeling are always enabled even if there are no
SECMARK, NetLabel or Labeled IPsec rules configured. This forces checking of
the packet class to protect the system should any rules fail to load or they get
maliciously flushed. Requires kernel 3.13 minimum.
The policy capability settings are available in userspace via the SELinux filesystem as
shown in Table 10.
To support peer labeling and CIPSO the NetLabel tools need to be installed:
yum install netlabel_tools

To support Labeled IPSec the IPSec tools need to be installed:
yum install ipsec-tools

It is also possible to use an alternative Labeled IPSec service that was OpenSwan but
is now distributed as LibreSwan:
yum install libreswan

It is important to note that the kernel must be configured to support these services.
The F-20 kernels are configured to handle all the above services.
The Linux networking package iproute has an SELinux aware socket statistics
command ss(8) that will show the SELinux context of network processes (-Z or
--context option) and network sockets (-z or --contexts option). Although
note that the socket contexts are taken from the inode associated to the socket and not
from the actual kernel socket structure (as currently there is no standard
kernel/userspace interface to achieve this).

Page 88
The SELinux Notebook

2.21.1 SECMARK
SECMARK makes use of the standard kernel NetFilter framework that underpins the
GNU / Linux IP networking sub-system. NetFilter services automatically inspects all
incoming and outgoing packets and can place controls on interfaces, IP addresses
(nodes) and ports with the added advantage of connection tracking. The SECMARK
security extensions allow security contexts to be added to packets (SECMARK) or
sessions (CONNSECMARK).
The NetFilter framework inspects and tag packets with labels as defined within
iptables(8) and then uses the security framework (e.g. SELinux) to enforce the
policy rules. Therefore SECMARK services are not SELinux specific as other
security modules using the LSM infrastructure could also implement the same
services (e.g. SMACK).
While the implementation of iptables / NetFilter is beyond the scope of this
Notebook, there are tutorials available 16. Figure 2.13 shows the basic structure with
the process working as follows:
• A table called the 'security table' is used to define the parameters that identify
and 'mark' packets that can then be tracked as the packet travels through the
networking sub-system. These 'marks' are called SECMARK and
CONNSECMARK.
• A SECMARK is placed against a packet if it matches an entry in the security
table applying a label that can then be used to enforce policy on the packet.
• The CONNSECMARK 'marks' all packets within a session 17 with the
appropriate label that can then be used to enforce policy.

16
There is a very good tutorial at http://www.frozentux.net/documents/iptables-tutorial/ [5], however
it does not cover the security table that was introduced by: http://lwn.net/Articles/267140/. It is still
possible to use the 'mangle table' to hold security labels as described in [5].
17
For example, an ftp session where the server is listening on a specific port (the destination port)
but the client will be assigned a random source port. The CONNSECMARK will ensure that all
packets for the ftp session are marked with the same label.

Page 89
The SELinux Notebook

Receive Client or Server Application Send

Policy:
allow ext_gateway_t ext_gateway_packet_t:packet { send recv };

security table entries:
iptables -t security -A INPUT -p tcp --dport 9999 -j As packets are sent, they
INPUT SECMARK --selctx are marked and either
system_u:object_r:ext_gateway_packet_t ACCEPT’ed or
As packets are received, DROP’ed
they are marked and
iptables -t security -A OUTPUT -p tcp --dport 9999 -j
either ACCEPT’ed or
SECMARK --selctx OUTPUT
DROP’ed
system_u:object_r:ext_gateway_packet_t

Route Forward

Network Interface

Figure 2.13: SECMARK Processing - Received packets are processed by the
INPUT chain where labels are added to the appropriate packets that will either be
accepted or dropped by the SECMARK process. Packets being sent are treated the
same way.
An example iptables18 'security table' entry is as follows:
# Flush the security table first:
iptables -t security -F

#-------------- INPUT IP Stream --------------------#

# This INPUT rule sets all packets to msg_filter.default_packet: as it is
# executed first:
iptables -t security -A INPUT -i lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx
system.user:object_r:msg_filter.default_packet:s0

# These rules will replace the above context with the internal or
# external gateway if port 9999 or 1111 is found in either the source or
# destination port of the packet:
iptables -t security -A INPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx
system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx
system.user:object_r:msg_filter.ext_gateway.packet:s0
#
# The internal gateway:
iptables -t security -A INPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx
system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx
system.user:object_r:msg_filter.int_gateway.packet:s0

iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j
CONNSECMARK --save

#-------------- OUTPUT IP Stream --------------------#

# This OUTPUT rule sets all packets to msg_filter.default_packet: as it is
# executed first:

18
The tables will not load correctly if the policy does not allow the iptables domain to relabel the
security table entries unless permissive mode is enabled (i.e. iptables must have the relabel
permission for each entry in the table).

Page 90
The SELinux Notebook

iptables -t security -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx
system.user:object_r:msg_filter.default_packet:s0

# These rules will replace the above context with the internal or
# external gateway if port 9999 or 1111 is found in either the source or
# destination port of the packet:
iptables -t security -A OUTPUT -o lo -p tcp --dport 9999 -j SECMARK --selctx
system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A OUTPUT -o lo -p tcp --sport 9999 -j SECMARK --selctx
system.user:object_r:msg_filter.ext_gateway.packet:s0
#
# The internal gateway:
iptables -t security -A OUTPUT -o lo -p tcp --dport 1111 -j SECMARK --selctx
system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A OUTPUT -o lo -p tcp --sport 1111 -j SECMARK --selctx
system.user:object_r:msg_filter.int_gateway.packet:s0

iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j
CONNSECMARK --save

An example policy that makes use of SECMARK services is described in the
Notebook source tarball. There are also articles "Transitioning to Secmark" [7] and
"New secmark-based network controls for SELinux" [6] that explain the services.

2.21.2 NetLabel - Fallback Peer Labeling
Fallback labeling can optionally be implemented on a system if the Labeled IPSec or
CIPSO is not being used (hence 'fallback labeling'). If either Labeled IPSec or CIPSO
are being used, then these take priority. There is an article "Fallback Label
Configuration Example" [8] that explains their usage, the netlabelctl(8) man
page is also a useful reference.
The example message filter has an optional module that makes use of fallback labels
and can be found in the Notebook source tarball.
The network peer controls have been extended to support an additional object class of
'peer' that is enabled by default in the F-20 policy as the
network_peer_controls in
/sys/fs/selinux/policy_capabilities is set to '1'. Figure 2.14 shows
the differences between the policy capability network_peer_controls being set
to 0 and 1.

0 network_peer_control 1

tcp_socket: peer:
allow ext_gateway_t netlabel_peer_t: allow ext_gateway_t netlabel_peer_t:
tcp_socket recvfrom; peer recv;

NetLabel Command:
netlabelctl unlbl add interface:lo address:127.0.0.1 \
label:system_u:object_r:netlabel_peer_t

Figure 2.14: Fallback Labeling - Showing the differences between the policy
capability network_peer_controls set to 0 and 1.

Page 91
The SELinux Notebook

2.21.3 NetLabel - CIPSO
To allow security levels to be passed over a network between MLS systems 19, the
CIPSO protocol is used. This is defined in the CIPSO Internet Draft document (this is
an obsolete document, however the protocol is still in use). The protocol defines how
security levels are encoded in the IP packet header.
Note that only the level component of the security context is passed over the network.
The exception is in loopback mode as explained in "Full SELinux Labels Over
Loopback with NetLabel and CIPSO" available at
http://paulmoore.livejournal.com/7234.html.
The protocol is implemented by the NetLabel service (see netlabelctl(8)) and
can be used by other security modules that use the LSM infrastructure. The NetLabel
implementation supports:
1. Tag Type 1 bit mapped format that allows a maximum of 256 sensitivity
levels and 240 categories to be mapped.
2. A non-translation option where labels are passed to / from systems unchanged
(for host to host communications as show in Figure 2.15).

MLS Host 1 MLS Host 2

Figure 2.15: MLS Systems on the same network
3. A translation option where both the sensitivity and category components can
be mapped for systems that have either different definitions for labels or
information can be exchanged over different networks (for example using an
SELinux enabled gateway as a guard as shown in Figure 2.16).

MLS Gateway
MLS Host 1 (Guard) MLS Host 2

Figure 2.16: MLS Systems on different networks communicating via a gateway

2.21.4 Labeled IPSec
Labeled IPSec has been built into the standard GNU / Linux IPSec services as
described in the "Leveraging IPSec for Distributed Authorization" [9]. Figure 2.17
shows the basic components that form the service based on IPSec tools where it is
generally used to set up either an encrypted tunnel between two machines 20 or an
encrypted transport session. The extensions defined in [9] describe how the security
context is configured and negotiated between the two systems (called security
associations (SAs) in IPSec terminology).
19
Note only the security levels are passed over the network as the other components of the security
context are not part of standard MLS systems (as it may be that the remote end is a Trusted Solaris
system).
20
Also known as a virtual private network (VPN).

Page 92
The SELinux Notebook

Internet Key
C lie nt setkey racoon Exchange (IKE) racoon setkey S e rve r
Application Manages Manages key Manages key Manages Application
configuration exchange
Negotiates the SAs exchange configuration

Security Policy Security Security Security Policy
Association Association
Database (SPD) Database (SAD) Database (SAD)
Database (SPD)

Encrypted
communications
IPSec packet management services IP Sec packet management services
channel

Figure 2.17: IPSec communications - The SPD contains information regarding the
security contexts to be used. These are exchanged between the two systems as part of
the channel set-up.
Basically what happens is as follows21:
1. The security policy database (SPD) defines the security communications
characteristics to be used between the two systems. This is populated using the
setkey(8) utility with an example shown in the Configuration Example
section.
2. The SAs have their configuration parameters such as protocols used for
securing packets, encryption algorithms and how long the keys are valid held
in the Security Association database (SAD). For Labeled IPSec the security
context (or labels) is also defined within the SAD. SAs can be negotiated
between the two systems using either racoon or pluto22 that will
automatically populate the SAD or manually by the setkey utility (see the
example below).
3. Once the SAs have been negotiated and agreed, the link should be active.
A point to note is that SAs are one way only, therefore when two systems are
communicating (using the above example), one system will have an SA, SAout for
processing outbound packets and another SA, SAin, for processing the inbound
packets. The other system will also create two SAs for processing its packets.
Each SA will share the same cryptographic parameters such as keys and protocol23
(e.g. ESP (encapsulated security payload) and AH (authentication header)).
The object class used for the association of an SA is association and the
permissions available are as follows:

21
There is an “IPSec HOWTO" [10] at http://www.ipsec-howto.org that gives the gory details,
however it does not cover Labeled IPSec.
22
These are the Internet Key Exchange (IKE) daemons that exchange encryption keys securely and
also supports Labeled IPSec parameter exchanges.
23
The GNU / Linux version supports a number of secure protocols, see setkey(8) for details.

Page 93
The SELinux Notebook

polmatch Match the SPD context (-ctx) entry to an SELinux domain
(that is contained in the SAD -ctx entry)
recvfrom Receive from an IPSec association.
sendto Send to an IPSec association.
setcontext Set the context of an IPSec association on creation (e.g.
when running setkey the process will require this
permission to set the context in the SAD and SPD, also
racoon / pluto will need this permission to build the
SAD).

When running Labeled IPSec it is recommended that the systems use the same
type/version of policy to avoid any problems with them having different meanings.
There are worked examples of Labeled IPSec sessions showing manual configuration
using setkey and IKE exchanges using racoon24 and LibreSwan (pluto)
configurations in the Notebook source tarball (note that the LibreSwan examples use
the kernel netkey services).
There is a further example in the "Secure Networking with SELinux" [11] article.
There is a good reference covering "Basic Labeled IPsec Configuration" available at:
http://www.redhat.com/archives/redhat-lspp/2006-November/msg00051.html

2.21.4.1 Configuration Examples
There are two possible labeled IPSec solutions available:
IPSec Tools - This uses the setkey(8) tools and racoon(8) Internet Key
Exchange (IKE) daemon.
LibreSwan - This uses ipsec(8) tools and pluto(8) Internet Key Exchange
(IKE) daemon.
Both work in much the same way but use different configuration files with samples
shown below. The one point they have in common is that to start any session for label
exchange using IKE, setkey must be used to initially set up the labels in the
security policy database (SPD) on each machine.
Another point to note is that if interoperating between racoon and pluto the IPSEC
Security Association Attribute values are different:
• racoon has this hard-wired to a value of '10'.
• pluto is configurable with a default of '32001'. To interoperate with
racoon the ipsec.conf(5) file must have:

config setup
secctx_attr_value = 10

The following example configurations show the common setkey configuration to set
up the SPD entries and then a sample supporting racoon and pluto (LibreSwan)
configuration file:

24
Unfortunately racoon core dumps when using non MCS/MLS policies.

Page 94
The SELinux Notebook

Add label / context to SPD for loopback:
# setkey -f configuration file entries for RACOON SA configuration
#
# If the Internal Gateway module (int_gateway.conf) is not loaded,
# then the entries should be removed from this file.
#
# Flush the SAD and SPD
flush;
spdflush;

#
########### Security Policy Database entries ##########################
#
# Note that the only part of the security context matched against is
# the 'type' (e.g. ext_gateway_t).

# Security policies for external gateway:
spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"
-P out ipsec esp/transport//require;

spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"
-P in ipsec esp/transport//require;

# Security policies for internal gateway:
spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0"
-P out ipsec esp/transport//require;

spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0"
-P in ipsec esp/transport//require;

racoon configuration:
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

sainfo anonymous
{
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}

LibreSwan / pluto loopback configuration:
# /etc/ipsec.conf - Libreswan IPsec configuration file

version 2.0

config setup
plutorestartoncrash=false
protostack=netkey
plutodebug="all"
# A "secctx_attr_value" is optional for >= 3.6 as defaults to this:
secctx_attr_value = 32001

conn labeled_loopback_test
auto=start
rekey=no
authby=secret
type=transport

Page 95
The SELinux Notebook

left=127.0.0.1
right=127.0.0.1
ike=3des-sha1
phase2=esp
phase2alg=aes-sha1
loopback=yes
labeled_ipsec=yes
policy_label=unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0
leftprotoport=tcp
rightprotoport=tcp

2.22 SELinux Virtual Machine Support
SELinux support is available in the KVM/QEMU and Xen virtual machine (VM)
technologies25 that are discussed in the sections that follow, however the package
documentation should be read for how these products actually work and how they are
configured.
Currently the main SELinux support for virtualisation is via libvirt that is an
open-source virtualisation API used to dynamically load guest VMs. Security
extensions were added as a part of the Svirt project and the SELinux implementation
for the KVM/QEMU package (qemu-kvm and libvirt rpms) is discussed using
some examples. The Xen product has Flask/TE services that can be built as an
optional service, although it can also use the security enhanced libvirt services as
well.
The sections that follow give an introduction to KVM/QEMU, then libvirt
support with some examples using the Virtual Machine Manager to configure VMs,
then an overview of the Xen implementation follows.
To ensure all dependencies are installed run:
yum install libvirt
yum install qemu
yum install virt-manager

2.22.1 KVM / QEMU Support
KVM is a kernel loadable module that uses the Linux kernel as a hypervisor and
makes use of a modified QEMU emulator to support the hardware I/O emulation. The
"Kernel-based Virtual Machine" [17] document gives a good overview of how KVM
and QEMU are implemented. It also provides an introduction to virtualisation in
general. Note that KVM requires virtulisation support in the CPU (Intel-VT or AMD-
V extensions).
The SELinux support for VMs is implemented by the libvirt sub-system that is
used to manage the VM images using a Virtual Machine Manager, and as KVM is
based on Linux it has SELinux support by default. There are also Reference Policy
modules to support the overall infrastructure (KVM support is in various kernel and
system modules with a virt module supporting the libvirt services). Figure 2.18
25
KVM (Kernel-based Virtual Machine) and Xen are classed as 'bare metal' hypervisors and they
rely on other services to manage the overall VM environment. QEMU (Quick Emulator) is an
emulator that emulates the BIOS and I/O device functionality and can be used standalone or with
KVM and Xen.

Page 96
The SELinux Notebook

shows a high level overview with two VMs running in their own domains. The
libvirt Support section shows how to configure these and their VM image files.

Virtual Machine VM Guest 1 VM Guest 2
svirt_t:s0:c1,c2 svirt_t:s0:c7,c8
Manager
libvirtd
Linux Guest Windows Guest
Manages the
QEMU operating system operating system
images, assigns
security labels, start libvirt
--------------------------- ---------------------------
and stop VMs etc. Driver
QEMU QEMU

KVM Hypervisor (Linux kernel)

Hardware

Figure 2.18: KVM Environment - KVM provides the hypervisor while
QEMU provides the hardware emulation services for the guest
operating systems. Note that KVM requires CPU virtualisation support.

2.22.2 libvirt Support
The Svirt project added security hooks into the libvirt library that is used by the
libvirtd daemon. This daemon is used by a number of VM products (such as
KVM, QEMU and Xen) to start their VMs running as guest operating systems.
The VM supplier can implement any security mechanism they require using a product
specific libvirt driver that will load and manage the images. The SELinux
implementation supports four methods of labeling VM images, processes and their
resources with support from the Reference Policy modules/services/virt.*
loadable module26. To support this labeling, libvirt requires an MCS or MLS
enabled policy as the level entry of the security context is used
(user:role:type:level) .
The link http://libvirt.org/drvqemu.html#securityselinux has details regarding the
QEMU driver and the SELinux confinement modes it supports.

2.22.3 VM Image Labeling
This sections assumes VM images have been generated using the simple Linux kernel
available at: http://wiki.qemu.org/Testing (the linux-0.2.img.bz2 disk image),
this image was renamed to reflect each test, for example 'Dynamic_VM1.img'.
These images can be generated using the VMM by selecting the 'Create a new virtual
machine' menu, 'importing existing disk image' then in step 2 Browse... selecting
'Choose Volume: Dynamic_VM1.img' with OS type: Linux, Version: Generic
2.6.x kernel and change step 4 'Name' to Dynamic_VM1.

26
The various images would have been labeled by the virt module installation process (see the
virt.fc module file or the policy file_contexts file libvirt entries). If not, then need to
ensure it is relabeled by the most appropriate SELinux tool.

Page 97
The SELinux Notebook

2.22.3.1 Dynamic Labeling
The default mode is where each VM is run under its own dynamically configured
domain and image file therefore isolating the VMs from each other (i.e. every time the
VM is run a different and unique MCS label will be generated to confine each VM to
its own domain). This mode is implemented as follows:
a) An initial context for the process is obtained from the
/etc/selinux/<SELINUXTYPE>/contexts/virtual_domain_context file
(the default is system_u:system_r:svirt_tcg_t:s0).
b) An initial context for the image file label is obtained from the
/etc/selinux/<SELINUXTYPE>/contexts/virtual_image_context file.
The default is system_u:system_r:svirt_image_t:s0 that allows
read/write of image files.
c) When the image is used to start the VM, a random MCS level is generated
and added to the process context and the image file context. The process and
image files are then transitioned to the context by the libselinux API
calls setfilecon and setexeccon respectively (see
security_selinux.c in the libvirt source). The following example
shows two running VM sessions each having different labels:
VM Name Object Dynamically assigned security context
Dynamic_VM1 Process system_u:system_r:svirt_tcg_t:s0:c585,c813
File system_u:system_r:svirt_image_t:s0:c585,c813
Dynamic_VM2 Process system_u:system_r:svirt_tcg_t:s0:c535,c601
File system_u:system_r:svirt_image_t:s0:c535,c601

The running image ls -Z and ps -eZ are as follows, and for completeness
an ls -Z is shown when both VMs have been stopped:
# Both VMs running:
ls -Z /var/lib/libvirt/images
system_u:object_r:svirt_image_t:s0:c585,c813 Dynamic_VM1.img
system_u:object_r:svirt_image_t:s0:c535,c601 Dynamic_VM2.img

ps -eZ | grep qemu
system_u:system_r:svirt_tcg_t:s0:c585,c813 8707 ? 00:00:44 qemu-system-
x86
system_u:system_r:svirt_tcg_t:s0:cc535,c601 8796 ? 00:00:37 qemu-system-
x86

# Both VMs stopped (note that the categories are now missing AND
# the type has changed from svirt_image_t to virt_image_t):
ls -Z /var/lib/libvirt/images
system_u:object_r:virt_image_t:s0 Dynamic_VM1.img
system_u:object_r:virt_image_t:s0 Dynamic_VM2.img

2.22.3.2 Shared Image
If the disk image has been set to shared, then a dynamically allocated level will be
generated for each VM process instance, however there will be a single instance of
the disk image.

Page 98
The SELinux Notebook

The Virtual Machine Manager can be used to set the image as shareable by checking
the Shareable box as shown in Figure 2.19.

Figure 2.19: Setting the Virtual Disk as Shareable
This will set the image (Shareable_VM.xml) resource XML configuration file
located in the /etc/libvirt/qemu directory <disk> contents as follows:
# /etc/libvirt/qemu/Shareable_VM.xml:

As the two VMs will share the same image, the Shareable_VM service needs to be
cloned and the VM resource name selected was Shareable_VM-clone.

Page 99
The SELinux Notebook

The resource XML file <disk> contents generated are shown - note that it has the
same source file name as the Shareable_VM.xml above.
# /etc/libvirt/qemu/Shareable_VM-clone.xml:

With the targeted policy on F-20 the shareable option gave a error when the VMs
were run as follows:
Could not allocate dynamic translator buffer

The audit log contained the following AVC message:
type=AVC msg=audit(1326028680.405:367): avc: denied
{ execmem } for pid=5404 comm="qemu-system-x86"
scontext=system_u:system_r:svirt_t:s0:c121,c746
tcontext=system_u:system_r:svirt_t:s0:c121,c746 tclass=process

To overcome this error, the following boolean needs to be enabled with
setsebool(8) to allow access to shared memory (the -P option will set the
boolean across reboots):
setsebool -P virt_use_execmem on

Now that the image has been configured as shareable, the following initialisation
process will take place:
a) An initial context for the process is obtained from the
/etc/selinux/<SELINUXTYPE>/contexts/virtual_domain_context file
(the default is system_u:system_r:svirt_tcg_t:s0).
b) An initial context for the image file label is obtained from the
/etc/selinux/<SELINUXTYPE>/contexts/virtual_image_context file.

Page 100
The SELinux Notebook

The default is system_u:system_r:svirt_image_t:s0 that allows
read/write of image files.
c) When the image is used to start the VM a random MCS level is generated and
added to the process context (but not the image file). The process is then
transitioned to the appropriate context by the libselinux API calls
setfilecon and setexeccon respectively. The following example
shows each VM having the same file label but different process labels:
VM Name Object Security context
Shareable_VM Process system_u:system_r:svirt_tcg_t:s0:c231,c245
Shareable_VM Process system_u:system_r:svirt_tcg_t:s0:c695,c894
-clone
File system_u:system_r:svirt_image_t:s0

The running image ls -Z and ps -eZ are as follows and for completeness
an ls -Z is shown when both VMs have been stopped:
# Both VMs running and sharing same image:
ls -Z /var/lib/libvirt/images
system_u:object_r:svirt_image_t:s0 Shareable_VM.img

# but with separate processes:
ps -eZ | grep qemu
system_u:system_r:svirt_t:s0:c231,c254 6748 ? 00:01:17 qemu-system-x86
system_u:system_r:svirt_t:s0:c695,c894 7664 ? 00:00:03 qemu-system-x86

# Both VMs stopped (note that the type has remained as svirt_image_t)
ls -Z /var/lib/libvirt/images
system_u:object_r:svirt_image_t:s0 Shareable_VM.img

2.22.3.3 Static Labeling
It is possible to set static labels on each image file, however a consequence of this is
that the image cannot be cloned using the VMM, therefore an image for each VM will
be required. This is the method used to configure VMs on MLS systems as there is a
known label that would define the security level. With this method it is also possible
to configure two or more VMs with the same security context so that they can share
resources. A useful reference is at: http://libvirt.org/formatdomain.html#seclabel.
If using the Virtual Machine Manager GUI, then by default it will start each VM
running as they are built, therefore they need to be stopped and restarted once
configured for static labels, the image file will also need to be relabeled. An example
VM configuration follows where the VM has been created as Static_VM1 using the
F-20 targeted policy in enforcing mode (just so all errors are flagged during the
build):
a) To set the required security context requires editing the Static_VM1
configuration file using virsh(1) as follows:

virsh edit Static_VM1

Then add the following at the end of the file:

Page 101
The SELinux Notebook

....
</devices>

<seclabel type='static' model='selinux' relabel='no'>
<label>system_u:system_r:svirt_t:s0:c1022,c1023</label>
</seclabel>

</domain>

For this example svirt_t has been chosen as it is a valid context (however
it will not run as explained in the text). This context will be written to the
Static_VM1.xml configuration file in /etc/libvirt/qemu.
b) If the VM is now started an error will be shown as follows:

Figure 2.20: Image Start Error
This is because the image file label is incorrect as by default it is labeled
virt_image_t when the VM image is built (and svirt_t does not have
read/write permission for this label):
# The default label of the image at build time:
system_u:object_r:virt_image_t:s0 Static_VM1.img

There are a number of ways to fix this, such as adding an allow rule or
changing the image file label. In this example the image file label will be
changed using chcon(1) as follows:

# This command is executed from /var/lib/libvirt/images
#
# This sets the correct type:
chcon -t svirt_image_t Static_VM1.img

Optionally, the image can also be relabeled so that the [level] is the same
as the process using chcon as follows:

# This command is executed from /var/lib/libvirt/images
#
# Set the MCS label to match the process (optional step):
chcon -l s0:c1022,c1023 Static_VM1.img

Page 102
The SELinux Notebook

c) Now that the image has been relabeled, the VM can now be started.

The following example shows two static VMs (one is configured for
unconfined_t that is allowed to run under the targeted policy - this was possible
because the 'setsebool -P virt_transition_userdomain on' boolean
was set that allows virtd_t domain to transition to a user domain (e.g.
unconfined_t).
VM Name Object Static security context
Static_VM1 Process system_u:system_r:svirt_t:s0:c1022,c1023
File system_u:system_r:svirt_image_t:s0:c1022,c1023
Static_VM2 Process system_u:system_r:unconfined_t:s0:c11,c22

File system_u:system_r:virt_image_t:s0

The running image ls -Z and ps -eZ are as follows, and for completeness an ls
-Z is shown when both VMs have been stopped:
# Both VMs running (Note that Static_VM2 did not have file level reset):
ls -Z /var/lib/libvirt/images
system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img
system_u:object_r:virt_image_t:s0 Static_VM2.img

ps -eZ | grep qemu
system_u:system_r:svirt_t:s0:c585,c813 6707 ? 00:00:45 qemu-system-x86
system_u:system_r:unconfined_t:s0:c11,c22 6796 ? 00:00:26 qemu-system-x86

# Both VMs stopped (note that Static_VM1.img was relabeled svirt_image_t
# to enable it to run, however Static_VM2.img is still labeled
# virt_image_t and runs okay. This is because the process is run as
# unconfined_t that is allowed to use virt_image_t):
system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img
system_u:object_r:virt_image_t:s0 Static_VM2.img

2.22.4 Xen Support
This is not supported by SELinux in the usual way as it is built into the actual Xen
software as a 'Flask/TE' extension27 for the XSM (Xen Security Module). Also the
Xen implementation has its own built-in policy (xen.te) and supporting definitions
for access vectors, security classes and initial SIDs for the policy. These Flask/TE
components run in Domain 0 as part of the domain management and control
supporting the Virtual Machine Monitor (VMM) as shown in Figure 2.21.

27
This is a version of the SELinux security server, avc etc. that has been specifically ported for the
Xen implementation.

Page 103
The SELinux Notebook

Domain 0 Domain U Domain U
Modified Linux
Kernel to control Guest Guest
Domain U Guests Linux Windows
(with SELinux
Flask/TE
Enforcement if
Module
required)
Xen Security
Module
Xen Virtual Machine Manager (Hypervisor)

Hardware

Figure 2.21: Xen Hypervisor - Using XSM and Flask/TE to enforce
policy on the physical I/O resources.
The "How Does Xen Work" [18] document describes the basic operation of Xen, the
"Xen Security Modules" [19] describes the XSM/Flask implementation, and the
xsm-flask.txt file in the Xen source package describes how SELinux and its
supporting policy is implemented.
However (just to confuse the issue), there is another Xen policy module (also called
xen.te) in the Reference Policy to support the management of images etc. via the
Xen console.
For reference, the Xen policy supports additional policy language statements:
iomemcon, ioportcon, pcidevicecon and pirqcon that are discussed in the
Xen section of SELinux Policy Language.

2.23 Sandbox Services
Fedora has support for three types of sandbox services in F-20:
1. Non-GUI sandboxing (sandbox - see
http://danwalsh.livejournal.com/28545.html).
There is also a good use-case with solutions at:
http://opensource.com/education/12/8/harvard-goes-paas-selinux-sandbox that
involves uploading information to web servers and access by staff and
students.
2. GUI sandboxing using the Xephyr server (sandbox-X - see
http://danwalsh.livejournal.com/31146.html).
This will allow isolation of X applications via nested Xephyr servers. For
example running:
sandbox -t sandbox_web_t -i /path/to/user/home/dir/.mozilla -W metacity -X firefox

will load Firefox in an isolated X sandbox. The -i parameter stops Firefox
displaying the 'welcome to Firefox' page at start-up as it will use a copy from
the users current .mozilla directory.

Page 104
The SELinux Notebook

Red Hat use sandbox-X as the preferred alternative to XSELinux when
using the targeted policy, this is because X-clients that get a permission
denied will probably abort as they expect full access to the X-server.
Both of these sandbox services are defined in the sandbox(3) man page and
are available in the policycoreutils package. They make use of
seunshare(8) that allows commands to be run in an alternate home directory,
temp directory or security context. The sandbox.conf(5) file allows the
sandbox name, cpu and memory usage to be configured. There is also a
sandbox.init service that can be run at boot time to set up /var/tmp and
/tmp as private (mount --make-private).
Note that the sandbox services require MCS policy support as a minimum as
categories are used to isolate multiple sandboxes. Issuing the following command
will show this usage:
sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c421,c945

3. Virtulisation sandboxing of applications using either KVM/qemu or LXC 28
(Linux Containers) (virt-sandbox - see
http://people.redhat.com/berrange/fosdem-2012/libvirt-sandbox-fosdem-
2012.pdf that contains a good overview).
This service is available in the libvirt-sandbox package and provides an
API and command line services to start sessions. There is currently limited
policy support for virt-sandbox as it primary aim is for developers to
build services and provide the appropriate policy.
The package is built on Svirt that provides the virtulisation with SELinux
enforcement and KVM/qemu or LXC to provide the virtulisation environment.
If KVM support is not available on the machine (as it requires virtulisation
support in the CPU (Intel-VT or AMD-V extensions)), then LXC is the
alternative to use.
An LXC example:
virt-sandbox -c lxc:/// /bin/sh

To run in enforcing mode, the following policy module was added for the
targeted policy:
module lxc_example 1.0.0;

require {
type svirt_t, virtd_lxc_t, root_t, bin_t, proc_net_t;
type cache_home_t, user_home_t, boot_t, user_tmp_t;
class unix_stream_socket { connectto };
class chr_file { open read write ioctl getattr setattr };
class file { read write open getattr entrypoint };
class process { transition sigchld execmem };
class filesystem getattr;
}

28
Linux Containers do not provide a virtual machine, but a virtual environment that has its own
process and network space.

Page 105
The SELinux Notebook

allow virtd_lxc_t root_t : chr_file { open read write ioctl setattr };
allow virtd_lxc_t root_t : file { write open };
allow virtd_lxc_t svirt_t : process { transition };
allow svirt_t bin_t : file { entrypoint };
allow svirt_t proc_net_t : file { read };
allow svirt_t virtd_lxc_t : unix_stream_socket { connectto };
allow svirt_t virtd_lxc_t : process { sigchld };
allow svirt_t cache_home_t : file { read getattr open };
allow svirt_t proc_net_t : file { getattr open };
allow svirt_t root_t : chr_file { read write ioctl open getattr };
allow svirt_t root_t : filesystem { getattr };
allow svirt_t user_home_t : file { read open };

that was built and installed as follows:
checkmodule -M -m lxc_example.conf -o lxc_example.mod
semodule_package -o lxc_example.pp -m lxc_example.mod
semodule -v -i lxc_example.pp

2.24 X-Windows SELinux Support
The SELinux X-Windows (XSELinux) implementation provides fine grained access
control over the majority of the X-server objects (known as resources) using an X-
Windows extention acting as the object manager (OM). The extension name is
"SELinux".
This Notebook will only give a high level description of the infrastructure based on
Figure 2.22, however the "Application of the Flask Architecture to the X Window
System Server" [14] paper has a good overview of how the object manager has been
implemented, although it does not cover areas such as polyinstantiation.
The X-Windows object classes and permissions are listed in the X Windows Object
Classes section and the Reference Policy modules have been updated to enforce
policy using the XSELinux object manager.
On Fedora XSELinux is disabled in the targeted policy but enabled on the MLS
policy. This is because Red Hat prefers to use sandboxing with the Xephyr server to
isolate windows with the targeted policy, see the Sandbox Services section for details.

2.24.1 Infrastructure Overview
It is important to note that the X-Windows OM operates on the low level window
objects of the X-server. A windows manager (such as Gnome or twm) would then sit
above this, however they (the windows manager or even the lower level Xlib) would
not be aware of the policy being enforced by SELinux. Therefore there can be
situations where X-Windows applications get bitter & twisted at the denial of a
service. This can result in either opening the policy more than desired, or just letting
the application keep aborting, or modifying the application.

Page 106
The SELinux Notebook

x_contexts XSELinux Object X-Server
File Manager X-Client
Device Independent Layer (DIX)
(X-Extension) ---------------------------------------------- X-Client
Device Dependent Layer (DDX)
Initialise extension + Atoms: ---------------------------------------------- -------------------
_SELINUX_CONTEXT and Graphics, Keyboard and Pointer
libselinux Xlib
_SELINUX_CLIENT_CONTEXT . Hardware
Library X-Protocol over
TCP/IP or Streams -------------------
Load x_contexts file.
XACE interfaces Xlib
Manage X Object classes, and tables such as:
permissions and SID
allocation. Function Dispatch
Table and
User-space XSELinuxGet/Set. Functions. Resource Table
Policy AVC Manage interfaces between the XACE Interface
X-Server, XACE and the
libselinux API.
User-space

Netlink Linux Security Kernel Resources Kernel-space
Module (LSM) and supporting
SELinux Access Vector
Security Cache (AVC) Object Managers
Server

Figure 2.22: X-Server and XSELinux Object Manager - Showing the supporting services. The kernel space services are discussed in the
Linux Security Module and SELinux section.

Page 107
The SELinux Notebook

Using Figure 2.22, the major components that form the overall XSELinux OM are
(top left to right):
The Policy - The Reference Policy has been updated, however in Fedora the OM
is enabled for mls and disabled for targeted policies via the xserver-object-
manager boolean. Enabling this boolean also initialises the XSELinux OM
extension. Important note - The boolean must be present in any policy and be set
to true, otherwise the object manager will be disabled as the code specifically
checks for the boolean.
libselinux - This library provides the necessary interfaces between the OM,
the SELinux userspace services (e.g. reading configuration information and
providing the AVC), and kernel services (e.g. security server for access decisions
and policy update notification).
x_contexts File - This contains default context configuration information that
is required by the OM for labeling certain objects. The OM reads its contents
using the selabel_lookup(3) function.
XSELinux Object Manager - This is an X-extension for the X-server process
that mediates all access decisions between the the X-server (via the XACE
interface) and the SELinux security server (via libselinux). The OM is
initialised before any X-clients connect to the X-server.
The OM has also added XSELinux functions that are described in Table 12 to
allow contexts to be retrieved and set by userspace SELinux-aware applications.
XACE Interface - This is an 'X Access Control Extension' (XACE) that can be
used by other access control security extensions, not only SELinux. Note that if
other security extensions are linked at the same time, then the X-function will only
succeed if allowed by all the security extensions in the chain.
This interface is defined in the "X Access Control Extension Specification" [15].
The specification also defines the hooks available to OMs and how they should be
used. The provision of polyinstantiation services for properties and selections is
also discussed. The XACE interface is a similar service to the LSM that supports
the kernel OMs.
X-server - This is the core X-Windows server process that handles all request and
responses to/from X-clients using the X-protocol. The XSELinux OM is
intercepting these request/responses via XACE and enforcing policy decisions.
X-clients - These connect to the X-server are are typically windows managers
such as Gnome, twm or KDE.
Kernel-Space Services - These are discussed in the Linux Security Module and
SELinux section.

2.24.1.1 Polyinstantiation
The OM / XACE services support polyinstantiation of properties and selections
allowing these to be grouped into different membership areas so that one group does
not know of the exsistance of the others. To implement polyinstantiation the poly_
keyword is used in the x_contexts file for the required selections and properties,
there would then be a corresponding type_member rule in the policy to enforce the

Page 108
The SELinux Notebook

separation by computing a new context with either
security_compute_member(3) or avc_compute_member(3).
Note that the current Reference Policy does not implement polyinstantiation, instead
the MLS policy uses mlsconstrain rules to limit the scope of properties and
selections.

2.24.2 Configuration Information
This section covers:
• How to enable/disable the OM X-extension.
• How to determine the OM X-extension opcode.
• How to configure the OM in a specific SELinux enforcement mode.
• The x-contexts configuration file.

2.24.2.1 Enable/Disable the OM from Policy Decisions
The Reference Policy has a xserver_object_manager boolean that
enables/disables the X-server policy module and also stops the object manager
extension from initialising when X-Windows is started. The following command will
enable the boolean, however it will be necessary to reload X-Windows to initialise the
extension (i.e. run the init 3 and then init 5 commands):

setsebool -P xserver_object_manager true

If the boolean is set to false, the x-server log will indicate that "SELinux: Disabled
by boolean". Important note - If the boolean is not present in a policy then the object
manager will always be enabled (therefore if not required then either do not include
the object manager in the X-server build, add the boolean to the policy and set it to
false or add a disabled entry to the xorg.conf file as described in the Configure
OM Enforcement Mode section).

2.24.2.2 Determine OM X-extension Opcode
The object manager is treated as an X-server extension and its major opcode can be
queried using Xlib XQueryExtension function as follows:
/* Get the SELinux Extension opcode */
if (!XQueryExtension (dpy, "SELinux", &opcode, &event, &error)) {
perror ("XSELinux extension not available");
exit (1);
}
else
printf ("XQueryExtension for XSELinux Extension - Opcode: %d
Events: %d Error: %d \n", opcode, event, error);
/* Have XSELinux Object Manager */

2.24.2.3 Configure OM Enforcement Mode
If the X-server object manager needs to be run in a specific SELinux enforcement
mode, then the option may be added to the xorg.conf file (normally in
/etc/X11/xorg.conf.d). The option entries are as follows:

Page 109
The SELinux Notebook

"SELinux mode disabled"
"SELinux mode permissive"
"SELinux mode enforcing"
Note that the entry must be exact otherwise it will be ignored. An example entry is:
Section "Module"
SubSection "extmod"
Option "SELinux mode enforcing"
EndSubSection
EndSection

If there is no entry, the object manager will follow the current SELinux enforcement
mode.

2.24.2.4 The x_contexts File
The x_contexts file contains default context information that is required by the
OM to initialise the service and then label objects as they are created. The policy will
also need to be aware of the context information being used as it will use this to
enforce policy or transition new objects. A typical entry is as follows:
# object_type object_name context
selection PRIMARY system_u:object_r:clipboard_xselection_t:s0

or for polyinstantiation support:
# object_type object_name context
poly_selection PRIMARY system_u:object_r:clipboard_xselection_t:s0

The object_name can contain '*' for 'any' or '?' for 'substitute'.
The OM uses the selabel functions (such as selabel_lookup(3)) that are a
part of libselinux to fetch the relevant information from the x_contexts file.
The valid object_type entries are client, property, poly_property,
extension, selection, poly_selection and events.
The object_name entries can be any valid X-server resource name that is defined
in the X-server source code and can typically be found in the protocol.txt and
BuiltInAtoms source files (in the dix directory of the xorg-server source
package), or user generated via the Xlib libraries (e.g. XInternAtom).
Notes:
1. The way the XSELinux extension code works (see xselinux_label.c -
SELinuxAtomToSIDLookup) is that non-poly entries are searched for
first, if an entry is not found then it searches for a matching poly entry.
The reason for this behavior is that when operating in a secure environment all
objects would be polyinstantiated unless there are specific exemptions made
for individual objects to make them non-polyinstantiated. There would then be
a 'poly_selection *' or 'poly_property *' at the end of the section.

Page 110
The SELinux Notebook

2. For systems using the Reference Policy all X-clients connecting remotely will
be allocated a security context from the x_contexts file of:

# object_type object_name context
client * system_u:object_r:remote_t:s0

A full description of the x_contexts file format is given in the x_contexts File
section.

Page 111
The SELinux Notebook

2.24.3 SELinux Extension Functions
Function Name Minor Parameters Comments
Opcode
XSELinuxQueryVersion 0 None Returns the XSELinux version. F-20 returns 1.1
XSELinuxSetDeviceCreateContext 1 Context+Len Sets the context for creating a device object (x_device).
XSELinuxGetDeviceCreateContext 2 None Retrieves the context set by XSELinuxSetDeviceCreateContext.
XSELinuxSetDeviceContext 3 DeviceID + Context+Len Sets the context for creating the specified DeviceID object.
XSELinuxGetDeviceContext 4 DeviceID Retrieves the context set by XSELinuxSetDeviceContext.
XSELinuxSetWindowCreateContext 5 Context+Len Set the context for creating a window object (x_window).
XSELinuxGetWindowCreateContext 6 None Retrieves the context set by XSELinuxSetWindowCreateContext.
XSELinuxGetWindowContext 7 WindowID Retrieves the specified WindowID context.
XSELinuxSetPropertyCreateContext 8 Context + Len Sets the context for creating a property object (x_property).
XSELinuxGetPropertyCreateContext 9 None Retrieves the context set by XSELinuxSetPropertyCreateContext.
XSELinuxSetPropertyUseContext 10 Context + Len Sets the context of the property object to be retrieved when polyinstantiation is
being used.
XSELinuxGetPropertyUseContext 11 None Retrieves the property object context set by SELinuxSetPropertyUseContext.
XSELinuxGetPropertyContext 12 WindowID + AtomID Retrieves the context of the property atom object.
XSELinuxGetPropertyDataContext 13 WindowID + AtomID Retrieves the context of the property atom data.
XSELinuxListProperties 14 WindowID Lists the object and data contexts of properties associated with the selected
WindowID.
XSELinuxSetSelectionCreateContext 15 Context+Len Sets the context to be used for creating a selection object.
XSELinuxGetSelectionCreateContext 16 None Retrieves the context set by SELinuxSetSelectionCreateContext.
XSELinuxSetSelectionUseContext 17 Context+Len Sets the context of the selection object to be retrieved when polyinstantiation is
being used. See the XSELinuxListSelections function for an example.
XSELinuxGetSelectionUseContext 18 None Retrieves the selection object context set by SELinuxSetSelectionUseContext.

Page 112
The SELinux Notebook

Function Name Minor Parameters Comments
Opcode
XSELinuxGetSelectionContext 19 AtomID Retrieves the context of the specified selection atom object.
XSELinuxGetSelectionDataContext 20 AtomID Retrieves the context of the selection data from the current selection owner
(x_application_data object).
XSELinuxListSelections 21 None Lists the selection atom object and data contexts associated with this display. The
main difference in the listings is that when (for example) the PRIMARY selection
atom is polyinstantiated, multiple entries can returned. One has the context of the
atom itself, and one entry for each process (or x-client) that has an active
polyinstantiated entry, for example:

Atom: PRIMARY - label defined in the x_contexts file (this is also for non-poly listing):
Object Context: system_u:object_r:primary_xselection_t
Data Context: system_u:object_r:primary_xselection_t

Atom: PRIMARY - Labels for client 1:
Object Context: system_u:object_r:x_select_paste1_t
Data Context: system_u:object_r:x_select_paste1_t

Atom: PRIMARY - Labels for client 2:
Object Context: system_u:object_r:x_select_paste2_t
Data Context: system_u:object_r:x_select_paste2_t

XSELinuxGetClientContext 22 ResourceID Retrieves the client context of the specified ResourceID.

Table 12: The XSELinux Extension Functions - Supported by the object manager as X-protocol extensions. Note that some functions will
return the default contexts, while others (2, 6, 9, 11, 16, 18) will not return a value unless one has been set the the appropriate function (1, 5, 8,
10, 15, 17) by an SELinux-aware application.

Page 113
The SELinux Notebook

2.25 SE-PostgreSQL
This section gives an overview of PostgreSQL version 9.3 with the sepgsql
extension to support SELinux labeling. It assumes some basic knowledge of
PostgreSQL that can be found at: http://wiki.postgresql.org/wiki/Main_Page
It is important to note that PostgreSQL from version 9.3 has the necessary
infrastructure to support labeling of database objects via external 'providers'. An
sepgsql extension has been added that provides SELinux labeling. This is not
installed by default but as an option as outlined in the sections that follow. Because of
these changes the original version 9.0 patches are no longer supported (i.e. the SE-
PostgreSQL database engine is replaced by PostgreSQL database engine 9.3 plus the
sepgsql extension). A consequence of this change is that row level labeling is no
longer supported.
The features of sepgsql 9.3 and its setup are covered in the following document:
http://www.postgresql.org/docs/9.3/static/sepgsql.html

2.25.1 sepgsql Overview
The sepgsql extension adds SELinux mandatory access controls (MAC) to
database objects such as tables, columns, views, functions, schemas and sequences.
Figure 2.23 shows a simple database with one table, two columns and three rows,
each with their object class and associated security context (the Internal Tables
section shows these entries from the testdb database in the Notebook tarball
example). The database object classes and permissions are described in Appendix A -
Object Classes and Permissions.

database
context = 'unconfined_u:object_r:postgresql_db_t:s0'
This context is inherited from the database directory label - ls -Z /var/lib/pgsql/data

schema (db_schema)
security_label = 'unconfined_u:object_r:sepgsql_schema_t:s10'

table (db_table)
security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c20'

column 1 (db_column) column 2 (db_column)
security_label = security_label =
'unconfined_u:object_r:sep 'unconfined_u:object_r:se
gsql_table_t:s0:c30' pgsql_table_t:s0:c40'

Figure 2.23: Database Security Context Information - Showing the security
contexts that can be associated to a schema, table and columns.
To use SE-PostgreSQL each GNU / Linux user must have a valid PostgreSQL
database role (not to be confused with an SELinux role). The default installation
automatically adds a user called pgsql with a suitable database role.

Page 114
The SELinux Notebook

If a client is connecting remotely and labeled networking is required, then it is
possible to use IPSec or NetLabel as discussed in the SELinux Networking Support
section (the "Security-Enhanced PostgreSQL Security Wiki" [2] also covers these
methods of connectivity with examples).
Using Figure 2.24, the database client application (that could be provided by an API
for Perl/PHP or some other programming language) connects to a database and
executes SQL commands. As the SQL commands are processed by PostgreSQL, each
operation performed on an object is checked by the object manager (OM) to see if the
opration is allowed by the security policy or not.

Database Client
(e.g. psql)

SQL Query /
Results SE-PostgreSQL
Object Manager

Database
Check (sepgsql extension)
P ermissions
(filestore) SQL Engine

libselinux

SELinux
Kernel LSM Security
Kernel AVC Policy
Resources Server

Figure 2.24: SE-PostgreSQL Services - The Object Manager checks access
permissions for all objects under its control.
SE-PostgreSQL supports SELinux services via the libselinux library with AVC
audits being logged into the standard PostgreSQL file as described in the Logging
Security Events section.

2.25.2 Installing SE-PostgreSQL
The http://www.postgresql.org/docs/devel/static/sepgsql.html page contains all the
information required to install PostgreSQL and the sepgsql extension, however the
Notebook tarball sepgsql-9.3/README file also explains this and adds a simple
test database.

Page 115
The SELinux Notebook

2.25.3 SECURITY LABEL SQL Command
The 'SECURITY LABEL' SQL command has been added to PostgreSQL to allow
security providers to label or change a label on database objects. The command
format is:
SECURITY LABEL [ FOR provider ] ON
{
TABLE object_name |
COLUMN table_name.column_name |
AGGREGATE agg_name (agg_type [, ...] ) |
DATABASE object_name |
DOMAIN object_name |
EVENT TRIGGER object_name |
FOREIGN TABLE object_name
FUNCTION function_name ( [ [ argmode ] [ argname ] argtype
[, ...] ] ) |
LARGE OBJECT large_object_oid |
[ PROCEDURAL ] LANGUAGE object_name |
ROLE object_name |
SCHEMA object_name |
SEQUENCE object_name |
TABLESPACE object_name |
TYPE object_name |
VIEW object_name
} IS 'label'

The full syntax is defined at http://www.postgresql.org/docs/9.3/static/sql-security-
label.html and also in the security_label(7) man page. Some examples taken
from the Notebook tarball are:
--- These set the security label on objects (default provider
--- is SELinux):
SECURITY LABEL ON SCHEMA test_ns IS
'unconfined_u:object_r:sepgsql_schema_t:s0:c10';
SECURITY LABEL ON TABLE test_ns.info IS
'unconfined_u:object_r:sepgsql_table_t:s0:c20';
SECURITY LABEL ON COLUMN test_ns.info.user_name IS
'unconfined_u:object_r:sepgsql_table_t:s0:c30';
SECURITY LABEL ON COLUMN test_ns.info.email_addr IS
'unconfined_u:object_r:sepgsql_table_t:s0:c40';

2.25.4 Additional SQL Functions
The following functions have been added:
sepgsql_getcon() Returns the client security context.
sepgsql_mcstrans_in(text Translates the readable range of the
con) context into raw format provided the
mcstransd daemon is running.

sepgsql_mcstrans_out(text Translates the raw range of the context
con) into readable format provided the
mcstransd daemon is running.

Page 116
The SELinux Notebook

sepgsql_restorecon(text Sets security contexts on all database
specfile) objects (must be superuser) according to
the specfile. This is normally used for
initialisation of the database by the
sepgsql.sql script. If the parameter is
NULL, then the default
sepgsql_contexts file is used. See
selabel_db(5) details.

2.25.5 Additional postgresql.conf Entries
The postgresql.conf file supports the following additional entries to enable and
manage SE-PostgreSQL:
1. This entry is mandatory to enable the sepgsql extention to be loaded:

shared_preload_libraries = 'sepgsql'

2. These entries are optional and default to 'off'. The
'custom_variable_classes' entry must contain 'sepgsql' to enable
these to be configured.
# This entry allows sepgsql customised entries:
custom_variable_classes = 'sepgsql'

# These are the possible entries:
# This enables sepgsql to always run in permissive mode:
sepgsql.permissive = on

# This enables printing of audit messages regardless of
# the policy setting:
sepgsql.debug_audit = on

To view these settings the SHOW SQL statement can be used (psql output
shown):
SHOW sepgsql.permissive;
sepgsql.permissive
---------------
on
(1 row)

SHOW sepgsql.debug_audit;
sepgsql.debug_audit
---------------
on
(1 row)

Page 117
The SELinux Notebook

2.25.6 Logging Security Events
SE-PostgreSQL manages its own AVC audit entries in the standard PostgreSQL log
normally located within the /var/lib/pgsql/data/pg_log directory and by
default only errors are logged (Note that there are no SE-PostgreSQL AVC entries
added to the standard audit.log). The 'sepgsql.debug_audit = on' can be
set to log all audit events.

2.25.7 Internal Tables
To support the overall database operation PostgreSQL has internal tables in the
system catalog that hold information relating to databases, tables etc. This section will
only highlight the pg_seclabel table that holds the security label and other
references. The pg_seclabel is described in Table 13 that has been taken from
http://www.postgresql.org/docs/9.3/static/catalog-pg-seclabel.html.
Name Type References Comment
objoid oid any OID column The OID of the object this security label pertains to.
classoid oid pg_class.oid The OID of the system catalog this object appears in.
objsubid int4 For a security label on a table column, this is the column
number (the objoid and classoid refer to the table
itself). For all other objects this column is zero.
provider text The label provider associated with this label. Currently
only SELinux is supported.
label text The security label applied to this object.

Page 118
The SELinux Notebook

2.26 Apache SELinux Support
Apache web servers are supported by SELinux using the Apache policy modules from
the Reference Policy (httpd modules), however there is no specific Apache object
manger. There is though an SELinux-aware shared library and policy that will allow
finer grained access control when using Apache with threads. The additional Apache
module is called mod_selinux.so and has a supporting policy module called
mod_selinux.pp.
The mod_selinux policy module makes use of the typebounds Statement that
was introduced into version 24 of the policy (requires a minimum kernel of 2.6.28).
mod_selinux allows threads in a multi-threaded application (such as Apache) to be
bound within a defined set of permissions in that the child domain cannot have greater
permissions than the parent domain.
These components are known as 'Apache / SELinux Plus' and are described in the
sections that follow, however a full description including configuration details is
available from:
http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus
The objective of these Apache add-on services is to achieve a fully SELinux-aware
web stack (although not there yet). For example, currently the LAPP 29 (Linux,
Apache, PostgreSQL, PHP / Perl / Python) stack has the following support:
L Linux has SELinux support.

A Apache has partial SELinux support using the 'Apache SELinux Plus'
module.

P PostgreSQL has SELinux support using SE-PostgreSQL.

P PHP / Perl / Python are not currently SELinux-aware, however PHP and
Python do have support for libselinux functions in packages: PHP - with
the php-pecl-selinux package, Python - with the libselinux-
python package.

The "A secure web application platform powered by SELinux" [16] document gives a
good overview of the LAPP architecture.

2.26.1 mod_selinux Overview
What the mod_selinux module achieves is to allow a web application (or a 'request
handler') to be launched by Apache with a security context based on policy rather than
that of the web server process itself, for example:
1. A user sends an HTTP request to Apache that requires the services of a web
application (Apache may or may not apply HTTP authentication).
2. Apache receives the request and launches the web application instance to
perform the task:

29
This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack, however MySQL
is not SELinux-aware.

Page 119
The SELinux Notebook

a) Without mod_selinux enabled the web applications security context
is identical to the Apache web server process, it is therefore not
possible to restrict it privileges.
b) With mod_selinux enabled, the web application is launched with
the security context defined in the mod_selinux.conf file
(selinuxDomainVal <security_context> entry). It is also
possible to restrict its privileges as described in the Bounds Overview
section.
3. The web application exits, handing control back to the web server that replies
with the HTTP response.

2.26.2 Bounds Overview
Because multiple threads share the same memory segment, SELinux was unable to
check the information flows between these different threads when using setcon(3)
in pre 2.6.28 kernels. This meant that if a thread (the parent) should launch another
thread (a child) with a different security context, SELinux could not enforce the
different permissions.
To resolve this issue the typebounds statement was introduced with kernel support
in 2.6.28 that stops a child thread (the 'bounded domain') having greater privileges
than the parent thread (the 'bounding domain') i.e. the child thread must have equal or
less permissions than the parent.
For example the following typebounds statement and allow rules:

# parent | child
# domain | domain
typebounds httpd_t httpd_child_t;

allow httpd_t etc_t : file { getattr read };
allow httpd_child_t etc_t : file { read write };

State that the parent domain (httpd_t) has file : { getattr read }
permissions. However the child domain (httpd_child_t) has been given
file : { read write }. At run-time, this would not be allowed by the kernel
because the parent does not have write permission, thus ensuring the child domain
will always have equal or less privileges than the parent.
When setcon(3) is used to set a different context on a new thread without an
associated typebounds policy statement, then the call will return 'Operation not
permitted' and an SELINUX_ERR entry will be added to the audit log stating
'op=security_bounded_transition result=denied' with the old and
new context strings.
Should there be a valid typebounds policy statement and the child domain
exercises a privilege greater that that of the parent domain, the operation will be
denied and an SELINUX_ERR entry will be added to the audit log stating
'op=security_compute_av reason=bounds' with the context strings and
the denied class and permissions.

Page 120
The SELinux Notebook

2.26.2.1 Notebook Examples
The Notebook source tarball contains two demonstrations using setcon(3) with
threads and how the typebounds statement is used to allow a thread to be executed.
These are located in the libselinux/examples directory and are:
a) setcon_thread1_example.c - this example calls setcon in the main
process loop but also starts a thread. If the setcon_example.conf policy
module has been been loaded and a context of
"unconfined_u:unconfined_r:user_t:s0" selected, then an error message
should be displayed as follows:
setcon_raw - ERROR: Operation not permitted
This is because the setcon function cannot be run in a threaded environment
without a typebounds statement. Now load the
setcon_thread_example.conf policy module and then re-run the
example, it should now complete without error.
b) setcon_thread2_example.c - this functions as example 1, however it
calls setcon from a thread.

Page 121
The SELinux Notebook

3. SELinux Configuration Files

3.1 Introduction
This section explains each SELinux configuration file with its format, example
content and where applicable, any supporting SELinux commands or libselinux
library API function names.
Where configuration files have specific man pages, these are noted by adding the man
page section (e.g. semanage.config(5)).
This Notebook classifies the types of configuration file used in SELinux as follows:
1. Global Configuration files that affect the active policy and their supporting
SELinux-aware applications, utilities or commands. This Notebook will only
refer to the commonly used configuration files.
2. Policy Configuration files used by an active (run time) policy and their
supporting Policy Store Configuration files.
The Policy Store Configuration files are 'private'30 and managed by the
semanage(8) and semodule(8) commands31. These are used to build
the majority of the Policy Configuration files. This store will be moving as
part of a migration programme, see
https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration and
Policy Store Migration for details.
Note that there can be multiple policy configuration areas on a system (e.g.
/etc/selinux/targeted and /etc/selinux/mls), however only
one can be the active policy).
3. SELinux Kernel Configuration files located under the /sys/fs/selinux
directory and reflect the current configuration of SELinux for the active
policy. This area is used extensively by the libselinux library for
userspace object managers and other SELinux-aware applications. These files
and directories should not be updated by users (the majority are read only
anyway), however they can be read to check various configuration parameters.

3.1.1 Policy Store Migration
When distributions move to version 2.4 of libsemanage, libsepol, and
policycoreutils the policy module store will move from
/etc/selinux/<SELINUXTYPE>/modules to
/var/lib/selinux/<SELINUXTYPE>. Once the libraries are upgraded, all
policy stores must be migrated before any commands can be executed that modify or
use the store, for example semodule(8) or semanage(8). See
https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration for details.

30
They should NOT be edited as together they describe the 'policy'.
31
The system-config-selinux GUI (supplied in the polycoreutils-gui rpm) can also
be used to manage users, booleans and the general configuration of SELinux as it calls
semanage(8), however it does not manage all that the semanage command can (it also gets
bitter & twisted if there are no MCS/MLS labels on some operations).

Page 122
The SELinux Notebook

Once the migration is complete, it will be possible to build policies containing a
mixture of Reference Policy modules, kernel policy language modules and modules
written in the CIL language as shown in the following example:
# Compile and install a base and two modules written in kernel language:
checkmodule -o base.mod base.conf
semodule_package -o base.pp -m base.mod -f base.fc
checkmodule -m ext_gateway.conf -o ext_gateway.mod
semodule_package -o ext_gateway.pp -m ext_gateway.mod -f gateway.fc
checkmodule -m int_gateway.conf -o int_gateway.mod
semodule_package -o int_gateway.pp -m int_gateway.mod
semodule -s modular-test --priority 100 -i base.pp ext_gateway.pp int_gateway.pp

# Compile and install an updated module written in CIL:
semodule -s modular-test --priority 400 -i custom/int_gateway.cil

# Show a full listing of modules:
semodule -s modular-test --list-modules=full
400 int_gateway cil
100 base pp
100 ext_gateway pp
100 int_gateway pp

# Show a standard listing of modules:
semodule -s modular-test --list-modules=standard
base
ext_gateway
int_gateway

Note the use of --priority 100 and --priority 400 option that is available
after migration for semodule(8). This command has a number of new options,
with the most significant being:
1. Setting module priorities (-X | --priority), this is discussed in The
priority Option section.
2. Listing modules (--list-modules=full | standard). The 'full'
option shows all the available modules with their priority and policy format.
The 'standard' option will only show the highest priority, enabled modules.

3.1.1.1 The priority Option
32
Priorities allow multiple modules with the same name to exist in the policy store,
with the higher priority module included in the final kernel binary, and all lower
priority modules of the same name ignored. For example:
semodule --priority 100 --install distribution/apache.pp
semodule --priority 400 --install custom/apache.pp

Both apache modules are installed in the policy store as 'apache', but only the custom
apache module is included in the final kernel binary. The distribution apache module
is ignored. The --list-modules options can be used to show these:
# Show a full listing of modules:
semodule --list-modules=full
400 apache pp
100 base pp
100 apache pp

# Show a standard listing of modules:
semodule --list-modules=standard

32
This text has been derived from: http://marc.info/?l=selinux&m=141044198403718&w=2.

Page 123
The SELinux Notebook

base
apache

The main use case for this is the ability to override a distribution provided policy,
while keeping the distribution policy in the store.
This makes it easy for distributions, 3rd parties, configuration management tools (e.g.
puppet), local administrators, etc. to update policies without erasing each others
changes. This also means that if a distribution, 3rd party etc. updates a module,
providing the local customisation is installed at a higher priority, it will override the
new distribution policy.
This does require that policy managers adopt some kind of scheme for who uses what
priority. No strict guidelines currently exist, however the value used by the
semanage_migrate_store script is --priority 100 as this is assumed to
be migrating a distribution. If a value is not provided, semodule will use a default
of --priority 400 as it is assumed to be a locally customised policy.
When semodule builds a lower priority module when a higher priority is already
available, the following message will be given: "A higher priority <name>
module exists at priority <999> and will override the
module currently being installed at priority <111>".

3.1.1.2 Converting policy packages to CIL
A component of the update is to add a facility that converts compiled policy modules
(known as policy packages or the *.pp files) to CIL format. This is achieved via a
pp to CIL high level language conversion utility located at
/usr/libexec/selinux/hll/pp. This utility can be used manually as
follows:
cat module_name.pp | /usr/libexec/selinux/hll/pp > module_name.cil

There is no man page for 'pp', however the help text is as follows:
Usage: pp [OPTIONS] [IN_FILE [OUT_FILE]]

Read an SELinux policy package (.pp) and output the equivilent CIL.
If IN_FILE is not provided or is -, read SELinux policy package from
standard input. If OUT_FILE is not provided or is -, output CIL to
standard output.

Options:
-h, --help print this message and exit

3.2 Global Configuration Files
Listed in the sections that follow are the common configuration files used by SELinux
and are therefore not policy specific. The two most important files are:
• /etc/selinux/config - This defines the policy to be activated and its
enforcing mode.

Page 124
The SELinux Notebook

• /etc/selinux/semanage.conf - This is used by the SELinux policy
configuration subsystem for modular or CIL policies.

3.2.1 /etc/selinux/config File
If this file is missing or corrupt no SELinux policy will be loaded (i.e. SELinux is
disabled). The file man page is selinux_config(5), this is because 'config' has
already been taken. The config file controls the state of SELinux using the
following parameters:
SELINUX=enforcing|permissive|disabled
SELINUXTYPE=policy_name
SETLOCALDEFS=0|1
REQUIREUSERS=0|1
AUTORELABEL=0|1

Where:
SELINUX This entry can contain one of three values:
enforcing
SELinux security policy is enforced.
permissive
SELinux logs warnings (see the Auditing
SELinux Events section) instead of enforcing the
policy (i.e. the action is allowed to proceed).
disabled
No SELinux policy is loaded.
Note that this configures the global SELinux
enforcement mode. It is still possible to have domains
running in permissive mode and/or object managers
running as disabled, permissive or enforcing, when the
global mode is enforcing or permissive.
SELINUXTYPE The policy_name is used as the directory name
where the active policy and its configuration files will
be located. The system will then use this information to
locate and load the policy contained within this
directory structure.
The policy directory must be located at:
/etc/selinux/<policy_name>/
SETLOCALDEFS This optional field should be set to 0 (or the entry
removed) as the policy store management
infrastructure (semanage(8) / semodule(8)) is
now used.
If set to 1, then init(8) and load_policy(8)
will read the local customisation for booleans and

Page 125
The SELinux Notebook

users.
REQUIRESEUSERS This optional field can be used to fail a login if there is
no matching or default entry in the seusers file or if
the file is missing.
It is checked by the libselinux function
getseuserbyname(3) that is used by SELinux-
aware login applications such as PAM(8).
If it is set to 0 or the entry missing:
getseuserbyname(3) will return the GNU /
Linux user name as the SELinux user.
If it is set to 1:
getseuserbyname(3) will fail.
AUTORELABEL This is an optional field. If set to '0' and there is a file
called .autorelabel in the root directory, then on a
reboot, the loader will drop to a shell where a root
logon is required. An administrator can then manually
relabel the file system.
If set to '1' or the parameter name is not used (the
default) there is no login for manual relabeling,
however should the /.autorelabel file exists, then
the file system will be automatically relabeled using
fixfiles -F restore.
In both cases the /.autorelabel file will be
removed so the relabel is not done again.

Example config file contents are:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
#
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

3.2.2 /etc/selinux/semanage.conf File
The semanage.config(5) file controls the configuration and actions of the
semanage(8) and semodule(8) set of commands using the following
parameters:
module-store = method

Page 126
The SELinux Notebook

[verify kernel]
path = <application_to_run>
args = <arguments>
[end]

[verify module]
path = <application_to_run>
args = <arguments>
[end]

[verify linked]
path = <application_to_run>
args = <arguments>
[end]

[load_policy]
path = <application_to_run>
args = <arguments>
[end]

[setfiles]
path = <application_to_run>
args = <arguments>
[end]

[sefcontext_compile]
path = <application_to_run>
args = <arguments>
[end]

[load_policy]
path = <application_to_run>
args = <arguments>
[end]

# libsepol (v2.4) with CIL support add the following:
store-root = <path>
compiler-directory = <path>
ignore-module-cache = true|false
target-platform = selinux | xen

Where:
module-store The method can be one of four options:
direct libsemanage will write

Page 127
The SELinux Notebook

directly to a module store.
This is the default value.
source libsemanage
manipulates a source
SELinux policy.
/foo/bar Write via a policy
management server, whose
named socket is at
/foo/bar. The path must
begin with a '/'.
foo.com:4242 Establish a TCP connection
to a remote policy
management server at
foo.com. If there is a
colon then the remainder is
interpreted as a port
number; otherwise default
to port 4242.
policy-version This optional entry can contain a policy version
number, however it is normally commented out
as it then defaults to that supported by the system.
expand-check This optional entry controls whether hierarchy
checking on module expansion is enabled (1) or
disabled (0). The default is 0.
It is also required to detect the presence of policy
rules that are to be excluded with neverallow
rules.
file-mode This optional entry allows the file permissions to
be set on runtime policy files. The format is the
same as the mode parameter of the chmod
command and defaults to 0644 if not present.
save-previous This optional entry controls whether the previous
module directory is saved (TRUE) after a
successful commit to the policy store. The default
is to delete the previous version (FALSE).
save-linked This optional entry controls whether the
previously linked module is saved (TRUE) after a
successful commit to the policy store. Note that
this option will create a base.linked file in
the module policy store.
The default is to delete the previous module
(FALSE).
disable- This optional entry controls whether the
genhomedircon embedded genhomedircon function is run

Page 128
The SELinux Notebook

when using the semanage(8) command. The
default is FALSE.
handle-unknown This optional entry controls the kernel behaviour
for handling permissions defined in the kernel but
missing from the policy (that are declared at the
start of the base.conf (loadable policy) or
policy.conf (monolithic policy)).
The options are: allow the permission, reject
by not loading the policy or deny the
permission. The default is deny. See the
SELinux Filesystem section for how these are
reported in /sys/fs/selinux.
Note: to activate any change, the base policy
needs to be rebuilt with the semodule -B
command.
bzip-blocksize This optional entry determines whether the
modules are compressed or not with bzip. If the
entry is 0, then no compression will be used (this
is required with tools such as sechecker and
apol). This can also be set to a value between 1
and 9 that will set the block size used for
compression (bzip will multiply this by
100,000, so '9' is faster but uses more memory).
bzip-small When this optional entry is set to TRUE the
memory usage is reduced for compression and
decompression (the bzip -s or --small
option). If FALSE or no entry present, then does
not try to reduce memory requirements.
usepasswd When this optional entry is set to TRUE
semanage will scan all password records for
home directories and set up their labels correctly.
If set to FALSE (the default if no entry present),
then only the /home directory will be
automatically re-labeled.
ignoredirs With a list of directories to ignore (separated by
';') when setting up users home directories. This
is used by some distributions to stop labeling
/root as a home directory.
[verify kernel] Start an additional set of entries that can be used
to validate the kernel policy with an external
application during the build process. There may
be multiple [verify kernel] entries.
The validation process takes place before the
policy is allowed to be inserted into the store with

Page 129
The SELinux Notebook

a worked example shown in Appendix E - Policy
Validation Example.
[verify module] Start an additional set of entries that can be used
to validate each module by an external
application during the build process. There may
be multiple [verify module] entries.
[verify linked] Start an additional set of entries that can be used
to validate module linking by an external
application during the build process. There may
be multiple [verify linked] entries.
[load_policy] Replace the default load policy application with
this new policy loader. Defaults are either:
/sbin/load_policy or
/usr/sbin/load_policy.
[setfiles] Replace the default set files application with this
new set files. Defaults are either:
/sbin/setfiles or
/usr/sbin/setfiles.
[sefcontexts_compile] Replace the default file context build application
with this new builder. Defaults are either:
/sbin/sefcontexts_compile or
/usr/sbin/sefcontexts_compile.

For libsepol (v2.4) with CIL support add the following entries:
store-root Specify an alternative store root path to use. The
default is "/var/lib/selinux".
compiler-directory Specify an alternate directory that will hold the
High Level Language (HLL) to CIL compilers.
The default is
"/usr/libexec/selinux/hll".
ignore-module-cache Whether or not to ignore the cache of CIL
modules compiled from HLL. The default is
false.
target-platform Target platform for generated policy. Default is
"selinux", the alternate is "xen".

Example semanage.config file contents are:

# /etc/selinux/semanage.conf

module-store = direct
expand-check = 0

[verify kernel]
path = /usr/local/bin/validate

Page 130
The SELinux Notebook

args = $@
[end]

3.2.3 /etc/selinux/restorecond.conf and restorecond-
user.conf Files
The restorecond.conf file contains a list of files that may be created by
applications with an incorrect security context. The restorecond(8) daemon will
then watch for their creation and automatically correct their security context to that
specified by the active policy file context configuration files 33 (located in the
/etc/selinux/<policy_name>/contexts/files directory).
Each line of the file contains the full path of a file or directory. Entries that start with
a tilde (~) will be expanded to watch for files in users home directories (e.g.
~/public_html would cause the daemon to listen for changes to public_html
in all logged on users home directories).
Note that it is possible to run restorecond in a user session using the -u option
(see restorecond(8)). This requires a restorecond-user.conf file to be
installed as shown in the examples below.

Example restorecond.conf file contents are:

# /etc/selinux/restorecond.conf

/etc/services
/etc/resolv.conf
/etc/samba/secrets.tdb
/etc/mtab
/var/run/utmp
/var/log/wtmp

Example restorecond-user.conf file contents are:

# /etc/selinux/restorecond-user.conf

# This entry expands to listen for all files created for all
# logged in users within their home directories:
~/*
~/public_html/*

3.2.4 /etc/selinux/newrole_pam.conf
The optional newrole_pam.conf file is used by newrole(1) and maps
applications or commands to PAM(8) configuration files. Each line contains the
executable file name followed by the name of a pam configuration file that exists in
/etc/pam.d.

33
The daemon uses functions in libselinux such as matchpathcon(3) to manage the context
updates.

Page 131
The SELinux Notebook

3.2.5 /etc/sestatus.conf File
The sestatus.conf(5) file is used by the sestatus(8) command to list files
and processes whose security context should be displayed when the -v flag is used
(sestatus -v).
The file has the following parameters:
[files]
List of files to display context

[process]
List of processes to display context

Example sestatus.conf file contents are:

# /etc/sestatus.conf

[files]
/etc/passwd
/etc/shadow
/bin/bash
/bin/login
/bin/sh
/sbin/agetty
/sbin/init
/sbin/mingetty
/usr/sbin/sshd
/lib/libc.so.6
/lib/ld-linux.so.2
/lib/ld.so.1

[process]
/sbin/mingetty
/sbin/agetty
/usr/sbin/sshd

3.2.6 /etc/security/sepermit.conf File
The sepermit.conf(5) file is used by the pam_sepermit.so module to
allow or deny a user login depending on whether SELinux is enforcing the policy or
not. An example use of this facility is the Red Hat kiosk policy where a terminal can
be set up with a guest user that does not require a password, but can only log in if
SELinux is in enforcing mode.
The entry is added to the appropriate /etc/pam.d configuration file, with the
example shown being the /etc/pam.d/gdm file (the PAM Login Process section
describes PAM in more detail):
#%PAM-1.0
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth required pam_succeed_if.so user != root quiet
auth required pam_env.so
auth substack system-auth
auth optional pam_gnome_keyring.so
account required pam_nologin.so
account include system-auth

Page 132
The SELinux Notebook

password include system-auth
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session optional pam_gnome_keyring.so auto_start
session include system-auth

The usage is described in pam_sepermit(5), with the following example that
describes the configuration:
# /etc/security/sepermit.conf
#
# Each line contains either:
# - an user name
# - a group name, with @group syntax
# - a SELinux user name, with %seuser syntax

# Each line can contain an optional argument:
# exclusive - only single login session will be allowed for
# the user and the user's processes will be
# killed on logout
#
# ignore - The module will never return PAM_SUCCESS status
# for the user.

# An example entry for 'kiosk mode':
xguest:exclusive

3.3 Policy Store Configuration Files
Depending on the release being used policy stores will be located at:
• /etc/selinux/<policy_name>/modules - This is the default for
systems that support versions < 2.4 of libsemanage, libsepol, and
policycoreutils.
• /var/lib/selinux/<policy_name>/modules - This is the default
for systems that support versions >= 2.4 of libsemanage, libsepol, and
policycoreutils. The base (/var/lib/selinux) may be overridden
by the store-root parameter defined in the semanage.conf(5) file.
The migration process from previous releases is described at
https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration.
Note that there can be multiple policy stores on a system, each file described in this
section is relative to the ./<policy_name> as discussed above.
The Policy Store files are either installed, updated or built by the semodule(8) and
semanage(8) commands as a part of the build process. The resulting files will
either be copied over to the Policy Configuration files area, or used to rebuild the
kernel binary policy located at /etc/selinux/<policy_name>/policy.
All files may have comments inserted where each line must have the '#' symbol to
indicate the start of a comment.

Page 133
The SELinux Notebook

The command options and outputs shown in the text are based on the current F-20
build. After the migration programme, some command options and their output will
change.

3.3.1 modules/ Files
The policy store has two lock files that are used by libsemanage for managing the
store. Their format is not relevant to policy construction:
semanage.read.LOCK
semanage.trans.LOCK

3.3.2 modules/active/base.pp File
This is the packaged base policy that contains the mandatory modules and policy
components such as object classes, permission declarations and initial SIDs.

3.3.3 modules/active/base.linked File
This is only present if the save-linked is set to TRUE as described in the
/etc/selinux/semanage.conf section. It contains the modules that have been
linked using the semodule_link(8) command.

3.3.4 modules/active/commit_num File
This is a binary file used by libsemanage for managing updates to the store. The
format is not relevant to policy construction.

3.3.5 modules/active/file_contexts.template File
This contains a copy all the modules 'Labeling Policy File' entries (e.g. the
<module_name>.fc files) that have been extracted from the base.pp and the
loadable modules in the modules/active/modules directory.
The entries in the file_contexts.template file are then used to build the
following files as shown in Figure 3.1:
1. homedir_template file that will be used to produce the
file_contexts.homedirs file which will then become the policies
./contexts/files/file_contexts.homedirs file.
2. file_contexts file that will become the policies
./contexts/files/file_contexts file.
Note that as a part of the semanage build process, these two files will also have
file_contexts.bin and file_contexts.homedirs.bin files present in
the Policy Configuration Files ./contexts/files directory. This is because
semanage requires these in the Perl compatible regular expression (PCRE) internal
format. They are generated by the sefcontext_compile(8) utility.

Page 134
The SELinux Notebook

/etc/selinux/
<policy_name>/
modules/active Policy .fc files from
These files are used by the Modules and Base
/etc/selinux/ semanage and semodule
<policy_name>/ command set.
contexts/files
T hese files are used by
file labeling utilities Are used to build the file:
(setfiles, file_contexts.template
fixfiles &
restorecon)

Whose contents are used Whose contents are used
file_contexts to build the file: to build the file:
file_contexts homedir_template

genhomedircon

file_contexts. Whose contents are used to build
homedirs the file:
file_contexts.homedirs

Figure 3.1: File Context Configuration Files - The two files copied to the policy
area will be used by the file labeling utilities to relabel files.

The homedir_template and file_contexts files are built is as follows:
homedir_template - Any line in the file_contexts.template file
that has the keywords HOME_ROOT, HOME_DIR and/or USER are extracted
and added to the homedir_template file. This is because these keywords
are used to identify entries that are associated to a users home directory area.
These lines may also have the ROLE keyword declared.
The homedir_template file will then be processed by
genhomedircon(8)34 to generate individual SELinux user entries in the
file_contexts.homedirs file as discussed in the
./modules/active/file_contexts.homedirs section.
These are examples of one line being processed as described above, taken
from the F-20 targeted policy:
The master file_contexts.template entry:

HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0

34
The genhomedircon command has now been built into the libsemanage library as a
function to build the file_contexts.homedirs file via semanage(8).

Page 135
The SELinux Notebook

The homedir_template entry is created as:

HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0

The file_contexts.homedirs entries are created by
genhomedircon for the SELinux users extracted from the seusers file as
follows:
# Home Context for any Linux user that is assigned
# the SELinux user unconfined_u
/home/[^/]*/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0

# Home Context for user root
/root/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0

file_contexts - All other lines are extracted and added to the
file_contexts file as they are files not associated to a users home
directory.

The format of the file_contexts.template file is as follows:
Each line within the file consists of the following:
pathname_regexp [file_type] opt_security_context

Where:
pathname_regexp An entry that defines the pathname that may be
in the form of a regular expression.
The metacharacters '^' (match beginning of line)
and '$' (match end of line) are automatically
added to the expression by the routines that
process this file, however they can be over-
ridden by using '.*' at either the beginning or
end of the expression (see the example
file_contexts files below).
There are also keywords of HOME_ROOT,
HOME_DIR, ROLE and USER that are used by
file labeling commands (see the keyword
definitions below and the
./modules/active/homedir_template
file section for their usage).
file_type One of the following optional file_type
entries (note if blank means "all file types"):
'-b' - Block Device '-c' - Character Device
'-d' - Directory '-p' - Named Pipe (FIFO)
'-l' - Symbolic Link '-s' - Socket File

Page 136
The SELinux Notebook

'--' - Ordinary file
By convention this entry is known as 'file type',
however it really represents the 'file object class'.
opt_security_context This entry can be either:
a. The security context, including the MLS /
MCS level or range if applicable that
will be assigned to the file.
b. A value of <<none>> can be used to
indicate that matching files should not be
re-labeled.

Keywords that can be in the file_contexts.template file are:
HOME_ROOT This keyword is replaced by the GNU / Linux users root home
directory, normally '/home' is the default.
HOME_DIR This keyword is replaced by the GNU / Linux users home
directory, normally '/home/' is the default.
USER This keyword will be replaced by the users GNU / Linux user id.
ROLE This keyword is replaced by the 'prefix' entry from the
users_extra configuration file that corresponds to the
SELinux users user id. Example users_extra configuration
file entries are:
user user_u prefix user;
user staff_u prefix staff;

It is used for files and directories within the users home directory
area.
The prefix can be added by the semanage login command as
follows (although note that the -P option is suppressed when help
is displayed as it is generally it is not used (defaults to user) -
see http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701
for further information):
# Add a Linux user:
adduser rch

# Modify staff_u SELinux user and prefix:
semanage user -m -R staff_r -P staff staff_u

# Associate the SELinux user to the Linux user:
semanage login -a -s staff_u rch

Example file_contexts.template contents from targeted policy:

# ./modules/active/file_contexts.template - These sample entries

Page 137
The SELinux Notebook

# have been taken from the targeted policy and show the
# HOME_DIR, HOME_ROOT and USER keywords whose lines will be
# extracted and added to the homedir_template file that is
# used to manage user home directory entries.

/.* system_u:object_r:default_t:s0
/[^/]+ -- system_u:object_r:etc_runtime_t:s0
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0
/nsr(/.*)? system_u:object_r:var_t:s0
/sys(/.*)? system_u:object_r:sysfs_t:s0
...
/etc/ntop.* system_u:object_r:ntop_etc_t:s0
HOME_DIR/.+ system_u:object_r:user_home_t:s0
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0
...
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0
...
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0
...
HOME_ROOT/\.journal <<none>>

3.3.6 modules/active/file_contexts File
This file becomes the policies ./contexts/files/file_contexts file and is
built from entries in the ./modules/active/file_contexts.template
file as explained above and shown in Figure 3.1. It is then used by the file labeling
utilities to ensure that files and directories are labeled according to the policy.
The format of the file_contexts file is the same as the
./modules/active/file_contexts.template file.
The USER keyword is replaced by the users GNU / Linux user id when the file
labeling utilities are run.

Example file_contexts contents:

# ./modules/active/file_contexts - These sample entries have
# been taken from the targeted policy.
# The keywords HOME_DIR, HOME_ROOT, USER and ROLE have been
# removed and put in the homedir_template file.

/.* system_u:object_r:default_t:s0
/[^/]+ -- system_u:object_r:etc_runtime_t:s0
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0
/nsr(/.*)? system_u:object_r:var_t:s0
/sys(/.*)? system_u:object_r:sysfs_t:s0
/xen(/.*)? system_u:object_r:xen_image_t:s0
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0
/mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0
/bin/.* system_u:object_r:bin_t:s0
/dev/.* system_u:object_r:device_t:s0
/usr/.* system_u:object_r:usr_t:s0
/var/.* system_u:object_r:var_t:s0
/run/.* system_u:object_r:var_run_t:s0
/srv/.* system_u:object_r:var_t:s0
/tmp/.* <<none>>

Page 138
The SELinux Notebook

# ./contexts/files/file_contexts - Sample entries from the
# MLS reference policy.

# Notes:
# 1) The fixed_disk_device_t is labeled SystemHigh (s15:c0.c255)
# as it needs to be trusted. Also some logs and configuration
# files are labeled SystemHigh as they contain sensitive
# information used by trusted applications.
#
# 2) Some directories (e.g. /tmp) are labeled
# SystemLow-SystemHigh (s0-s15:c0.c255) as they will
# support polyinstantiated directories.

/.* system_u:object_r:default_t:s0
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0
/mnt/[^/]*/.* <<none>>
/dev/.*mouse.* -c system_u:object_r:mouse_device_t:s0
/dev/.*tty[^/]* -c system_u:object_r:tty_device_t:s0
/dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s15:c0.c255
/var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t:s0
/dev/(raw/)?rawctl -c system_u:object_r:fixed_disk_device_t:s15:c0.c255
/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255
/dev/pts -d system_u:object_r:devpts_t:s0-s15:c0.c255
/var/log -d system_u:object_r:var_log_t:s0-s15:c0.c255
/var/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255
/var/run -d system_u:object_r:var_run_t:s0-s15:c0.c255
/usr/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255

3.3.7 modules/active/homedir_template File
This file is built from entries in the file_contexts.template file (as shown in
Figure 3.1) and explained in the
./modules/active/file_contexts.template section.
The file is used by genhomedircon, semanage login or semanage user to
generate individual user entries in the file_contexts.homedirs file.
The homedir_template file has the same per line format as the
./modules/active/file_contexts.template file.

Example file contents:
# ./modules/active/homedir_template - These sample entries have
# been taken from the targeted policy and show the
# HOME_DIR, HOME_ROOT and USER keywords that are used to manage
# users home directories:

HOME_DIR/.+ system_u:object_r:user_home_t:s0
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0
HOME_ROOT/\.journal <<none>>

3.3.8 modules/active/file_contexts.homedirs File
This file becomes the policies
./contexts/files/file_contexts.homedirs file when building policy
as shown in Figure 3.1. It is then used by the file labeling utilities to ensure that users
home directory areas are labeled according to the policy.

Page 139
The SELinux Notebook

The file can be built by the genhomedircon command (that just calls
/usr/sbin/semodule -Bn) or if using semanage with user or login
options to manage users, where it is called automatically as it is now a libsepol
library function.
The file_contexts.homedirs file has the same per line format as the
./modules/active/file_contexts.template file, however the
HOME_DIR, ROOT_DIR, ROLE and USER keywords will be replaced as explained in
the keyword definitions section above.

Example file_contexts.homedirs contents:

# ./modules/active/file_contexts.homedirs - These sample entries
# have been taken from the targeted policy and show that
# the HOME_DIR, HOME_ROOT and USER keywords have been replaced
# by entries as explained above.
#
# Home Context for the default user (unconfined_u)
/home/[^/]*/.+ unconfined_u:object_r:user_home_t:s0
/home/[^/]*/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0
...
/tmp/gconfd-.*/.* -- unconfined_u:object_r:gconf_tmp_t:s0
/tmp/gconfd-.* -d unconfined_u:object_r:user_tmp_t:s0

# Home Context for user rch
/home/rch/.+ staff_u:object_r:user_home_t:s0
/home/rch/.maildir(/.*)? staff_u:object_r:mail_home_rw_t:s0
...
/tmp/gconfd-rch/.* -- staff_u:object_r:gconf_tmp_t:s0
/tmp/gconfd-rch -d staff_u:object_r:user_tmp_t:s0

# Home Context for user root
/root/.+ unconfined_u:object_r:user_home_t:s0
/root/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0
...
/tmp/gconfd-root/.* -- unconfined_u:object_r:gconf_tmp_t:s0
/tmp/gconfd-root -d unconfined_u:object_r:user_tmp_t:s0

3.3.9 modules/active/netfilter_contexts &
netfilter.local File
These files are not used at present. There is code to produce a
netfilter_contexts file for use by the GNU/Linux iptables service35 in the
Reference Policy that would generate a file similar to the example below, however
there seems much debate on how they should be managed (see bug 201573 - Secmark
iptables integration for details).

3.3.10 modules/active/policy.kern File
This is the binary policy file built by either the semanage(8) or semodule(8)
commands (depending on the configuration action), that is then becomes the
./policy/policy.[ver] binary policy that will be loaded into the kernel.

35
This uses SECMARK labeling that has been utilised by SELinux as described in the SELinux
Networking Support section.

Page 140
The SELinux Notebook

3.3.11 modules/active/seusers.final and seusers Files
The seusers.final file maps GNU / Linux users to SELinux users and becomes
the policies seusers36 file as discussed in the ./seusers section. The
seusers.final file is built or modified when:
1. Building a policy where an optional seusers file has been included in the
base package via the semodule_package(8) command (signified by the
-s flag) as follows37:

semodule_package -o base.pp -m base.mod -s seusers ...

The seusers file would be extracted by the subsequent semodule
command when building the policy to produce the seusers.final file.
2. The semanage login command is used to map GNU / Linux users to
SELinux users as follows:
semanage login -a -s staff_u rch

This action will update the seusers file that would then be used to produce
the seusers.final file with both policy and locally defined user mapping.
It is also possible to associate a GNU / Linux group of users to an SELinux
user as follows:
semanage login -a -s staff_u %staff_group

The format of the seusers.final & seusers files are as follows:

[%]user_id:seuser_id[:range]

Where:
user_id Where user_id is the GNU / Linux user identity. If this is
a GNU / Linux group_id then it will be preceded with the
'%' sign as shown in the example below.
seuser_id The SELinux user identity.
range The optional level or range.

Example seusers.final file contents:

# ./modules/active/seusers.final
system_u:system_u
root:root

36
Many seusers make confusion: The ./modules/active/seusers file is used to hold
initial seusers entries, the ./modules/active/seusers.final file holds the complete
entries that then becomes the policy ./seusers file.
37
The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial
seusers file.

Page 141
The SELinux Notebook

__default__:user_u

Example semanage login command to add a GNU / Linux user mapping:

# This command will add the rch:user_u entry in the seusers
# file:

semanage login -a -s user_u rch

The resulting seusers file would be:

# ./modules/active/seusers

rch:user_u

The seusers.final file that will become the ./<policy_name>/seusers
file is as follows:
# ./modules/active/seusers.final

system_u:system_u
root:root
__default__:user_u
rch:user_u

Example semanage login command to add a GNU / Linux group mapping:

# This command will add the %user_group:user_u entry in the
# seusers file:

semanage login -a -s user_u %user_group

The resulting seusers file would be:

# ./modules/active/seusers

rch:user_u
%user_group:user_u

The seusers.final file that will become the ./<policy_name>/seusers
file is as follows:
# ./modules/active/seusers.final

system_u:system_u
root:root
__default__:user_u
rch:user_u
%user_group:user_u

Page 142
The SELinux Notebook

3.3.12 modules/active/users_extra, users_extra.local
and users.local Files
These three files work together to describe SELinux user information as follows:
1. The users_extra and users_extra.local files are used to map a
prefix to users home directories as discussed in the
./modules/active/file_contexts.template file section, where
it is used to replace the ROLE keyword. The prefix is linked to an SELinux
user id and should reflect the users role. The semanage user command
will allow a prefix to be added via the -P flag (although no longer used by
policies as discussed in the
./modules/active/file_contexts.template file section).
The users_extra file contains all the policy prefix entries, and the
users_extra.local file contains those generated by the semanage
user command.
The users_extra file can optionally be included in the base package via
the semodule_package(8) command (signified by the -u flag) as
follows38:
semodule_package -o base.pp -m base.mod -u users_extra ...

The users_extra file would then be extracted by a subsequent
semodule command when building the policy.
2. The users.local file is used to add new SELinux users to the policy
without editing the policy source itself (with each line in the file following a
policy language user Statement). This is useful when only the Reference
Policy headers are installed and additional users need to added. The
semanage user command will allow a new SELinux user to be added that
would generate the user.local file and if a -P flag has been specified,
then a users_extra.local file is also updated (note: if this is a new
SELinux user and a prefix is not specified a default prefix of user is
generated).
The sections that follow will:
• Define the format and show example users_extra and
users_extra.local files.
• Execute an semanage user command that will add a new SELinux user
and associated prefix, and show the resulting users_extra,
users_extra.local and users.local files.
Note that each line of the users.local file contains a user statement that
is defined in the policy language user Statement section, and will be built
into the policy via the semanage command.

The format of the users_extra & users_extra.local files are as follows:
38
The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial
users_extra file.

Page 143
The SELinux Notebook

user seuser_id prefix prefix_id;

Where:
user The user keyword.
seuser_id The SELinux user identity.
prefix The prefix keyword.
prefix_id An identifier that will be used to replace the ROLE keyword
within the ./modules/active/homedir_template
file when building the
./modules/active/file_contexts.homedirs
file for the relabeling utilities to set the security context on
users home directories.

Example users_extra file contents:

# ./modules/active/users_extra entries, note that the
# users_extra.local file contents are similar and generated by
# the semanage user command.

user user_u prefix user;
user staff_u prefix user;
user sysadm_u prefix user;
user root prefix user;

Example semanage user command to add a new SELinux user:

# This command will add the user test_u prefix staff entry in
# the users_extra.local file:

semanage user -a -R staff_r -P staff test_u

The resulting users_extra.local file is as follows:

# ./modules/active/users_extra.local

user test_u prefix staff;

The resulting users_extra file is as follows:

# ./modules/active/users_extra

user user_u prefix user;
user staff_u prefix user;
user sysadm_u prefix user;
user root prefix user;
user test_u prefix staff;

The resulting users.local file is as follows:

Page 144
The SELinux Notebook

# ./modules/active/users.local file entry:

user test_u roles { staff_r } level s0 range s0;

3.3.13 modules/active/booleans.local File
This file is created and updated by the semanage boolean command and holds
boolean value as requested.

Example semanage boolean command to modify a boolean value:

# This command will add an entry in the booleans.local
# file and set the boolean value to 'off':

semanage boolean -m -0 ext_gateway_audit

The resulting booleans.local file would be:

# ./modules/active/booleans.local

ext_gateway_audit=0

3.3.14 modules/active/file_contexts.local File
This file is created and updated by the semanage fcontext command. It is used
to hold file context information on files and directories that were not delivered by the
core policy (i.e. they are not defined in any of the *.fc files delivered in the base and
loadable modules).
The semanage command will add the information to the policy stores
file_contexts.local file and then copy this file to the
./contexts/files/file_contexts.local file, where it will be used when
the file context utilities are run.
The format of the file_contexts.local file is the same as the
./modules/active/file_contexts.template file.

Example semanage fcontext command to add a new entry:

# This command will add an entry in the file_contexts.local
# file:

semanage fcontext -a -t user_t /usr/move_file

# Note that the type (-t flag) must exist in the policy
# otherwise the command will fail.

The resulting file_contexts.local file would be:

# ./modules/active/file_contexts.local

Page 145
The SELinux Notebook

/usr/move_file system_u:object_r:user_t

3.3.15 modules/active/interfaces.local File
This file is created and updated by the semanage interface command to hold
network interface information that was not delivered by the core policy (i.e. they are
not defined in base.conf file). The new interface information is then built into the
policy by the semanage(8) command.
Each line of the file contains a netifcon statement that is defined along with
examples in the netifcon Statement section.

3.3.16 modules/active/nodes.local File
This file is created and updated by the semanage node command to hold network
address information that was not delivered by the core policy (i.e. they are not defined
in base.conf file). The new node information is then built into the policy by the
semanage(8) command.
Each line of the file contains a nodecon statement that is defined along with
examples in the policy language nodecon Statement section.

3.3.17 modules/active/ports.local File
This file is created and updated by the semanage port command to hold network
port information that was not delivered by the core policy (i.e. they are not defined in
base.conf file). The new port information is then built into the policy by the
semanage(8) command.
Each line of the file contains a portcon statement that is defined along with
examples in the policy language portcon Statement section.

3.3.18 modules/active/preserve_tunables File
This file will only exist if the policy build specified that tunables should be preserved,
if so they would be converted to booleans by the policy build process.

3.3.19 modules/active/disable_dontaudit File
This file will only exist if the policy build specified that dontaudit rules should be
disabled.

3.3.20 modules/active/modules Directory Contents
This directory contains loadable modules (<module_name>.pp or when disabled
<module_name>.pp.disabled) that have been built by the
semodule_package command and placed in the store by the semodule or
semanage module -a commands as shown in the following example:

# Package the module move_file_c:

Page 146
The SELinux Notebook

semodule_package -o move_file_c.pp -m move_file_c.mod -f
move_file.fc

# Then to install it in the store (at /etc/selinux/modular-test/
# modules/active/modules/move_file_c.pp) and build the binary
# policy file, run the semodule command:

semodule -v -s modular-test -i move_file_c.pp
# Or:
semanage module -a -S modular-test move_file_c.pp

The modules within the policy store may be compressed or not depending on the
value of the bzip-blocksize parameter in the semanage.conf file. The
modules and their status can be listed using the semanage module -l command
as shown below.
semanage module -l
ext_gateway 1.1.0
int_gateway 1.1.0
move_file 1.1.0
netlabel 1.0.0 Disabled

3.4 Policy Configuration Files
Each file discussed in this section is relative to the policy name as follows:
/etc/selinux/<policy_name>
The majority of files are installed by the Reference Policy, semanage(8) or
semodule(8) commands. It is possible to build custom monolithic policies that
only use the files installed in this area (i.e. do not use semanage or semodule).
For example the simple monolithic policy described in the Notebook source tarball
could run at init 3 (i.e. no X-Windows) and only require the following
configuration files:
./policy/policy.29 - The binary policy loaded into the kernel.
./context/files/file_contexts - To allow the filesystem to be
relabeled.
If the simple policy is to run at init 5, (i.e. with X-Windows) then an additional
two files are required:
./context/dbus_contexts - To allow the dbus messaging service to run
under SELinux.
./context/x_contexts - To allow the X-Windows service to run under
SELinux.

Page 147
The SELinux Notebook

3.4.1 seusers File
The seusers(5) file is used by login programs (normally via the libselinux
library) and maps GNU / Linux users (as defined in the user / passwd files) to
SELinux users (defined in the policy). A typical login sequence would be:
• Using the GNU / Linux user_id, lookup the seuser_id from this file. If
an entry cannot be found, then use the __default__ entry.
• To determine the remaining context to be used as the security context, read the
./contexts/users/[seuser_id] file. If this file is not present, then:
• Check for a default context in the
./contexts/default_contexts file. If no default context is
found, then:
• Read the ./contexts/failsafe_context file to allow
a fail safe context to be set.
Note: The system_u user is defined in this file, however there must be no
system_u GNU / Linux user configured on the system.
The format of the seusers file is the same as the files described in the
./modules/active/seusers.final and seusers section, where an
example semanage user command is also shown.

Example seusers file contents:

# ./seusers file for non-MCS/MLS systems.

system_u:system_u
root:root
fred:user_u
__default__:user_u

# ./seusers file for an MLS system. Note that the system_u user
# has access to all security levels and therefore should not be
# configured as a valid GNU / Linux user.

system_u:system_u:s0-s15:c0.c255
root:root:s0-s15:c0.c255
fred:user_u:s0
__default__:user_u:s0

Supporting libselinux API functions are:

getseuser
getseuserbyname

3.4.2 booleans and booleans.local File
Generally these booleans(5) files are not present if semanage(8) is being used
to manage booleans (see the modules/active/booleans.local File section). However if
semanage is not being used or there is an SELinux-aware application that uses the

Page 148
The SELinux Notebook

libselinux functions listed below, then these files may be present (they could also
be present in older Reference policies):
security_set_boolean_list(3) - Writes a boolean.local file if
flag permanent = '1'.
security_load_booleans(3) - Will look for a booleans or
booleans.local file here unless a specific path is specified.
Both files have the same format and contain one or more boolean names. The format
is:
boolean_name value

Where:
boolean_name The name of the boolean.
value The default setting for the boolean that can be
one of the following:
true | false | 1 | 0

Note that if SETLOCALDEFS is set in the SELinux config file, then
selinux_mkload_policy(3) will check for a booleans.local file in the
selinux_booleans_path(3), and also a local.users file in the
selinux_users_path(3).

3.4.3 booleans.subs_dist File
The booleans.subs_dist file (if present) will allow new boolean names to be
allocated to those in the active policy. This file was added because many older
booleans began with 'allow' that made it difficult to determine what they did. For
example the boolean allow_console_login becomes more descriptive as
login_console_enabled. If the booleans.subs_dist file is present, then
either name maybe used. selinux_booleans_subs_path(3) will return the
active policy path to this file and selinux_boolean_sub(3) will will return the
translated name.
Each line within the substitution file booleans.subs_dist is:

policy_bool_name new_name

Where:
policy_bool_name
The policy boolean name.
new_name
The new boolean name.
Example:
# ./booleans.subs_dist

Page 149
The SELinux Notebook

# policy_bool_name new_name
allow_auditadm_exec_content auditadm_exec_content
allow_console_login login_console_enabled
allow_cvs_read_shadow cvs_read_shadow
allow_daemons_dump_core daemons_dump_core

When security_get_boolean_names(3) or
security_set_boolean(3) is called with a boolean name and the
booleans.subs_dist file is present, the name will be looked up and if using the
new_name, then the policy_bool_name will be used (as that is what is defined
in the active policy).

Supporting libselinux API functions are:

selinux_booleans_subs_path
selinux_booleans_sub
security_get_boolean_names
security_set_boolean

3.4.4 setrans.conf File
The setrans.conf(8) file is used by the mcstransd(8) daemon (available in
the mcstrans rpm). The daemon enables SELinux-aware applications to translate
the MCS / MLS internal policy levels into user friendly labels.
There are a number of sample configuration files within the mcstrans package that
describe the configuration options in detail that are located at
/usr/share/mcstrans/examples.
The daemon will not load unless a valid MCS or MLS policy is active.
The translations can be disabled by added the following line to the file:
disable = 1

This file will also support the display of information in colour. The configuration file
that controls this is called secolor.conf and is described in the secolor.conf
File section.
The file format is described in setrans.conf(8) with the following giving an
overview:
# Syntax

# A domain is a self consistent domain of translation (English, German,
Paragraph Markings ...)
Domain=NAME1

# Within a domain are a number of fixed translations
# format is raw_range=trans_range
s3:c200.c511=Confidential
# repeat as required...

# Within a domain are variable translations that are a Base + ModifierGroup +
ModifierGroup

Page 150
The SELinux Notebook

Base=Sensitivity Levels
# raw_range=name
s1=Unclassified
# Aliases have the same name but a different translation.
# The first one is used to compute translations
s1=U
# inverse bits should appear in the base of any level that uses inverse bits
s2:c200.c511=Restricted
# repeat as required...

# Modifier Groups should be in the order of appearance in the translated range.
ModifierGroup=GROUP1
# Allowed white space can be defined
Whitespace=- ,/
# Join defines the character between multiple members of this group
Join=/
# A Prefix can be defined per group
Prefix=Releasable to
# Inverse categories (releasabilities) should always be set as Default
categories in every ModifierGroup
Default=c200.c511
# format is raw_categories=name
# ~ turns off inverse bits
~c200.c511=EVERYBODY

# Aruba - bit 201
~c200,~c201=ABW
~c200,~c201=AA
# Afghanistan - bit 202
~c200,~c202=AFG
~c200,~c202=AF
# repeat as required...

# Another Modifier Group
ModifierGroup=GROUP2
# With different white space
Whitespace=
# And different Join
Join=,
# A Suffix can be defined per group
Suffix=Eyes only
# Default categories need to be consistent
Default=c200.c511

# New domain
Domain=NAME2

# any text can be put in a separate file
Include=PATH
Include=PATH

Example file contents:
# ./setrans.conf
#
# Multi-Level Security translation table for SELinux
#
# Uncomment the following to disable translation library
# disable=1
#
# SystemLow and SystemHigh
s0=SystemLow
s15:c0.c1023=SystemHigh
s0-s15:c0.c1023=SystemLow-SystemHigh

# Unclassified level
s1=Unclassified

Page 151
The SELinux Notebook

# Secret level with compartments
s2=Secret
s2:c0=A
s2:c1=B

# ranges for Unclassified
s0-s1=SystemLow-Unclassified
s1-s2=Unclassified-Secret
s1-s15:c0.c1023=Unclassified-SystemHigh

# ranges for Secret with compartments
s0-s2=SystemLow-Secret
s2:c1-s15:c0.c1023=Secret:B-SystemHigh
s2:c0,c1-s15:c0.c1023=Secret:AB-SystemHigh

Supporting libselinux API functions are:

selinux_translations_path
selinux_raw_to_trans_context
selinux_trans_to_raw_context

3.4.5 secolor.conf File
The secolor.conf(5) file controls the colour to be associated to the components
of a context when information is displayed by an SELinux colour-aware application
(currently none, although there are two examples in the Notebook source tarball under
the libselinux/examples directory). The file format is as follows:

color color_name = #color_mask

context_component string fg_color_name bg_color_name

Where:
color The color keyword.
color_name A descriptive name for the colour (e.g. red).
color_mask A colour mask starting with a hash (#) that
describes the RGB colours with black being
#000000 and white being #ffffff.
context_component The colour translation supports different colours on
the context string components (user, role, type
and range). Each component is on a separate line.
string This is the context_component string that will
be matched with the raw context component
passed by
selinux_raw_context_to_color(3)
A wildcard '*' may be used to match any undefined
string for the user, role and type
context_component entries only

Page 152
The SELinux Notebook

A wildcard '*' may be used to match any undefined
string for the user, role and type
context_component entries only.
fg_color_name The color_name string that will be used as the
foreground colour.
A color_mask may also be used.
bg_color_name The color_name string that will be used as the
background colour.
A color_mask may also be used.

Example file contents:
color black = #000000
color green = #008000
color yellow = #ffff00
color blue = #0000ff
color white = #ffffff
color red = #ff0000
color orange = #ffa500
color tan = #D2B48C

user * = black white
role * = white black
type * = tan orange
range s0-s0:c0.c1023 = black green
range s1-s1:c0.c1023 = white green
range s3-s3:c0.c1023 = black tan
range s5-s5:c0.c1023 = white blue
range s7-s7:c0.c1023 = black red
range s9-s9:c0.c1023 = black orange
range s15:c0.c1023 = black yellow

Supporting libselinux API functions are:

selinux_colors_path
selinux_raw_context_to_color - this call returns the foreground
and background colours of the context string as the specified
RGB 'color' hex digits as follows:
user : role : type : range
#000000 #ffffff #ffffff #000000 #d2b48c #ffa500 #000000 #008000
black white white black tan orange black green

3.4.6 policy/policy.<ver> File
This is the binary policy file that is loaded into the kernel to enforce policy and is
built by either checkpolicy or semodule. Life is too short to describe the format
but the libsepol source could be used as a reference or for an overview the
"SELinux Policy Module Primer" [3] notes.

Page 153
The SELinux Notebook

By convention the file name extension is the policy database version used to build the
policy, however is is not mandatory as the true version is built into the policy file. The
different policy versions are discussed in the Policy Versions section.

3.4.7 contexts/customizable_types File
The customizable_types(5) file contains a list of types that will not be
relabeled by the setfiles(8) or restorecon(8) commands. The commands
check this file before relabeling and excludes those in the list unless the -F flag is
used (see the man pages).

The file format is as follows:
type

Where:
type The type defined in the policy that needs to excluded from
relabeling. An example is when a file has been purposely
relabeled with a different type to allow an application to
work.

Example file contents:
# ./contexts/customizable_types

mount_loopback_t
public_content_rw_t
public_content_t
swapfile_t
sysadm_untrusted_content_t
sysadm_untrusted_content_tmp_t

Supporting libselinux API functions are:

is_context_customizable
selinux_customizable_types_path
selinux_context_path

3.4.8 contexts/default_contexts File
The default_contexts(5) file is used by SELinux-aware applications that need
to set a security context for user processes (generally the login applications) where:
1. The GNU / Linux user identity should be known by the application.
2. If a login application, then the SELinux user (seuser), would have been
determined as described in the seusers file section.
3. The login applications will check the ./contexts/users/
[seuser_id] file first and if no valid entry, will then look in the
[seuser_id] file for a default context to use.

Page 154
The SELinux Notebook

The file format is as follows:
role:type[:range] role:type[:range] ...

Where:
role:type[:range] The file contains one or more lines that consist of
role:type[:range] pairs (including the MLS /
MCS level or range if applicable).
The entry at the start of a new line corresponds to
the partial role:type[:range] context of
(generally) the login application.
The other role:type[:range] entries on that
line represent an ordered list of valid contexts that
may be used to set the users context.

Example file contents:
# ./contexts/default_contexts

system_r:crond_t:s0 system_r:system_crond_t:s0
system_r:local_login_t:s0 user_r:user_t:s0
system_r:remote_login_t:s0 user_r:user_t:s0
system_r:sshd_t:s0 user_r:user_t:s0
system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0
system_r:xdm_t:s0 user_r:user_t:s0

Supporting libselinux API functions are:

# Note that the ./contexts/users/[seuser_id] file is also read
# by some of these functions.

selinux_contexts_path
selinux_default_context_path
get_default_context
get_ordered_context_list
get_ordered_context_list_with_level
get_default_context_with_level
get_default_context_with_role
get_default_context_with_rolelevel
query_user_context
manual_user_enter_context

An example use in this Notebook (to get over a small feature) is that when the initial
basic policy was built, no default_contexts file entries were required as only
one role:type of unconfined_r:unconfined_t had been defined,
therefore the login process did not need to decide anything (as the only user context
was unconfined_u:unconfined_r:unconfined_t).
However when adding the loadable module that used another type
(ext_gateway_t) but with the same role and user (e.g.
unconfined_u:unconfined_r:ext_gateway_t), then it was found that the
login process would always set the logged in user context to

Page 155
The SELinux Notebook

unconfined_u:unconfined_r:ext_gateway_t (i.e. the login application
now had a choice and choose the wrong one, probably because the types are sorted
and 'e' comes before 'u').
The end result was that as soon as enforcing mode was set, the system got bitter and
twisted. To resolve this the default_contexts file entries were set to:

unconfined_r:unconfined_t unconfined_r:unconfined_t

The login process could now set the context correctly to
unconfined_r:unconfined_t. Note that adding the same entry to the
contexts/users/unconfined_u configuration file instead could also have
achieved this.

3.4.9 contexts/dbus_contexts File
This file is for the dbus messaging service daemon (a form of IPC) that is used by a
number of GNU / Linux applications such as GNOME and KDE desktops. If
SELinux is enabled, then this file needs to exist in order for these applications to
work. The dbus-daemon(1) man page details the contents and the Free Desktop
web site has detailed information at:
http://dbus.freedesktop.org

Example file contents:
# ./contexts/dbus_contexts

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus
Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/
1.0/busconfig.dtd">
<busconfig>
<selinux>
</selinux>
</busconfig>

Supporting libselinux API function is:

selinux_context_path

3.4.10 contexts/default_type File
The default_type(5) file allows SELinux-aware applications such as
newrole(1) to select a default type for a role if one is not supplied.

The file format is as follows:
role:type

Where:

Page 156
The SELinux Notebook

role:type The file contains one or more lines that consist of
role:type entries. There should be one line for each role
defined within the policy.

Example file contents:
# ./contexts/default_type

auditadm_r:auditadm_t
secadm_r:secadm_t
sysadm_r:sysadm_t
staff_r:staff_t
unconfined_r:unconfined_t
user_r:user_t

Supporting libselinux API functions are:

selinux_default_type_path
get_default_type

3.4.11 contexts/failsafe_context File
The failsafe_context(5) is used when a login process cannot determine a
default context to use. The file contents will then be used to allow an administrator
access to the system.

The file format is as follows:
role:type[:range]

Where:
role:type[:range] A single line that has a valid context to allow an
administrator access to the system, including the
MLS / MCS level or range if applicable.

Example file contents:
# ./contexts/failsafe_context - Taken from the targeted policy.

unconfined_r:unconfined_t

# ./contexts/failsafe_context - Taken from the MLS policy.

sysadm_r:sysadm_t:s0

Supporting libselinux API functions are:

selinux_context_path
selinux_failsafe_context_path
get_default_context
get_default_context_with_role

Page 157
The SELinux Notebook

get_default_context_with_level
get_default_context_with_rolelevel
get_ordered_context_list
get_ordered_context_list_with_level

3.4.12 contexts/initrc_context File
This is used by the run_init(8) command to allow system services to be started
in the same security context as init. This file could also be used by other SELinux-
aware applications for the same purpose.

The file format is as follows:
user:role:type[:range]

Where:
user:role:type[:range] The file contains one line that consists of a
security context, including the MLS / MCS
level or range if applicable.

Example file contents:
# ./contexts/initrc_context - Taken from the targeted policy.

system_u:system_r:initrc_t:s0

# ./contexts/initrc_context - Taken from the MLS policy
# Note that the init process has full access via the
# range s0-s15:c0.c255.

system_u:system_r:initrc_t:s0-s15:c0.c255

Supporting libselinux API functions are:

selinux_context_path

3.4.13 contexts/lxc_contexts File
This file supports labeling lxc containers within the libvirt library (see libvirt
source src/security/security_selinux.c). This is similar to the
virtual_domain_context and virtual_image_context used by libvirt
qemu services.

The file format is as follows:
process = "security_context"
file = "security_context"
content = "security_context"

Where:

Page 158
The SELinux Notebook

process A single process entry that contains the
lxc domain security context, including the
MLS / MCS level or range if applicable.
file A single file entry that contains the lxc file
security context, including the MLS / MCS
level or range if applicable.
content A single content entry that contains the
lxc content security context, including the
MLS / MCS level or range if applicable.
sandbox_kvm_process These entries may be present, however in F-
sandbox_lxc_process 20 they are not currently used.

Example file contents:
# ./contexts/lxc_contexts

process = "system_u:system_r:svirt_lxc_net_t:s0"
file = "system_u:object_r:svirt_sandbox_file_t:s0"
content = "system_u:object_r:virt_var_lib_t:s0"

Supporting libselinux API functions are:

selinux_context_path
selinux_lxc_context_path

3.4.14 contexts/netfilter_contexts File
This file will support the Secmark labeling for Netfilter / iptable rule matching of
network packets, however it is currently unused (see the
./modules/active/netfilter_contexts & netfilter.local file
section for further information).

Supporting libselinux API functions are:

selinux_context_path
selinux_netfilter_context_path

3.4.15 contexts/removable_context File
The removable_context(5) file contains a single default label that should be
used for removable devices that are not defined in the contexts/files/media
file.

The file format is as follows:
user:role:type[:range]

Page 159
The SELinux Notebook

Where:
user:role:type[:range] The file contains one line that consists of a
security context, including the MLS / MCS
level or range if applicable.

Example file contents:
# ./contexts/removable_contexts

system_u:object_r:removable_t:s0

Supporting libselinux API functions are:

selinux_removable_context_path

3.4.16 contexts/securetty_types File
The securetty_types(5) file is used by the newrole(1) command to find
the type to use with tty devices when changing roles or levels.

The file format is as follows:
type

Where:
type Zero or more type entries that are defined in the policy for
tty devices.

Example file contents:
# ./contexts/securetty_types

sysadm_tty_device_t
user_tty_device_t
staff_tty_device_t

Supporting libselinux API functions are:

selinux_securetty_types_path

3.4.17 contexts/sepgsql_contexts File
This file contains the default security contexts for SE-PostgreSQL database objects
and is descibed in selabel_db(5).

The file format is as follows:
Each line within the database contexts file is as follows:

Page 160
The SELinux Notebook

object_type object_name context

Where:
object_type This is the string representation of the object type.

object_name These are the object names of the specific database objects.
The entry can contain '*' for wildcard matching or '?' for
substitution. Note that if the '*' is used, then be aware that
the order of entries in the file is important. The '*' on its own
is used to ensure a default fallback context is assigned and
should be the last entry in the object_type block.

context The security context that will be applied to the object.

Example file contents:
# ./contexts/sepgsql_contexts file

# object_type object_name context
db_database my_database system_u:object_r:my_sepgsql_db_t:s0
db_database * system_u:object_r:sepgsql_db_t:s0
db_schema *.* system_u:object_r:sepgsql_schema_t:s0

3.4.18 contexts/systemd_contexts File
This file is not currently used in F-20 but seems to contain file contexts to be used by
tasks run via systemd(8) in a later release. There are some patches in the
systemd mail archive that relate to this file.

The file format is as follows:
service_class = security_context

Where:
service_class One or more entries that relate to the systemd
service (e.g. runtime, transient).
security_context The security context, including the MLS / MCS
level or range if applicable of the service to be
run.

Example file contents:
# ./contexts/systemd_contexts

runtime=system_u:object_r:systemd_runtime_unit_file_t:s0

Page 161
The SELinux Notebook

Supporting libselinux API functions are:

selinux_context_path
selinux_systemd_contexts_path

3.4.19 contexts/userhelper_context File
This file contains the default security context used by the system-config-*
applications when running from root.

The file format is as follows:
security_context

Where:
security_context The file contains one line that consists of a full
security context, including the MLS / MCS level or
range if applicable.

Example file contents:
# ./contexts/userhelper_context - Taken from the standard
# reference policy.

system_u:sysadm_r:sysadm_t

# ./contexts/userhelper_context - Taken from the MLS/MCS
# reference policy.

system_u:sysadm_r:sysadm_t:s0

Supporting libselinux API functions are:

selinux_context_path

3.4.20 contexts/virtual_domain_context File
The virtual_domain_context(5) file is used by the virtulization API
(libvirt) and provides the qemu domain contexts available in the policy (see
libvirt source src/security/security_selinux.c). There may be two
entries in this file, with the second entry being an alternative domain context.

Example file contents:
# ./contexts/virtual_domain_context - From targeted policy.

system_u:system_r:svirt_t:s0

Supporting libselinux API functions are:

Page 162
The SELinux Notebook

selinux_virtual_domain_context_path

3.4.21 contexts/virtual_image_context File
The virtual_image_context(5) file is used by the virtulization API
(libvirt) and provides the image contexts that are available in the policy (see
libvirt source src/security/security_selinux.c). The first entry is the
image file context and the second entry is the image content context.

Example file contents:
# ./contexts/virtual_image_context - From targeted policy.

system_u:system_r:svirt_image_t:s0
system_u:system_r:svirtcontent_t:s0

Supporting libselinux API functions are:

selinux_virtual_image_context_path

3.4.22 contexts/x_contexts File
The x_contexts(5) file provides the default security contexts for the X-Windows
SELinux security extension. The usage is discussed in the X-windows SELinux
Support section. The MCS / MLS version of the file has the appropriate level or
range information added.
A typical entry is as follows:
# object_type object_name context
selection PRIMARY system_u:object_r:clipboard_xselection_t

Where:
object_type These are types of object supported and valid entries are:
client, property, poly_property, extension,
selection, poly_selection and events.

object_name These are the object names of the specific X-server resource
such as PRIMARY, CUT_BUFFER0 etc. They are generally
defined in the X-server source code (protocol.txt and
BuiltInAtoms in the dix directory of the xorg-
server source package).
This can contain '*' for 'any' or '?' for 'substitute' (see the
CUT_BUFFER? entry where the '?' would be substituted for
a number between 0 and 7 that represents the number of
these buffers).

Page 163
The SELinux Notebook

context This is the security context that will be applied to the object.
For MLS/MCS systems there would be the additional MLS
label.

Example file contents:
#
# Config file for XSELinux extension
#

### Rules for X Clients
# The default client rule defines a context to be used for all clients
# connecting to the server from a remote host.
#
client * system_u:object_r:remote_t

#
### Rules for X Properties
# Property rules map a property name to a context. A default property
# rule indicated by an asterisk should follow all other property rules.
#
# Properties that normal clients may only read
property _SELINUX_* system_u:object_r:seclabel_xproperty_t

# Clipboard and selection properties
property CUT_BUFFER? system_u:object_r:clipboard_xproperty_t

# Default fallback type
property * system_u:object_r:xproperty_t

#
### Rules for X Extensions
# Extension rules map an extension name to a context. A default extension
# rule indicated by an asterisk should follow all other extension rules.
#
# Restricted extensions
extension SELinux system_u:object_r:security_xextension_t

# Standard extensions
extension * system_u:object_r:xextension_t

#
### Rules for X Selections
# Selection rules map a selection name to a context. A default selection
# rule indicated by an asterisk should follow all other selection rules.
#
# Standard selections
selection PRIMARY system_u:object_r:clipboard_xselection_t
selection CLIPBOARD system_u:object_r:clipboard_xselection_t

# Default fallback type
selection * system_u:object_r:xselection_t

#
### Rules for X Events
# Event rules map an event protocol name to a context. A default event
# rule indicated by an asterisk should follow all other event rules.
#
# Input events
event X11:KeyPress system_u:object_r:input_xevent_t
event X11:KeyRelease system_u:object_r:input_xevent_t
event X11:ButtonPress system_u:object_r:input_xevent_t
event X11:ButtonRelease system_u:object_r:input_xevent_t
event X11:MotionNotify system_u:object_r:input_xevent_t
event XInputExtension:DeviceKeyPress system_u:object_r:input_xevent_t
event XInputExtension:DeviceKeyRelease system_u:object_r:input_xevent_t
event XInputExtension:DeviceButtonPress system_u:object_r:input_xevent_t
event XInputExtension:DeviceButtonRelease system_u:object_r:input_xevent_t
event XInputExtension:DeviceMotionNotify system_u:object_r:input_xevent_t
event XInputExtension:DeviceValuator system_u:object_r:input_xevent_t
event XInputExtension:ProximityIn system_u:object_r:input_xevent_t
event XInputExtension:ProximityOut system_u:object_r:input_xevent_t

Page 164
The SELinux Notebook

# Client message events
event X11:ClientMessage system_u:object_r:client_xevent_t
event X11:SelectionNotify system_u:object_r:client_xevent_t
event X11:UnmapNotify system_u:object_r:client_xevent_t
event X11:ConfigureNotify system_u:object_r:client_xevent_t

# Default fallback type
event * system_u:object_r:xevent_t

Supporting libselinux API functions are:

selinux_x_context_path
selabel_open
selabel_close
selabel_lookup
selabel_stats

3.4.23 contexts/files/file_contexts File
The file_contexts(5) file is managed by the semodule(8) and
semanage(8) commands39 as the policy is updated (adding or removing modules or
updating the base), and therefore should not be edited.
The file is used by a number of SELinux-aware commands (setfiles(8),
fixfiles(8), matchpathcon(8), restorecon(8)) to relabel either part or
all of the file system.
Note that users home directory file contexts are not present in this file as they are
managed by the file_contexts.homedirs file as explained below.
The format of the file_contexts file is the same as the files described in the
./modules/active/file_contexts file section.
There may also be a file_contexts.bin present that is built and used by
semanage(8). The format of this file conforms to the Perl compatible regular
expression (PCRE) internal format.

Supporting libselinux API functions are:

selinux_file_context_path
selabel_open
selabel_close
selabel_lookup
selabel_stats

3.4.24 contexts/files/file_contexts.local File
This file is added by the semanage fcontext command as described in the
./modules/active/file_contexts.local file section to allow locally

39
As each module would have its own file_contexts component that is either added or
removed from the policies overall /etc/selinux/<policy_name>/contexts/
files/file_contexts file.

Page 165
The SELinux Notebook

defined files to be labeled correctly. The file_contexts(5) man page also
decribes this file.

Supporting libselinux API functions are:

selinux_file_context_local_path

3.4.25 contexts/files/file_contexts.homedirs File
This file is managed by the semodule(8) and semanage(8) commands as the
policy is updated (adding or removing users and modules or updating the base), and
therefore should not be edited.
It is generated by the genhomedircon(8) command (in fact by semodule -Bn
that rebuilds the policy) and used to set the correct contexts on the users home
directory and files.
It is fully described in the ./modules/active/file_contexts.homedirs
file section. The file_contexts(5) man page also decribes this file.
There may also be a file_contexts.homedirs.bin present that is built and
used by semanage(8). The format of this file conforms to the Perl compatible
regular expression (PCRE) internal format.

Supporting libselinux API functions are:

selinux_file_context_homedir_path
selinux_homedir_context_path

3.4.26 contexts/files/file_contexts.subs and
file_contexts.subs_dist File
These files allow substitution of file names (.subs for local use and .subs_dist
for GNU / Linux distributions use) for the libselinux functions
matchpatchcon(3) and selabel_lookup(3). The file_contexts(5)
man page also decribes this file.
The subs files contain a list of space separated path names such as:
/myweb /var/www
/myspool /var/spool/mail

Then (for example), when matchpatchcon(3) or selabel_lookup(3) is
passed a path /myweb/index.html the functions will substitute the /myweb
component with /var/www, with the final result being:

/var/www/index.html

Supporting libselinux API functions are:

selinux_file_context_subs_path

Page 166
The SELinux Notebook

selinux_file_context_subs_dist_path
selabel_lookup
matchpathcon
matchpathcon_index

3.4.27 contexts/files/media File
The media(5) file is used to map media types to a file context. If the media_id
cannot be found in this file, then the default context in the
./contexts/removable_contexts is used instead.

The file format is as follows:
media_id file_context

Where:
media_id The media identifier (those known are: cdrom,
floppy, disk and usb).
file_context The context to be used for the device. Note that it does
not have the MLS / MCS level).

Example file contents:
# contexts/files/media
# Note the same file is generated for all types of policy.

cdrom system_u:object_r:removable_device_t
floppy system_u:object_r:removable_device_t
disk system_u:object_r:fixed_disk_device_t

Supporting libselinux API functions are:

selinux_media_context_path

3.4.28 contexts/users/[seuser_id] File
These optional files are named after the SELinux user they represent. Each file has the
same format as the contexts/default_contexts file and is used to assign the
correct context to the SELinux user (generally during login). The
user_contexts(5) man page also decribes these entries.

Example file contents:
# ./contexts/users/unconfined_u - From the targeted policy.

system_r:crond_t:s0 unconfined_r:unconfined_t:s0
system_r:initrc_t:s0 unconfined_r:unconfined_t:s0
system_r:local_login_t:s0 unconfined_r:unconfined_t:s0

Page 167
The SELinux Notebook

system_r:remote_login_t:s0 unconfined_r:unconfined_t:s0
system_r:sshd_t:s0 unconfined_r:unconfined_t:s0
system_r:sysadm_su_t:s0 unconfined_r:unconfined_t:s0
system_r:unconfined_t:s0 unconfined_r:unconfined_t:s0
system_r:initrc_su_t:s0 unconfined_r:unconfined_t:s0
unconfined_r:unconfined_t:s0 unconfined_r:unconfined_t:s0
system_r:xdm_t:s0 unconfined_r:unconfined_t:s0

Supporting libselinux API functions are:

selinux_user_contexts_path
selinux_users_path
selinux_usersconf_path
get_default_context
get_default_context_with_role
get_default_context_with_level
get_default_context_with_rolelevel
get_ordered_context_list
get_ordered_context_list_with_level

3.4.29 logins/<linuxuser_id> File
These optional files are used by SELinux-aware login applications such as PAM
(using the pam_selinux module) to obtain an SELinux user name and level based
on the GNU / Linux login id and service name. It has been implemented for SELinux-
aware applications such as FreeIPA (Identity, Policy Audit - see
http://freeipa.org/page/Main_Page for details). The service_seusers(5) man
page also decribes these entries.
The file name is based on the GNU/Linux user that is used at log in time (e.g. ipa).
If getseuser(3) fails to find an entry, then the seusers file is used to retrieve
default information.

The file format is as follows:
service_name:seuser_id:level

Where:
service_name The name of the service.
seuser_id The SELinux user name.
level The run level

Example file contents:
# ./logins/ipa example entries

ipa_service:user_u:s0
another_service:unconfined_u:s0

Page 168
The SELinux Notebook

Supporting libselinux API functions are:

getseuser

3.4.30 users/local.users File
Generally the local.users(5) file is not present if semanage(8) is being used
to manage users, however if semanage is not being used then this file may be
present (it could also be present in older Reference or Example policies).
The file would contain local user definitions in the form of user statements as
defined in the modules/active/users.local section.
Note that if SETLOCALDEFS is set in the SELinux config file, then
selinux_mkload_policy(3) will check for a local.users file in the
selinux_users_path(3), and a booleans.local file in the
selinux_booleans_path(3).

Page 169
The SELinux Notebook

4. SELinux Policy Languages

4.1 Introduction
This section is intended as a reference to give a basic understanding of the kernel
policy language statements and rules with supporting examples taken from the
Reference Policy sources. Also all of the language updates to Policy DB version 29
should have been captured. For a more detailed explanation of the policy language the
"SELinux by Example" [12] book is recommended.
There is currently a project underway called the Common Intermediate Language
(CIL) project that defines a new policy definition language that has an overview of its
motivation and design at: https://github.com/SELinuxProject/cil/wiki, however some
of the language statement definitions out of date. The CIL compiler source and
language reference guide can be found at: https://github.com/SELinuxProject/cil.git
and cloned via:
git clone https://github.com/SELinuxProject/cil.git

The CIL compiler language reference guide has examples for each type of statement
and can be built in pdf or html formats, therefore this Notebook will not cover the CIL
policy language (there is a pdf copy of the CIL Reference Guide in the Notebook
tarball). There is a migration programme underway that will convert the Reference
Policy to CIL via a high level language module that is discussed in the Policy Store
Migration section. Once migration is complete, the CIL compiler will be in available
the libsepol library and CIL modules will be compiled with an updated
semodule(8) command as follows:
# Compile and install an updated module written in CIL:
semodule -s modular-test --priority 400 -i custom/int_gateway.cil

Note that any source policy file name with the '.cil' extension will automatically be
built as a CIL module.

4.1.1 CIL Overview
While the CIL design web pages give the main objectives of CIL, from a language
perspective it will:
a) Apply name and usage consistancy to the current kernel language statements.
For example the kernel language uses attribute and attribute_role
to declare identifiers, whereas CIL uses typeattribute and
roleattribute. Also statements to associate types or roles have been
made consistant and enhanced to allow expressions to be defined.
Examples:
Kernel CIL
attribute typeattribute
typeattribute typeattributeset
attribute_role roleattribute

Page 170
The SELinux Notebook

roleattribute roleattributeset
allow allow
allow (role) roleallow
dominance sensitivityorder

b) Additional CIL statements have been defined to enhance functionality:
classpermission - Declare a classpermissionset identifier.
classpermissionset - Associate class / permissions also supporting
expressions.
classmap / classmapping - Statements to support declaration and
association of multiple classpermissionset's. Useful when defining
an allow rule with multiple class/permissions.
context - Statement to declare security context.
c) Allow named and anonymous definitions to be supported.
d) Support namespace features allowing policy modules to be defined within
blocks with inheritance and template features.
e) Remove the order dependancy in that policy statements can be anywhere
within the source (i.e. remove dependancy of class, sid etc. being within a base
module).
f) Able to define macros and calls that will remove any dependancy on M4
macro support.
g) Directly generate the binary policy file and other configuration files - currently
the file_contexts file.
h) Support transformation services such as delete, transform and inherit with
exceptions.
An simple CIL policy is as follows:
; These CIL statements declare a user, role, type and range of:
; unconfined.user:unconfined.role:unconfined.process:s0-s0
;
; A CIL policy requires at least one 'allow' rule and sid to be declared
; before a policy will build.
;

(handleunknown allow)
(mls true)
(policycap open_perms)

(category c0)
(categoryorder (c0))
(sensitivity s0)
(sensitivityorder (s0))
(sensitivitycategory s0 (c0))
(level systemLow (s0))
(levelrange low_low (systemLow systemLow))

(sid kernel)
(sidorder (kernel))
(sidcontext kernel unconfined.sid_context)

(classorder (file))
(class file (read write open getattr))

Page 171
The SELinux Notebook

; Define object_r role. This must be assigned in CIL.
(role object_r)

; The unconfined namespace:
(block unconfined
(user user)
(userrange user (systemLow systemLow))
(userlevel user systemLow)
(userrole user role)

(role role)

(type process)
(roletype object_r process)
(roletype role process)
; Define a SID context:
(context sid_context (user role process low_low))

(type object)
(roletype object_r object)

; An allow rule:
(allow process object (file (read)))
)

There are CIL examples in the Notebook source tarball with a utility that will produce
a base policy in either the kernel policy language or CIL (notebook-
tools/build-sepolicy). The only requirement is that the initial_sids,
security_classes and access_vectors files from the Reference policy are
required, although the F-20 versions are supplied in the basic-policy/policy-
files/flask-files directory.
Usage: build-sepolicy [-k] [-M] [-c|-i|-p|-s] -d flask_directory -o output_file

-k Output kernel classes only (exclude # userspace entries in the
security_classes file).
-M Output an MLS policy.
-c Output a policy in CIL language (otherwise gererate a kernel policy
language policy).
-p Output a file containing class and classpermissionsets + their order
for use by CIL policies.
-s Output a file containing initial SIDs + their order for use by
CIL policies.
-i Output a header file containing class/permissions for use by
selinux_set_mapping(3).
-o The output file that will contain the policy source or header file.
-d Directory containing the initial_sids, security_classes and
access_vectors Flask files.

4.2 Kernel Policy Language

4.2.1 Policy Source Files
There are three basic types of policy source file 40 that can contain language statements
and rules. The three types of policy source file41 are:

40
It is important to note that the Reference Policy builds policy using makefiles and m4 support
macros within its own source file structure. However, the end result of the make process is that
there can be three possible types of source file built (depending on the MONOLITHIC=Y/N build
option). These files contain the policy language statements and rules that are finally complied into
a binary policy.

Page 172
The SELinux Notebook

Monolithic Policy - This is a single policy source file that contains all statements.
By convention this file is called policy.conf and is compiled using the
checkpolicy(8) command that produces the binary policy file.
Base Policy - This is the mandatory base policy source file that supports the
loadable module infrastructure. The whole system policy could be fully contained
within this file, however it is more usual for the base policy to hold the mandatory
components of a policy, with the optional components contained in loadable
module source files. By convention this file is called base.conf and is
compiled using the checkpolicy(8) or checkmodule(8) command.
Module (or Non-base) Policy - These are optional policy source files that when
compiled, can be dynamically loaded or unloaded within the policy store. By
convention these files are named after the module or application they represent,
with the compiled binary having a '.pp' extension. These files are compiled using
the checkmodule command.
Table 14 shows the order in which the statements should appear in source files with
the mandatory statements that must be present.

41
This does not include the 'file_contexts' file as it does not contain policy statements, only
default security contexts (labels) that will be used to label files and directories.

Page 173
The SELinux Notebook

Base Entries M/O Module Entries M/O
Security Classes (class) m module Statement o
Initial SIDs m
Access Vectors m require Statement o
(permissions)
MLS sensitivity, category o
and level Statements
MLS Constraints o
Policy Capability o
Statements
Attributes o Attributes o
Booleans o Booleans o
Default user, role, type, o
range rules
Type / Type Alias m Type / Type Alias o
Roles m Roles o
Policy Rules m Policy Rules o
Users m Users o
Constraints o
Default SID labeling m
fs_use_xattr o
Statements
fs_use_task and o
fs_use_trans
Statements
genfscon Statements o
portcon, netifcon and o
nodecon Statements

Table 14: Base and Module Policy Statements - There must be at least one of each
of the mandatory statements, plus at least one allow rule in a policy to successfully
build.
The language grammar defines what statements and rules can be used within the
different types of source file. To highlight these rules, the following table is included
in each statement and rule section to show what circumstances each one is valid
within a policy source file:
Monolithic Policy Base Policy Module Policy
Yes/No Yes/No Yes/No

Where:
Monolithic Policy Whether the statement is allowed within a monolithic
policy source file or not.
Base Policy Whether the statement is allowed within a base (for
loadable module support) policy source file or not.
Module Policy Whether the statement is allowed within the optional
loadable module policy source file or not.

Page 174
The SELinux Notebook

Table 16 shows a cross reference matrix of statements and rules allowed in each type
of policy source file.

4.2.2 Conditional, Optional and Require Statement Rules
The language grammar specifies what statements and rules can be included within
Conditional Policy, Optional Policy statements and the require statement. To
highlight these rules the following table is included in each statement and rule section
to show what circumstances each one is valid within a policy source file:
Conditional Policy (if) Statement optional Statement require Statement
Yes/No Yes/No Yes/No

Where:
Conditional Policy Whether the statement is allowed within a conditional
(if) Statement statement (IF / ELSE construct) as described in the
if Statement section. Conditional statements can be
in all types of policy source file.
optional Statement Whether the statement is allowed within the
optional { rule_list } construct as
described in the optional Statement section.
require Statement Whether the statement keyword is allowed within the
require { rule_list } construct as
described in the require Statement section.

Table 16 shows a cross reference matrix of statements and rules allowed in each of
the above policy statements.

4.2.3 MLS Statements and Optional MLS Components
The MLS Statements section defines statements specifically for MLS support.
However when MLS is enabled, there are other statements that require the MLS
Security Context component as an argument, therefore these statements show an
example taken from the Reference Policy MLS build.

4.2.4 General Statement Information
1. Identifiers can generally be any length but should be restricted to the following
characters: a-z, A-Z, 0-9 and _ (underscore).
2. A '#' indicates the start of a comment in policy source files.
3. All statements available to policy version 29 have been included.
4. When multiple source and target entries are shown in a single statement or rule,
the compiler (checkpolicy(8) or checkmodule(8)) will expand these to
individual statements or rules as shown in the following example:
# This allow rule has two target entries console_device_t and
# tty_device_t:

Page 175
The SELinux Notebook

allow apm_t { console_device_t tty_device_t }:chr_file
{ getattr read write append ioctl lock };

# The compiler will expand this to become:
allow apm_t console_device_t:chr_file { getattr read write
append ioctl lock };
# and:
allow apm_t tty_device_t:chr_file { getattr read write append
ioctl lock };

Therefore when comparing the actual source code with a compiled binary using
(for example) apol(8), sedispol or sedismod, the results will differ
(however the resulting policy rules will be the same).
5. Some statements can be added to a policy via the policy store using the
semanage(8) command. Examples of these are shown where applicable,
however the semanage man page should be consulted for all the possible
command line options.
6. Table 15 lists words reserved for the SELinux policy language.
alias allow and
attribute attribute_role auditallow
auditdeny bool category
cfalse class clone
common constrain ctrue
dom domby dominance
dontaudit else equals
false filename filesystem
fscon fs_use_task fs_use_trans
fs_use_xattr genfscon h1
h2 identifier if
incomp inherits iomemcon
ioportcon ipv4_addr ipv6_addr
l1 l2 level
mlsconstrain mlsvalidatetrans module
netifcon neverallow nodecon
not notequal number
object_r optional or
path pcidevicecon permissive
pirqcon policycap portcon
r1 r2 r3
range range_transition require
role roleattribute roles
role_transition sameuser sensitivity
sid source t1
t2 t3 target

Page 176
The SELinux Notebook

true type typealias
typeattribute typebounds type_change
type_member types type_transition
u1 u2 u3
user validatetrans version_identifier
xor default_user default_role
default_type default_range low
high low_high

Table 15: Policy language reserved words.
7. Table 16 shows what policy language statements and rules are allowed within
each type of policy source file, and whether the statement is valid within an if /
else construct, optional {rule_list}, or require {rule_list}
statement.
Statement / Rule Monolithic Base Module Conditional optional require
Policy Policy Policy Statements Statement Statement42
allow Yes Yes Yes Yes Yes No
allow - Role Yes Yes Yes No Yes No
attribute Yes Yes Yes No Yes Yes
attribute_role Yes Yes Yes No Yes Yes
auditallow Yes Yes Yes Yes Yes No
auditdeny Yes Yes Yes Yes Yes No
(Deprecated)
bool Yes Yes Yes No Yes Yes
category Yes Yes No No No Yes
class Yes Yes No No No Yes
common Yes Yes No No No No
constrain Yes Yes No No No No
default_user Yes Yes No No No No
default_role Yes Yes No No No No
default_type Yes Yes No No No No
default_range Yes Yes No No No No
dominance - MLS Yes Yes No No No No
dominance - Role Yes Yes Yes No Yes No
(Deprecated)
dontaudit Yes Yes Yes Yes Yes No
fs_use_task Yes Yes No No No No
fs_use_trans Yes Yes No No No No
fs_use_xattr Yes Yes No No No No
genfscon Yes Yes No No No No
if Yes Yes Yes No Yes No
level Yes Yes No No No No
mlsconstrain Yes Yes No No No No

42
Only the statement keyword is allowed.

Page 177
The SELinux Notebook

Statement / Rule Monolithic Base Module Conditional optional require
Policy Policy Policy Statements Statement Statement
mlsvalidatetrans Yes Yes No No No No
module No No Yes No No No
netifcon Yes Yes No No No No
neverallow Yes Yes Yes 43
No Yes No
nodecon Yes Yes No No No No
optional No Yes Yes Yes Yes Yes
permissive Yes Yes Yes Yes Yes No
policycap Yes Yes No No No No
portcon Yes Yes No No No No
range_transition Yes Yes Yes No Yes No
require No Yes 44
Yes Yes 45
Yes No
role Yes Yes Yes No Yes Yes
roleattribute Yes Yes Yes No Yes No
role_transition Yes Yes Yes No Yes No
sensitivity Yes Yes No No No Yes
sid Yes Yes No No No No
type Yes Yes Yes No No Yes
type_change Yes Yes Yes Yes Yes No
type_member Yes Yes Yes Yes Yes No
type_transition Yes Yes Yes Yes Yes No
typealias Yes Yes Yes No Yes No
typeattribute Yes Yes Yes No Yes No
typebounds Yes Yes Yes No Yes No
user Yes Yes Yes No Yes Yes
validatetrans Yes Yes No No No No

Table 16: The policy language statements and rules that are allowed within each
type of policy source file - The left hand side of the table shows what Policy
Language Statements and Rules are allowed within each type of policy source file.
The right hand side of the table shows whether the statement is valid within the
if / else construct, optional {rule_list}, or require
{rule_list} statement.

4.2.5 Section Contents
The policy language statement and rule sections are as follows:
a) Policy Configuration Statements
b) Default Object Rules
c) User Statements
43
neverallow statements are allowed in modules, however to detect these the semanage.conf
file must have the expand-check=1 entry present.
44
Only if preceded by the optional statement.
45
Only if preceded by the optional statement.

Page 178
The SELinux Notebook

d) Role Statements
e) Type Statements
f) Bounds Rules
g) Access Vector Rules
h) Object Class and Permission Statements
i) Conditional Policy Statements
j) Constraint Statements
k) MLS Statements
l) Security ID (SID) Statement
m) File System Labeling Statements
n) Network Labeling Statements
o) Modular Policy Support Statements
p) XEN Statements

4.3 Policy Configuration Statements

4.3.1 policycap
Policy version 22 introduced the policycap statement to allow new capabilities to
be enabled or disabled in the kernel via policy in a backward compatible way. For
example policies that are aware of a new capability can enable the functionality, while
older policies would continue to use the original functionality. An example is shown
in the SELinux Networking Support section using the network_peer_controls
capability.
In the 3.14 kernel there are four policy capabilities configured as shown in the
SELinux Filesystem section.

The statement definition is:
policycap capability;

Where:
policycap The policycap keyword.
capability A single capability identifier that will be
enabled for this policy.

The statement is valid in:

Page 179
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# This statement enables the network_peer_controls to be enabled
# for use by the policy.
#
policycap network_peer_controls;

4.4 Default Object Rules
These rules allow a default user, role, type and/or range to be used when computing a
context for a new object. These require policy version 27 or 28 with kernels 3.5 or
greater.

4.4.1 default_user
Allows the default user to be taken from the source or target context when computing
a new context for an object of the defined class. Requires policy version 27.

The statement definition is:
default_user class default;

Where:
default_user The default_user rule keyword.
class One or more class identifiers. Multiple entries
consist of a space separated list enclosed in braces
({}).
Entries can be excluded from the list by using the
negative operator (-).
default A single keyword consisting of either source or
target that will state whether the default user
should be obtained from the source or target
context.

The statement is valid in:

Page 180
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
# When computing the context for a new file object, the user
# will be obtained from the target context.
default_user file target;

# When computing the context for a new x_selection or x_property
# object, the user will be obtained from the source context.
default_user { x_selection x_property } source;

4.4.2 default_role
Allows the default role to be taken from the source or target context when computing
a new context for an object of the defined class. Requires policy version 27.

The statement definition is:
default_role class default;

Where:
default_role The default_role rule keyword.
class One or more class identifiers. Multiple entries
consist of a space separated list enclosed in braces
({}).
Entries can be excluded from the list by using the
negative operator (-).
default A single keyword consisting of either source or
target that will state whether the default role
should be obtained from the source or target
context.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Page 181
The SELinux Notebook

Example:
# When computing the context for a new file object, the role
# will be obtained from the target context.
default_role file target;

# When computing the context for a new x_selection or x_property
# object, the role will be obtained from the source context.
default_role { x_selection x_property } source;

4.4.3 default_type
Allows the default type to be taken from the source or target context when computing
a new context for an object of the defined class. Requires policy version 28.

The statement definition is:
default_type class default;

Where:
default_type The default_type rule keyword.
class One or more class identifiers. Multiple entries
consist of a space separated list enclosed in braces
({}).
Entries can be excluded from the list by using the
negative operator (-).
default A single keyword consisting of either source or
target that will state whether the default type
should be obtained from the source or target
context.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# When computing the context for a new file object, the type
# will be obtained from the target context.
default_type file target;

# When computing the context for a new x_selection or x_property

Page 182
The SELinux Notebook

# object, the type will be obtained from the source context.
default_type { x_selection x_property } source;

4.4.4 default_range
Allows the default range or level to be taken from the source or target context when
computing a new context for an object of the defined class. Requires policy version
27.

The statement definition is:
default_range class default range;

Where:
default_range The default_range rule keyword.
class One or more class identifiers. Multiple entries
consist of a space separated list enclosed in braces
({}).
Entries can be excluded from the list by using the
negative operator (-).
default A single keyword consisting of either source or
target that will state whether the default level or
range should be obtained from the source or target
context.
range A single keyword consisting of either: low, high
or low_high that will state what part of the range
should be used.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# When computing the context for a new file object, the lower
# level will be taken from the target context range.
default_range file target low;

# When computing the context for a new x_selection or x_property
# object, the range will be obtained from the source context.
default_type { x_selection x_property } source low_high;

Page 183
The SELinux Notebook

4.5 User Statements

4.5.1 user
The user statement declares an SELinux user identifier within the policy and
associates it to one or more roles. The statement also allows an optional MLS level
and range to control a users security level. It is also possible to add SELinux user
id's outside the policy using the 'semanage user' command that will associate the
user with roles previously declared within the policy.

The statement definition is:
user seuser_id roles role_id;

Or for MCS/MLS Policy:
user seuser_id roles role_id level mls_level range mls_range;

Where:
user The user keyword.
seuser_id The SELinux user identifier.
roles The roles keyword.
role_id One or more previously declared role or
attribute_role identifiers. Multiple role
identifiers consist of a space separated list enclosed
in braces ({}).
level If MLS is configured, the MLS level keyword.
mls_level The users default MLS security level that has
been previously declared with a level statement.
Note that the compiler only accepts the
sensitivity component of the level (e.g.
s0).
range If MLS is configured, the MLS range keyword.
mls_range The range of security levels that the user can run.
The format is described in the MLS range
Definition section.

The statement is valid in:

Page 184
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes Yes

Example:
# Using the user statement to define an SELinux user user_u that
# has been assigned the role of user_r. The SELinux user_u is a
# generic user identity for Linux users who have no specific
# SELinux user identity defined.
#
user user_u roles { user_r };

MLS Examples:
# Using the user statement to define an MLS SELinux user user_u
# that has been assigned the role of user_r and has a default
# login security level of s0 assigned, and is only allowed
# access to the s0 range of security levels (See the
# MLS Statements section for details):

user user_u roles { user_r } level s0 range s0;

# Using the user statement to define an MLS SELinux user
# sysadm_u that has been assigned the role of sysadm_r and has
# a default login security level of s0 assigned, and is
# allowed access to the range of security levels (low - high)
# between s0 and s15:c0.c255 (See the MLS Statements section
# for details):

user sysadm_u roles { sysadm_r } level s0 range s0-s15:c0.c255;

semanage(8) Command example:

# Add user mque_u to SELinux and associate to the unconfined_r
# role:
semanage user -a -R unconfined_r mque_u

This command will produce the following files in the default <policy_name>
policy store and then activate the policy:
/etc/selinux/<policy_name>/modules/active/users.local:

# This file is auto-generated by libsemanage
# Do not edit directly.

user mque_u roles { unconfined_r } ;

/etc/selinux/<policy_name>/modules/active/users_extra:

# This file is auto-generated by libsemanage

Page 185
The SELinux Notebook

# Do not edit directly.

user mque_u prefix user;

/etc/selinux/<policy_name>/modules/active/users_extra.local:

# This file is auto-generated by libsemanage
# Do not edit directly.

user mque_u prefix user;

4.6 Role Statements
Policy version 26 introduced two new role statements aimed at replacing the role
dominance rule by making role relationships easier to understand. These new
statements: attribute_role and roleattribute are defined in this section
with examples.

4.6.1 role
The role statement either declares a role identifier or associates a role identifier to
one or more types (i.e. authorise the role to access the domain or domains). Where
there are multiple role statements declaring the same role, the compiler will
associate the additional types with the role.

The statement definition to declare a role is:
role role_id;

The statement definition to associate a role to one or more types is:
role role_id types type_id;

Where:
role The role keyword.
role_id The identifier of the role being declared. The same
role identifier can be declared more than once in a
policy, in which case the type_id entries will be
amalgamated by the compiler.
types The optional types keyword.
type_id When used with the types keyword, one or more
type, typealias or attribute identifiers
associated with the role_id. Multiple entries
consist of a space separated list enclosed in braces
({}). Entries can be excluded from the list by using
the negative operator (-).
For role statements, only type, typealias or

Page 186
The SELinux Notebook

attribute identifiers associated to domains have
any meaning within SELinux.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes Yes

Examples:
# Declare the roles:

role system_r;
role sysadm_r;
role staff_r;
role user_r;
role secadm_r;
role auditadm_r;

# Within the policy the roles are then associated to the
# required types with this example showing the user_r role
# being associated to two domains:

role user_r types user_t;
role user_r types chfn_t;

4.6.2 attribute_role
The attribute_role statement declares a role attribute identifier that can then be
used to refer to a group of roles.

The statement definition is:
attribute_role attribute_id;

Where:
attribute_role The attribute_role keyword.
attribute_id The attribute identifier.

The statement is valid in:

Page 187
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes Yes

Examples:
# Using the attribute_role statement to declare attributes that
# can then refers to a list of roles. Note that there are no
# roles associated with them yet.

attribute_role role_list_1;
attribute_role srole_list_2;

4.6.3 roleattribute
The roleattribute statement allows the association of previously declared
roles to one or more previously declared attribute_roles.

The statement definition is:
roleattribute role_id attribute_id;

Where:
roleattribute The roleattribute keyword.
role_id The identifier of a previously declared role.
attribute_id One or more previously declared
attribute_role identifiers. Multiple entries
consist of a comma (,) separated list.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Examples:
# Using the roleattribute statement to associate a previously
# declared role of service_r to a previously declared
# role_list_1 attribute_role.

attribute_role role_list_1;
role service_r;

# The association using the roleattribute statement:

Page 188
The SELinux Notebook

roleattribute service_r role_list_1;

4.6.4 allow
The role allow rule checks whether a request to change roles is allowed, if it is, then
there may be a further request for a role_transition so that the process runs
with the new role or role set.
Note that the role allow rule has the same keyword as the allow AV rule.

The statement definition is:
allow from_role_id to_role_id;

Where:
allow The role allow rule keyword.
from_role_id One or more role or attribute_role
identifiers that identify the current role. Multiple
entries consist of a space separated list enclosed
in braces ({}).
to_role_id One or more role or attribute_role
identifiers that identify the new role to be granted
on the transition. Multiple entries consist of a
space separated list enclosed in braces ({}).

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Example:
# Using the role allow rule to define authorised role
# transitions in the Reference Policy. The current role
# sysadm_r is granted permission to transition to the secadm_r
# role in the MLS policy.

allow sysadm_r secadm_r;

4.6.5 role_transition
The role_transition rule specifies that a role transition is required, and if
allowed, the process will run under the new role. From policy version 25, the class
can now be defined.

Page 189
The SELinux Notebook

The statement definition is:
role_transition current_role_id type_id new_role_id;

Or from Policy version 25:
role_transition current_role_id type_id : class new_role_id;

Where:
role_transition The role_transition keyword.
current_role_id One or more role or attribute_role
identifiers that identify the current role. Multiple
entries consist of a space separated list enclosed in
braces ({}).
type_id One or more type, typealias or attribute
identifiers. Multiple entries consist of a space
separated list enclosed in braces ({}). Entries can
be excluded from the list by using the negative
operator (-).
class For policy versions >= 25 an object class that
applies to the role transition. If omitted defaults to
the process object class.
new_role_id A single role identifier that will become the new
role.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Example:
# This is a role_transition used in the ext_gateway.conf
# loadable module to allow the secure client / server process to
# run under the message_filter_r role. The role needs to be
# declared, allowed to transition from its current role of
# unconfined_r and it then transitions when the process
# transitions via the type_transition statement (not shown).
# Note that the role needs to be associated to a user by either:
# 1) An embedded user statement in the policy. This is not
# recommended as it makes the policy fixed to either
# standard, MCS or MLS.
# 2) Using the semanage(8) command to add the role. This will
# allow the module to be used by MCS/MLS policies as well.
#

Page 190
The SELinux Notebook

# The secure client / server will run in this domain:
type ext_gateway_t;

# The binaries will be labeled:
type secure_services_exec_t;

# Use message_filter_r role and then transition
role message_filter_r types ext_gatway_t;
allow unconfined_r message_filter_r;
role_transition unconfined_r secure_services_exec_t message_filter_r;

4.6.6 dominance
This rule has been deprecated and therefore should not be used. The role
dominance rule allows the dom_role_id to dominate the role_id (consisting
of one or more roles). The dominant role will automatically inherit all the type
associations of the other roles.
Notes:
1. There is another dominance rule for MLS (see the MLS dominance
statement).
2. The role dominance rule is not used by the Reference Policy as the policy
manages role dominance using the constrain statement.
3. Note the usage of braces '{}' and the ';' in the statement.

The statement definition is:
dominance { role dom_role_id { role role_id; } }

Where:
dominance The dominance keyword.
role The role keyword.
dom_role_id The dominant role identifier.
role_id For the simple case each { role role_id; }
pair defines the role_id that will be dominated by
the dom_role_id.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Example:

Page 191
The SELinux Notebook

# This shows the dominance role rule, note however that it
# has been deprecated and should not be used.

dominance { role message_filter_r { role unconfined_r };}

4.7 Type Statements
These statements share the same namespace, therefore the general convention is to
use '_t' as the final two characters of a type identifier to differentiate it from an
attribute identifier as shown in the following examples:

# Statement Identifier Comment
#-------------------------------------------
type bin_t; # A type identifier ends with _t
attribute file_type; # An attribute identifier ends with
# generally ends with _type

4.7.1 type
The type statement declares the type identifier and any optional associated alias
or attribute identifiers. Type identifiers are a component of the Security Context.

The statement definition is:
type type_id [alias alias_id] [, attribute_id];

Where:
type The type keyword.
type_id The type identifier.
alias Optional alias keyword that signifies alternate
identifiers for the type_id that are declared in the
alias_id list.
alias_id One or more alias identifiers that have been
previously declared by the typealias statement.
Multiple entries consist of a space separated list
enclosed in braces ({}).
attribute_id One or more optional attribute identifiers that
have been previously declared by the attribute
statement. Multiple entries consist of a comma (,)
separated list, also note the lead comma.

The statement is valid in:

Page 192
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No No Yes

Examples:
# Using the type statement to declare a type of shell_exec_t,
# where exec_t is used to identify a file as an executable type.

type shell_exec_t;

# Using the type statement to declare a type of bin_t, where
# bin_t is used to identify a file as an ordinary program type.

type bin_t;

# Using the type statement to declare a type of bin_t with two
# alias names. The sbin_t is used to identify the file as a
# system admin program type.

type bin_t alias { ls_exec_t sbin_t };

# Using the type statement to declare a type of boolean_t that
# also associates it to a previously declared attribute
# booleans_type (see the attribute statement)

attribute booleans_type; # declare the attribute

type boolean_t, booleans_type; # and associate with the type

# Using the type statement to declare a type of setfiles_t that
# also has an alias of restorecon_t and one previously declared
# attribute of can_relabelto_binary_policy associated with it.

attribute can_relabelto_binary_policy;

type setfiles_t alias restorecon_t, can_relabelto_binary_policy;

# Using the type statement to declare a type of
# ssh_server_packet_t that also associates it to two previously
# declared attributes packet_type and server_packet_type.

attribute packet_type; # declare attribute 1
attribute server_packet_type; # declare attribute 2

# Associate the type identifier with the two attributes:

type ssh_server_packet_t, packet_type, server_packet_type;

Page 193
The SELinux Notebook

4.7.2 attribute
An attribute statement declares an identifier that can then be used to refer to a
group of type identifiers.

The statement definition is:
attribute attribute_id;

Where:
attribute The attribute keyword.
attribute_id The attribute identifier.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes Yes

Examples:
# Using the attribute statement to declare attributes domain,
# daemon, file_type and non_security_file_type:

attribute domain;
attribute daemon;
attribute file_type;
attribute non_security_file_type;

4.7.3 typeattribute
The typeattribute statement allows the association of previously declared
types to one or more previously declared attributes.

The statement definition is:
typeattribute type_id attribute_id;

Where:
typeattribute The typeattribute keyword.
type_id The identifier of a previously declared type.
attribute_id One or more previously declared attribute
identifiers. Multiple entries consist of a comma (,)
separated list.

The statement is valid in:

Page 194
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Examples:
# Using the typeattribute statement to associate a previously
# declared type of setroubleshootd_t to a previously declared
# domain attribute.

# The previously declared attribute:
attribute domain;

# The previously declared type:
type setroubleshootd_t;

# The association using the typeattribute statement:
typeattribute setroubleshootd_t domain;

# Using the typeattribute statement to associate a type of
# setroubleshootd_exec_t to two attributes file_type and
# non_security_file_type.

# These are the previously declared attributes:
attribute file_type;
attribute non_security_file_type;

# The previously declared type:
type setroubleshootd_exec_t;

# These are the associations using the typeattribute statement:
typeattribute setroubleshootd_exec_t file_type, non_security_file_type;

4.7.4 typealias
The typealias statement allows the association of a previously declared type to
one or more alias identifiers (an alternative way is to use the type statement.

The statement definition is:
typealias type_id alias alias_id;

Where:
typealias The typealias keyword.
type_id The identifier of a previously declared type.
alias The alias keyword.
alias_id One or more alias identifiers. Multiple entries
consist of a space separated list enclosed in braces
({}).

Page 195
The SELinux Notebook

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Examples:
# Using the typealias statement to associate the previously
# declared type mount_t with an alias of mount_ntfs_t.

# Declare the type:
type mount_t;

# Then alias the identifier:
typealias mount_t alias mount_ntfs_t;

# Using the typealias statement to associate the previously
# declared type netif_t with two alias, lo_netif_t and
# netif_lo_t.

# Declare the type:
type netif_t;

# Then assign two alias identifiers lo_netif_t and netif_lo_t:
typealias netif_t alias { lo_netif_t netif_lo_t };

4.7.5 permissive
Policy version 23 introduced the permissive statement to allow the named domain
to run in permissive mode instead of running all SELinux domains in permissive
mode (that was the only option prior to version 23). Note that the permissive
statement:
1. Only tests the source context for any policy denial.
2. Can be set by the semanage(8) command as it supports a permissive option
as follows:
# semanage supports enabling and disabling of permissive
# mode using the following command:
# semanage permissive -a|d type

# This example will add a new module in /etc/selinux/
# <policy_name>/modules/active/modules/ called
# permissive_unconfined_t.pp and then reload the policy:

semanage permissive -a unconfined_t

3. Can be built into a loadable policy module so that permissive mode can be
easily enabled or disabled by adding or removing the module. An example
module is as follows:

Page 196
The SELinux Notebook

# This is an example loadable module that would allow the
# domain to be set to permissive mode.
#
module permissive_unconfined_t 1.0.0;
require {
type unconfined_t;
}
permissive unconfined_t;

The statement definition is:
permissive type_id;

Where:
permissive The permissive keyword.
type_id The type identifier of the domain that will be run
in permissive mode.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Example:
# This is the simple statement that would allow permissive mode
# to be set on the httpd_t domain, however this statement is
# generally built into a loadable policy module so that the
# permissive mode can be easily removed by removing the module.
#
permissive httpd_t;

semanage(8) Command example:

semanage permissive -a unconfined_t

This command will produce the following module in the default <policy_name>
policy store and then activate the policy:
/etc/selinux/<policy_name>/modules/active/modules/permissive_unconfined_t.pp

4.7.6 type_transition
The type_transition rule specifies the default type to be used for domain
transistion or object creation. Kernels from 2.6.39 with Policy versions from 25 also
support the 'name transition rule' extension. See the Computing Security Contexts

Page 197
The SELinux Notebook

section for more details. Note than an allow rule must be used to authorise the
transition.

The statement definitions are:
type_transition source_type target_type : class default_type;

Policy versions 25 and above also support a 'name transition' rule however, this is
only appropriate for the file classes:
type_transition source_type target_type : class default_type object_name;

Where:
type_transition The type_transition rule keyword.
source_type One or more source / target type, typealias or
target_type attribute identifiers. Multiple entries consist of
a space separated list enclosed in braces ({}).
Entries can be excluded from the list by using the
negative operator (-).
class One or more object classes. Multiple entries consist
of a space separated list enclosed in braces ({}).
default_type A single type or typealias identifier that will
become the default process type for a domain
transition or the type for object transitions.
object_name For the 'name transition' rule this is matched against
the objects name (i.e. the last component of a path).
If object_name exactly matches the object
name, then use default_type for the type.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
Yes Yes No

Example - Domain Transition:
# Using the type_transition statement to show a domain
# transition (as the statement has the process object class).

# The rule states that when a process of type initrc_t executes
# a file of type acct_exec_t, the process type should be changed
# to acct_t if allowed by the policy (i.e. Transition from the
# initrc_t domain to the acc_t domain).

Page 198
The SELinux Notebook

type_transition initrc_t acct_exec_t:process acct_t;

# Note that to be able to transition to the acc_t domain the
# following minimum permissions need to be granted in the policy
# using allow rules (as shown in the allow rule section).

# File needs to be executable in the initrc_t domain:
allow initrc_t acct_exec_t:file execute;

# The executable file needs an entry point into the acct_t
# domain:
allow acct_t acct_exec_t:file entrypoint;

# Process needs permission to transition into the acct_t domain:
allow initrc_t acct_t:process transition;

Example - Object Transition:
# Using the type_transition statement to show an object
# transition (as it has other than process in the class).

# The rule states that when a process of type acct_t creates a
# file in the directory of type var_log_t, by default it should
# have the type wtmp_t if allowed by the policy.

type_transition acct_t var_log_t:file wtmp_t;

# Note that to be able to create the new file object with the
# wtmp_t type, the following minimum permissions need to be
# granted in the policy using allow rules (as shown in the
# allow rule section).

# A minimum of: add_name, write and search on the var_log_t
# directory. The actual policy has:
#
allow acct_t var_log_t:dir { read getattr lock search ioctl
add_name remove_name write };

# A minimum of: create and write on the wtmp_t file. The actual
# policy has:
#
allow acct_t wtmp_t:file { create open getattr setattr read
write append rename link unlink ioctl lock };

Example - Name Transition:
# type_transition to allow using the last path component as
# part of the information in making labeling decisions for
# new objects. An example rule:
#
type_transition unconfined_t etc_t : file system_conf_t eric;

# This rule says if unconfined_t creates a file in a directory
# labeled etc_t and the last path component is "eric" (must be
# an exact strcmp) it should be labeled system_conf_t.

Page 199
The SELinux Notebook

4.7.7 type_change
The type_change rule specifies a default type when relabeling an existing object.
For example userspace SELinux-aware applications would use
security_compute_relabel(3) and type_change rules in policy to
determine the new context to be applied. Note that an allow rule must be used to
authorise access. See the Computing Security Contexts section for more details.

The statement definition is:
type_change source_type target_type : class change_type;

Where:
type_change The type_change rule keyword.
source_type One or more source / target type, typealias or
target_type attribute identifiers. Multiple entries consist of
a space separated list enclosed in braces ({}).
Entries can be excluded from the list by using the
negative operator (-).
class One or more object classes. Multiple entries consist
of a space separated list enclosed in braces ({}).
change_type A single type or typealias identifier that will
become the new type.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
Yes Yes No

Examples:
# Using the type_change statement to show that when relabeling a
# character file with type sysadm_devpts_t on behalf of
# auditadm_t, the type auditadm_devpts_t should be used:

type_change auditadm_t sysadm_devpts_t:chr_file auditadm_devpts_t;

# Using the type_change statement to show that when relabeling a
# character file with any type associated to the attribute
# server_ptynode on behalf of staff_t, the type staff_devpts_t
# should be used:

type_change staff_t server_ptynode:chr_file staff_devpts_t;

Page 200
The SELinux Notebook

4.7.8 type_member
The type_member rule specifies a default type when creating a polyinstantiated
object. For example a userspace SELinux-aware application would use
avc_compute_member(3) or security_compute_member(3) with
type_member rules in policy to determine the context to be applied. Note that an
allow rule must be used to authorise access. See the Computing Security Contexts
section for more details.

The statement definition is:
member_type source_type target_type : class member_type;

Where:
type_member The type_member rule keyword.
source_type One or more source / target type, typealias or
target_type attribute identifiers. Multiple entries consist of
a space separated list enclosed in braces ({}).
Entries can be excluded from the list by using the
negative operator (-).
class One or more object classes. Multiple entries consist
of a space separated list enclosed in braces ({}).
member_type A single type or typealias identifier that will
become the polyinstantiated type.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
Yes Yes No

Example:
# Using the type_member statement to show that if the source
# type is sysadm_t, and the target type is user_home_dir_t,
# then use user_home_dir_t as the type on the newly created
# directory object.

type_member sysadm_t user_home_dir_t:dir user_home_dir_t;

4.8 Bounds Rules
Bounds handling was added in version 24 of the policy and consisted of adding
userbounds, rolebounds and typebounds information to the policy.
However only the typebounds rule is currently implemented by

Page 201
The SELinux Notebook

checkpolicy(8) and checkmodule(8) with kernel support from 2.6.28. The
CIL compiler does support userbounds and rolebounds but these are resolved
at policy compile time, not via the kernel at run-time.

4.8.1 typebounds
The typebounds rule was added in version 24 of the policy. This defines a
hierarchical relationship between domains where the bounded domain cannot have
more permissions than its bounding domain (the parent). It requires kernel 2.6.28 and
above to control the security context associated to threads in multi-threaded
applications.

The statement definition is:
typebounds bounding_domain bounded_domain;

Where:
typebounds The typebounds keyword.
bounding_domain The type or typealias identifier of the parent
domain.
bounded_domain One or more type or typealias identifiers of
the child domains. Multiple entries consist of a
comma (,) separated list.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Example:
# This example states that:
# The httpd_child_t cannot have file:{write} due to lack of
# permissions on httpd_t which is the parent. It means the
# child domains will always have equal or less privileges
# than the parent.

# The typebounds statement:
typebounds httpd_t httpd_child_t;

# The parent is allowed file 'getattr' and 'read':
allow httpd_t etc_t : file { getattr read };

# However the child process has been given 'write' access that
# will not be allowed by the kernel SELinux security server.
allow httpd_child_t etc_t : file { read write };

Page 202
The SELinux Notebook

4.9 Access Vector Rules
The AV rules define what access control privileges are allowed for processes. There
are four types of AV rule: allow, dontaudit, auditallow, and neverallow
as explained in the sections that follow with a number of examples to cover all the
scenarios. There is also an auditdeny rule, however it is no longer used in the
Reference Policy and has been replaced by the dontaudit rule.
The general format of an AV rule is that the source_type is the identifier of a
process that is attempting to access an object identifier target_type, that has an
object class of class, and perm_set defines the access permissions
source_type is allowed.

The common format of the Access Vector Rule is:
rule_name source_type target_type : class perm_set;

Where:
rule_name The applicable allow, dontaudit,
auditallow, and neverallow rule keyword.
source_type One or more source / target type, typealias or
target_type attribute identifiers. Multiple entries consist of a
space separated list enclosed in braces ({}). Entries
can be excluded from the list by using the negative
operator (-).
The target_type can have the self keyword
instead of type, typealias or attribute
identifiers. This means that the target_type is
the same as the source_type.
The neverallow rule also supports the wildcard
operator (*) to specify that all types are to be
included and the complement operator (~) to specify
all types are to be included except those explicitly
listed.
class One or more object classes. Multiple entries consist
of a space separated list enclosed in braces ({}).
perm_set The access permissions the source is allowed to
access for the target object (also known as the Acess
Vector). Multiple entries consist of a space separated
list enclosed in braces ({}).
The optional wildcard operator (*) specifies that all
permissions for the object class can be used.
The complement operator (~) is used to specify all
permissions except those explicitly listed (although
the compiler issues a warning if the dontaudit
rule has '~').

Page 203
The SELinux Notebook

The statements are valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
allow = Yes allow = Yes allow = No
auditallow = Yes auditallow = Yes auditallow = No
dontaudit = Yes dontaudit = Yes dontaudit = No
neverallow = No neverallow = Yes neverallow = No

4.9.1 allow
The allow rule checks whether the operations between the source_type and
target_type are allowed for the class and permissions defined. It is the most
common statement that many of the Reference Policy helper macros and interface
definitions expand into multiple allow rules.
Examples:
# Using the allow rule to show that initrc_t is allowed access
# to files of type acct_exec_t that have the getattr, read and
# execute file permissions:

allow initrc_t acct_exec_t:file { getattr read execute };

# This rule includes an attribute filesystem_type and states
# that kernel_t is allowed mount permissions on the filesystem
# object for all types associated to the filesystem_type
# attribute:

allow kernel_t filesystem_type:filesystem mount;

# This rule includes the self keyword in the target_type that
# states that staff_t is allowed setgid, chown and fowner
# permissions on the capability object:

allow staff_t self:capability { setgid chown fowner };

# This would be the same as the above:
allow staff_t staff_t:capability { setgid chown fowner };

# This rule includes the wildcard operator (*) on the perm_set
# and states that bootloader_t is allowed to use all permissions
# available on the dbus object that are type system_dbusd_t:

allow bootloader_t system_dbusd_t:dbus *;

# This would be the same as the above:
allow bootloader_t system_dbusd_t:dbus { acquire_svc send_msg };

# This rule includes the complement operator (~) on the perm_set

Page 204
The SELinux Notebook

# and two class entries file and chr_file.
#
# The allow rule states that all types associated with the
# attribute files_unconfined_type are allowed to use all
# permissions available on the file and chr_file objects except
# the execmod permission when they are associated to the types
# listed within the attribute file_type:

allow files_unconfined_type file_type:{ file chr_file } ~execmod;

4.9.2 dontaudit
The dontaudit rule stops the auditing of denial messages as it is known that this
event always happens and does not cause any real issues. This also helps to manage
the audit log by excluding known events.
Example:
# Using the dontaudit rule to stop auditing events that are
# known to happen. The rule states that when the traceroute_t
# process is denied access to the name_bind permission on a
# tcp_socket for all types associated to the port_type
# attribute (except port_t), then do not audit the event:

dontaudit traceroute_t { port_type -port_t }:tcp_socket name_bind;

4.9.3 auditallow
Audit the event as a record as it is useful for auditing purposes. Note that this rule
only audits the event, it still requires the allow rule to grant permission.
Example:
# Using the auditallow rule to force an audit event to be
# logged. The rule states that when the ada_t process has
# permission to execstack, then that event must be audited:

auditallow ada_t self:process execstack;

4.9.4 neverallow
This rule specifies that an allow rule must not be generated for the operation, even if
it has been previously allowed. The neverallow statement is a compiler enforced
action, where the checkpolicy or checkmodule46 compiler checks if any
allow rules have been generated in the policy source, if so it will issue a warning
and stop.
Examples:
# Using the neverallow rule to state that no allow rule may ever
# grant any file read access to type shadow_t except those
# associated with the can_read_shadow_passwords attribute:

46
neverallow statements are allowed in modules, however to detect these the semanage.conf
file must have the expand-check=1 entry present.

Page 205
The SELinux Notebook

neverallow ~can_read_shadow_passwords shadow_t:file read;

# Using the neverallow rule to state that no allow rule may ever
# grant mmap_zero permissions any type associated to the domain
# attribute except those associated to the mmap_low_domain_type
# attribute (as these have been excluded by the negative
# operator (-)):

neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;

4.10 Object Class and Permission Statements
For those who write or manager SELinux policy, there is no need to define new
objects and their associated permissions as these would be done by those who actually
design and/or write object managers.
A list of object classes used by the Reference Policy can be found in the
./policy/flask/security_classes file.
There are two variants of the class statement for writing policy:
1. There is the class statement that declares the actual class identifier or name.
2. There is a further refinement of the class statement that associates
permissions to the class as discussed in the Associating Permissions to a Class
section.

4.10.1 class
Object classes are declared within a policy as follows:

The statement definition is:
class class_id

Where:
class The class keyword.
class_id The class identifier.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No Yes

Example:
# Define the PostgreSQL db_tuple object class

Page 206
The SELinux Notebook

#
class db_tuple

4.10.2 Associating Permissions to a Class
Permissions can be defined within policy in two ways:
1. Define a set of common permissions that can then be inherited by one or more
object classes using further class statements.
2. Define class specific permissions. This is where permissions are declared
for a specific object class only (i.e. the permission is not inherited by any other
object class).
A list of classes and their permissions used by the Reference Policy can be found in
the ./policy/flask/access_vectors file.

4.10.3 common
Declare a common identifier and associate one or more common permissions.

The statement definition is:
common common_id { perm_set }

Where:
common The common keyword.
common_id The common identifier.
perm_set One or more permission identifiers in a space
separated list enclosed within braces ({}).

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# Define the common PostgreSQL permissions
#
common database { create drop getattr setattr relabelfrom relabelto }

4.10.4 class
Inherit and / or associate permissions to a perviously declared class identifier.

The statement definition is:

Page 207
The SELinux Notebook

class class_id [ inherits common_set ] [ { perm_set } ]

Where:
class The class keyword.
class_id The previously declared class identifier.
inherits The optional inherits keyword that allows a
set of common permissions to be inherited.
common_set A previously declared common identifier.
perm_set One or more optional permission identifiers in a
space separated list enclosed within braces ({}).

Note:
There must be at least one common_set or one perm_set defined within the
statement.
The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No Yes

Examples:
# The following example shows the db_tuple object class being
# allocated two permissions:

class db_tuple { relabelfrom relabelto }

# The following example shows the db_blob object class
# inheriting permissions from the database set of common
# permissions (as described in the
# Associating Permissions to a Class section):

class db_blob inherits database

# The following example (from the access_vector file) shows the
# db_blob object class inheriting permissions from the database
# set of common permissions and adding a further four
# permissions:

class db_blob inherits database { read write import export }

Page 208
The SELinux Notebook

4.11 Conditional Policy Statements
Conditional policies consist of a bool statement that defines a condition as true or
false, with a supporting if / else construct that specifies what rules are valid
under the condition as shown in the example below:
bool allow_daemons_use_tty true;

if (allow_daemons_use_tty) {
# Rules if condition is true;

} else {
# Rules if condition is false;
}

Table 16 shows what policy statements or rules are valid within the if / else
construct under the "Conditional Statements" column.
The bool statement default value can be changed when a policy is active by using
the setsebool command as follows:

# This command will set the allow_daemons_use_tty bool to false,
# however it will only remain false until the next system
# re-boot where it will then revert back to its default state
# (in the above case, this would be true).

setsebool allow_daemons_use_tty false

# This command will set the allow_daemons_use_tty bool to false,
# and because the -P option is used (for persistent), the value
# will remain across system re-boots. Note however that all
# other pending bool values will become persistent across
# re-boots as well (see setsebool(8) man page).

setsebool -P allow_daemons_use_tty false

The getsebool command can be used to query the current bool statement value
as follows:
# This command will list all bool values in the active policy:

getsebool -a

# This command will show the current allow_daemons_use_tty bool
# value in the active policy:

getsebool allow_daemons_use_tty

4.11.1 bool
The bool statement is used to specify a boolean identifier and its initial state (true
or false) that can then be used with the if statement to form a 'conditional policy'
as described in the Conditional Policy section.

Page 209
The SELinux Notebook

The statement definition is:
bool bool_id default_value;

Where:
bool The bool keyword.
bool_id The boolean identifier.
default_value Either true or false.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes Yes

Examples:
# Using the bool statement to allow unconfined executables to
# make their memory heap executable or not. As the value is
# false, then by default they cannot make their heap executable.

bool allow_execheap false;

# Using the bool statement to allow unconfined executables to
# make their stack executable or not. As the value is true,
# then by default their stacks are executable.

bool allow_execstack true;

4.11.2 if
The if statement is used to form a 'conditional block' of statements and rules that are
enforced depending on whether one or more boolean identifiers (defined by the bool
Statement) evaluate to TRUE or FALSE. An if / else construct is also supported.
The only statements and rules allowed within the if / else construct are:
allow, auditallow, auditdeny, dontaudit, type_member,
type_transition (except 'file_name_transition'), type_change and
require.

The statement definition is:
if (conditional_expression) { true_list } [ else { false_list } ]

Where:
if The if keyword.

Page 210
The SELinux Notebook

conditional_expression One or more bool_name identifiers that
have been previously defined by the bool
Statement. Multiple identifiers must be
separated by the following logical operators:
&&, ¦¦, ^, !, ==, !=.
The conditional_expression is
enclosed in brackets ().
true_list A list of rules enclosed within braces '{}' that
will be executed when the
conditional_expression is 'true'.
Valid statements and rules are highlighted
within each language definition statement.
else Optional else keyword.
false_list A list of rules enclosed within braces '{}' that
will be executed when the optional 'else'
keyword is present and the
conditional_expression is 'false'.
Valid statements and rules are highlighted
within each language definition statement.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Examples:
# An example showing a boolean and supporting if statement.

bool allow_execmem false;

# The bool allow_execmem is FALSE therefore the allow statement
# is not executed:

if (allow_execmem) {
allow sysadm_t self:process execmem;
}

# An example showing two booleans and a supporting if statement.

bool allow_execmem false;
bool allow_execstack true;

# The bool allow_execmem is FALSE and allow_execstack is TRUE
# therefore the allow statement is not executed:

Page 211
The SELinux Notebook

if (allow_execmem && allow_execstack) {
allow sysadm_t self:process execstack;
}

# An example of an IF - ELSE statement where the bool statement
# is FALSE, therefore the ELSE statements will be executed.
#
bool read_untrusted_content false;

if (read_untrusted_content) {
allow sysadm_t { sysadm_untrusted_content_t
sysadm_untrusted_content_tmp_t }:dir { getattr search
read lock ioctl };
.....

} else {
dontaudit sysadm_t { sysadm_untrusted_content_t
sysadm_untrusted_content_tmp_t }:dir { getattr search
read lock ioctl };
...
}

4.12 Constraint Statements

4.12.1 constrain
The constrain statement allows further restriction on permissions for the specified
object classes by using boolean expressions covering: source and target types, roles
and users as described in the examples.

The statement definition is:
constrain class perm_set expression;

Where:
constrain The constrain keyword.
class One or more object classes. Multiple entries consist
of a space separated list enclosed in braces ({}).
perm_set One or more permissions. Multiple entries consist of
a space separated list enclosed in braces ({}).
expression The boolean expression of the constraint that is
defined as follows:
( expression : expression )
| not expression
| expression and expression
| expression or expression
| u1 op u2
| r1 role_op r2

Page 212
The SELinux Notebook

| t1 op t2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names
Where:
u1, r1, t1 = Source user, role, type
u2, r2, t2 = Target user, role, type
and:
op : == | !=
role_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
These examples have been taken from the Reference Policy source
./policy/constraints file.

# This constrain statement is the "SELinux process identity
# change constraint" taken from the Reference Policy source and
# contains multiple expressions.
#
# The overall constraint is on the process object class with the
# transition permission, and is stating that a domain transition
# is being constrained by the rules listed (u1 == u2 etc.),
# however only the first two expressions are explained.
#
# The first expression u1 == u2 states that the source (u1) and
# target (u2) user identifiers must be equal for a process
# transition to be allowed.
#
# However note that there are a number of or operators that can
# override this first constraint.
#
# The second expression:
# ( t1 == can_change_process_identity and t2 == process_user_target )
#
# states that if the source type (t1) is equal to any type
# associated to the can_change_process_identity attribute, and
# the target type (t2) is equal to any type associated to the
# process_user_target attribute, then a process transition is
# allowed.

Page 213
The SELinux Notebook

# What this expression means in the 'standard' build Reference
# Policy is that if the source domain is either cron_t,
# firstboot_t, local_login_t, su_login_t, sshd_t or xdm_t (as
# the can_change_process_identity attribute has these types
# associated to it) and the target domain is sysadm_t (as that
# is the only type associated to the can_change_process_identity
# attribute), then a domain transition is allowed.
#
# SELinux process identity change constraint:
constrain process transition (
u1 == u2
or
( t1 == can_change_process_identity and t2 == process_user_target )
or
( t1 == cron_source_domain and ( t2 == cron_job_domain or u2 == system_u ))
or
( t1 == can_system_change and u2 == system_u )
or
( t1 == process_uncond_exempt ) );

# This constrain statement is the "SELinux file related object
# identity change constraint" taken from the Reference Policy
# source and contains two expressions.
#
# The overall constraint is on the listed file related object
# classes (dir, file etc.), covering the create, relabelto, and
# relabelfrom permissions. It is stating that when any of the
# object class listed are being created or relabeled, then they
# are subject to the constraint rules listed (u1 == u2 etc.).
#
# The first expression u1 == u2 states that the source (u1) and
# target (u2) user identifiers (within the security context)
# must be equal when creating or relabeling any of the file
# related objects listed.
#
# The second expression:
# or t1 == can_change_object_identity
#
# states or if the source type (t1) is equal to any type
# associated to the can_change_object_identity attribute, then
# any of the object class listed can be created or relabeled.
#
# What this expression means in the 'standard' build
# Reference Policy is that if the source domain (t1) matches a
# type entry in the can_change_object_identity attribute, then
# any of the object class listed can be created or relabeled.
#
# SELinux file related object identity change constraint:
constrain { dir file lnk_file sock_file fifo_file chr_file
blk_file } { create relabelto relabelfrom }
(
u1 == u2
or t1 == can_change_object_identity
);

Page 214
The SELinux Notebook

4.12.2 validatetrans
Only file related object classes are currently supported by this statement and it is used
to control the ability to change the objects security context.
Note there are no validatetrans statements specified within the Reference
Policy source.

The statement definition is:
validatetrans class expression;

Where:
validatetrans The validatetrans keyword.
class One or more file related object classes. Multiple
entries consist of a space separated list enclosed
in braces ({}).
expression The boolean expression of the constraint that
is defined as follows:
( expression : expression )
| not expression
| expression and expression
| expression or expression
| u1 op u2
| r1 role_op r2
| t1 op t2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names
| u3 op names
| r3 op names
| t3 op names
Where:
u1, r1, t1 = Old user, role, type
u2, r2, t2 = New user, role, type
u3, r3, t3 = Process user, role, type
and:
op : == | !=
role_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name

The statement is valid in:

Page 215
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
validatetrans { file } { t1 == unconfined_t );

4.12.3 mlsconstrain
The mlsconstrain statement allows further restriction on permissions for the
specified object classes by using boolean expressions covering: source and target
types, roles, users and security levels as described in the examples.

The statement definition is:
mlsconstrain class perm_set expression;

Where:
mlsconstrain The mlsconstrain keyword.
class One or more object classes. Multiple entries consist
of a space separated list enclosed in braces {}.
perm_set One or more permissions. Multiple entries consist of
a space separated list enclosed in braces {}.
expression The boolean expression of the constraint that is
defined as follows:
( expression : expression )
| not expression
| expression and expression
| expression or expression
| u1 op u2
| r1 role_mls_op r2
| t1 op t2
| l1 role_mls_op l2
| l1 role_mls_op h2
| h1 role_mls_op l2
| h1 role_mls_op h2
| l1 role_mls_op h1
| l2 role_mls_op h2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names

Page 216
The SELinux Notebook

Where:
u1, r1, t1, l1, h1 = Source user, role, type, low level, high level
u2, r2, t2, l2, h2 = Target user, role, type, low level, high level
and:
op : == | !=
role_mls_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
These examples have been taken from the Reference Policy source ./policy/mls
constraints file. These are built into the policy at build time and add constraints to
many of the object classes.
# The MLS Reference Policy mlsconstrain statement for searching
# directories that comprises of multiple expressions. Only the
# first two expressions are explained.
#
# Expression 1 ( l1 dom l2 ) reads as follows:
# The dir object class search permission is allowed if the
# source low security level is dominated by the targets
# low security level.
# OR
# Expression 2 (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 ))
# reads as follows:
# If the source type is equal to a type associated to the
# mlsfilereadtoclr attribute and the source high security
# level is dominated by the targets low security level,
# then search permission is allowed on the dir object class.

mlsconstrain dir search
(( l1 dom l2 ) or
(( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsfileread ) or
( t2 == mlstrustedobject ));

4.12.4 mlsvalidatetrans
The mlsvalidatetrans is the MLS equivalent of the validatetrans
statement and is only used for file related object classes where it is used to control the
ability to change the objects security context.

The statement definition is:

Page 217
The SELinux Notebook

mlsvalidatetrans class expression;

Where:
mlsvalidatetrans The mlsvalidatetrans keyword.
class One or more file type object classes. Multiple
entries consist of a space separated list enclosed
in braces {}.
expression The boolean expression of the constraint that
is defined as follows:
( expression : expression )
| not expression
| and (expression and expression
| or expression or expression
| u1 op u2
| r1 role_mls_op r2
| t1 op t2
| l1 role_mls_op l2
| l1 role_mls_op h2
| h1 role_mls_op l2
| h1 role_mls_op h2
| l1 role_mls_op h1
| l2 role_mls_op h2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names
| u3 op names
| r3 op names
| t3 op names
Where:
u1, r1, t1, l1, h1 = Old user, role, type, low level, high level
u2, r2, t2, l2, h2 = New user, role, type, low level, high level
u3, r3, t3, l3, h3 = Process user, role, type, low level, high level
and:
op : == | !=
role_mls_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:

Page 218
The SELinux Notebook

This example has been taken from the Reference Policy source ./policy/mls file.

# The MLS Reference Policy mlsvalidatetrans statement for
# managing the file upgrade/downgrade rules that comprises of
# multiple expressions. Only the first two expressions are
# explained.
#
# Expression 1: ( l1 eq l2 ) reads as follows:
# For a file related object to change security context, its
# current (old) low security level must be equal to the new
# objects low security level.
#
# The second part of the expression:
# or (( t3 == mlsfileupgrade ) and ( l1 domby l2 )) reads as
# follows:
# or the process type must equal a type associated to the
# mlsfileupgrade attribute and its current (old) low security
# level must be dominated by the new objects low security level.
#
mlsvalidatetrans { dir file lnk_file chr_file blk_file sock_file
fifo_file }
((( l1 eq l2 ) or
(( t3 == mlsfileupgrade ) and ( l1 domby l2 )) or
(( t3 == mlsfiledowngrade ) and ( l1 dom l2 )) or
(( t3 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and (( h1 eq h2 )
or
(( t3 == mlsfileupgrade ) and ( h1 domby h2 )) or
(( t3 == mlsfiledowngrade ) and ( h1 dom h2 )) or
(( t3 == mlsfiledowngrade ) and ( h1 incomp h2 ))));

4.13 MLS Statements
The optional MLS policy extension adds an additional security context component
that consists of the following highlighted entries:
user:role:type:sensitivity[:category,...]- sensitivity [:category,...]

These consist of a mandatory hierarchical sensitivity and optional non-
hierarchical category's. The combination of the two comprise a level or security
level as shown in Table 17. Depending on the circumstances, there can be one level
defined or a range as shown in Table 17.

Page 219
The SELinux Notebook

Security Level (or Level) Note that SELinux uses level, sensitivity and
category in the language statements, however when
Consisting of a sensitivity and zero or discussing these the following terms can also be used:
more category entries: labels, classifications, and compartments.
sensitivity [: category, ... ]

 Range 
Low High
sensitivity [: category, ... ] - sensitivity [: category, ... ]

For a process or subject this is the For a process or subject this is the
current level or sensitivity Clearance

For an object this is the current level or For an object this is the maximum range
sensitivity

SystemLow SystemHigh

Table 17: Sensitivity and Category = Security Level - this table shows the
meanings depending on the context being discussed.
To make the security levels more meaningful, it is possible to use the setransd
daemon to translate these to human readable formats. The semanage(8) command
will allow this mapping to be defined as discussed in the ./setrans.conf file
section.

4.13.1 sensitivity
The sensitivity statement defines the MLS policy sensitivity identifies and
optional alias identifiers.

The statement definition is:
sensitivity sens_id [alias sensitivityalias_id ...];

Where:
sensitivity The sensitivity keyword.
sens_id The sensitivity identifier.
alias The optional alias keyword.
sensitivityalias_id One or more sensitivityalias identifiers
in a space separated list.

The statement is valid in:

Page 220
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No Yes

Examples:
# The MLS Reference Policy default is to assign 16 sensitivity
# identifiers (s0 to s15):
sensitivity s0;
....
sensitivity s15;

# The policy does not specify any alias entries, however a valid
# example would be:
sensitivity s0 alias secret wellmaybe ornot;

4.13.2 dominance
When more than one sensitivity statemement is defined within a policy, then a
dominance statement is required to define the actual hierarchy between all
sensitivities.

The statement definition is:
dominance { sensitivity_id ... }

Where:
dominance The dominance keyword.
sensitivity_id A space separated list of previously declared
sensitivity or sensitivityalias
identifiers in the order lowest to highest. They
are enclosed in braces ({}), and note that there is
no terminating semi-colon (;).

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# The MLS Reference Policy dominance statement defines s0 as the
# lowest and s15 as the highest sensitivity level:

dominance { s0 s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 s12 s13 s14 s15 }

Page 221
The SELinux Notebook

4.13.3 category
The category statement defines the MLS policy category identifiers 47 and optional
alias identifiers.

The statement definition is:
category category_id [alias categoryalias_id ...];

Where:
category The category keyword.
category_id The category identifier.
alias The optional alias keyword.
categoryalias_id One or more alias identifiers in a space separated
list.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No Yes

Examples:
# The MLS Reference Policy default is to assign 256 category
# identifiers (c0 to c255):
category c0;
...
category c255;

# The policy does not specify any alias entries, however a valid
# example would be:
category c0 alias planning development benefits;

4.13.4 level
The level statement enables the previously declared sensitivity and category
identifiers to be combined into a Security Level.
Note there must only be one level statement for each sensitivity statemement.

The statement definition is:
level sensitivity_id [ :category_id ];

Where:

47
SELinux use the term 'category' or 'categories' while some MLS systems and documentation use
the term 'compartment' or 'compartments', however they have the same meaning.

Page 222
The SELinux Notebook

level The level keyword.
sensitivity_id A previously declared sensitivity or
sensitivityalias identifier.
category_id An optional set of zero or more previously
declared category or categoryalias
identifiers that are preceded by a colon (:), that
can be written as follows:
• The period (.) separating two
category identifiers means an
inclusive set (e.g. c0.c16).
• The comma (,) separating two
category identifiers means a non-
contiguous list (e.g. c21,c36,c45).
• Both separators may be used (e.g.
c0.c16, c21,c36,c45).

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
# The MLS Reference Policy default is to assign each Security
# Level with the complete set of categories (i.e. the inclusive
# set from c0 to c255):

level s0:c0.c255;
...
level s15:c0.c255;

4.13.5 range_transition
The range_transition statement is primarily used by the init process or
administration commands to ensure processes run with their correct MLS range (for
example init would run at SystemHigh and needs to initialise / run other
processes at their correct MLS range). The statement was enhanced in Policy version
21 to accept other object classes.

The statement definition is (for pre-policy version 21):
range_transition source_type target_type new_range;

or (for policy version 21 and greater):

Page 223
The SELinux Notebook

range_transition source_type target_type : class new_range;

Where:
range_transition The range_transition keyword.
source_type One or more source / target type or attribute
target_type identifiers. Multiple entries consist of a space
separated list enclosed in braces ({}).
Entries can be excluded from the list by using the
negative operator (-).
class The optional object class keyword (this allows
policy versions 21 and greater to specify a class
other than the default of process).
new_range The new MLS range for the object class. The
format of this field is described in the MLS range
Definition section.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
No Yes No

Examples:
# A range_transition statement from the MLS Reference Policy
# showing that a process anaconda_t can transition between
# systemLow and systemHigh depending on calling applications
# level.

range_transition anaconda_t init_script_file_type:process s0-s15:c0.c255;

# Two range_transition statements from the MLS Reference Policy
# showing that init will transition the audit and cups daemon
# to systemHigh (that is the lowest level they can run at).

range_transition initrc_t auditd_exec_t:process s15:c0.c255;
range_transition initrc_t cupsd_exec_t:process s15:c0.c255;

4.13.5.1 MLS range Definition
The MLS range is appended to a number of statements and defines the lowest and
highest security levels. The range can also consist of a single level as discussed at
the start of the MLS section.

The definition is:
low_level[ - high_level ]

Page 224
The SELinux Notebook

Where:
low_level The processes lowest level identifier that has
been previously declared by a level statement.
If a high_level is not defined, then it is taken
as the same as the low_level.
- The optional hyphen (-) separator if a
high_level is also being defined.
high_level The processes highest level identifier that has
been previously declared by a level statement.

4.13.6 mlsconstrain
This is decribed in the Constraints section.

4.13.7 mlsvalidatetrans
This is decribed in the Constraints section.

4.14 Security ID (SID) Statement
There are two SID statements, the first one declares the actual SID identifier and is
defined at the start of a policy source file. The second statement is used to associate
an initial security context to the SID, this is used when SELinux initialises but the
policy has not yet been activated or as a default context should an object have an
invalid label.

4.14.1 sid
The sid statement declares the actual SID identifier and is defined at the start of a
policy source file.

The statement definition is:
sid sid_id

Where:
sid The sid keyword.
sid_id The sid identifier.

The statement is valid in:

Page 225
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
This example has been taken from the Reference Policy source
../policy/flask/initial_sids file.

# This example was taken from the
# ./policy/flask/initial_sids file and declares some
# of the initial SIDs:
#
sid kernel
sid security
sid unlabeled
sid fs

4.14.2 sid context
The sid context statement is used to associate an initial security context to the SID.

sid sid_id context

Where:
sid The sid keyword.
sid_id The previously declared sid identifier.
context The initial security context.

The statements are valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
# This is from a targeted policy:

sid unlabeled
...
sid unlabeled system_u:object_r:unlabeled_t

# This is from an MLS policy. Note that the security level
# is set to SystemHigh as it may need to label any object in
# the system.

Page 226
The SELinux Notebook

sid unlabeled
...
sid unlabeled system_u:object_r:unlabeled_t:s15:c0.c255

4.15 File System Labeling Statements
There are four types of file labeling statements: fs_use_xattr, fs_use_task,
fs_use_trans and genfscon that are explained below.
The filesystem identifiers (fs_name) used by these statements are defined by the
SELinux teams who are responsible for their development, the policy writer then uses
those needed to be supported by the policy.
A security context is defined by these filesystem labeling statements, therefore if the
policy supports MCS / MLS, then an mls_range is required as described in the
MLS range Definition section.

4.15.1 fs_use_xattr
The fs_use_xattr statement is used to allocate a security context to filesystems
that support the extended attribute security.selinux. The labeling is persistent
for filesystems that support these extended attributes, and the security context is
added to these files (and directories) by the SELinux commands such as setfiles
as explained in the Labeling Extended Attribute Filesystems section.

The statement definition is:
fs_use_xattr fs_name fs_context;

Where:
fs_use_xattr The fs_use_xattr keyword.
fs_name The filesystem name that supports extended
attributes. Example names are: encfs, ext2,
ext3, ext4, ext4dev, gfs, gfs2, jffs2,
jfs, lustre and xfs.
fs_context The security context allocated to the filesystem.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:

Page 227
The SELinux Notebook

# These statements define file systems that support extended
# attributes (security.selinux).

fs_use_xattr encfs system_u:object_r:fs_t:s0;
fs_use_xattr ext2 system_u:object_r:fs_t:s0;
fs_use_xattr ext3 system_u:object_r:fs_t:s0;

4.15.2 fs_use_task
The fs_use_task statement is used to allocate a security context to pseudo
filesystems that support task related services such as pipes and sockets.

The statement definition is:
fs_use_task fs_name fs_context;

Where:
fs_use_task The fs_use_task keyword.
fs_name Filesystem name that supports task related services.
Example valid names are: eventpollfs,
pipefs and sockfs.
fs_context The security context allocated to the task based
filesystem.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# These statements define the file systems that support pseudo
# filesystems that represent objects like pipes and sockets, so
# that these objects are labeled with the same type as the
# creating task.
#
fs_use_task eventpollfs system_u:object_r:fs_t:s0;
fs_use_task pipefs system_u:object_r:fs_t:s0;
fs_use_task sockfs system_u:object_r:fs_t:s0;

4.15.3 fs_use_trans
The fs_use_trans statement is used to allocate a security context to pseudo
filesystems such as pseudo terminals and temporary objects. The assigned context is
derived from the creating process and that of the filesystem type based on transition
rules.

Page 228
The SELinux Notebook

The statement definition is:
fs_use_trans fs_name fs_context;

Where:
fs_use_trans The fs_use_trans keyword.
fs_name Filesystem name that supports transition rules.
Example names are: mqueue, shm, tmpfs and
devpts.
fs_context The security context allocated to the transition
based on that of the filesystem.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# These statements define pseudo filesystems such as devpts
# and tmpfs where objects are labeled with a derived context.
#
fs_use_trans mqueue system_u:object_r:tmpfs_t:s0;
fs_use_trans shm system_u:object_r:tmpfs_t:s0;
fs_use_trans tmpfs system_u:object_r:tmpfs_t:s0;
fs_use_trans devpts system_u:object_r:devpts_t:s0;

4.15.4 genfscon
The genfscon statement is used to allocate a security context to filesystems that
cannot support any of the other file labeling statements (fs_use_xattr,
fs_use_task or fs_use_trans). Generally a filesystem would have a single
default security context assigned by genfscon from the root (/) that would then be
inherited by all files and directories on that filesystem. The exception to this is the
/proc filesystem, where directories can be labeled with a specific security context
(as shown in the examples). Note that there is no terminating semi-colon (;) on this
statement.

The statement definition is:
genfscon fs_name partial_path fs_context

Where:
genfscon The genfscon keyword.
fs_name The filesystem name.

Page 229
The SELinux Notebook

partial_path If fs_name is proc, then the partial path (see the
examples). For all other types, this must be '/'.
fs_context The security context allocated to the filesystem

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

MLS Examples:
# The following examples show those filesystems that only
# support a single security context across the filesystem
# with the MLS levels added.

genfscon msdos / system_u:object_r:dosfs_t:s0
genfscon iso9660 / system_u:object_r:iso9660_t:s0
genfscon usbfs / system_u:object_r:usbfs_t:s0
genfscon selinuxfs / system_u:object_r:security_t:s0

# The following show some example /proc entries. Note that the
# /kmsg has the highest sensitivity level assigned (s15) because
# it is a trusted process.

genfscon proc / system_u:object_r:proc_t:s0
genfscon proc /sysvipc system_u:object_r:proc_t:s0
genfscon proc /fs/openafs system_u:object_r:proc_afs_t:s0
genfscon proc /kmsg system_u:object_r:proc_kmsg_t:s15:c0.c255

4.16 Network Labeling Statements
The network labeling statements are used to label the following objects:
Network interfaces - This covers those interfaces managed by the
ifconfig(8) command.
Network nodes - These are generally used to specify host systems using either
IPv4 or IPv6 addresses.
Network ports - These can be either udp or tcp port numbers.
A security context is defined by these network labeling statements, therefore if the
policy supports MCS / MLS, then an mls_range is required as described in the
MLS range Definition section. Note that there are no terminating semi-colons (;)
on these statements.
If any of the network objects do not have a specific security context assigned by the
policy, then the value given in the policies initial SID is used (netif, node or port
respectively), as shown below:

Page 230
The SELinux Notebook

# Network Initial SIDs from the MLS Reference Policy:
sid netif system_u:object_r:netif_t:s0 - s15:c0.c255
sid node system_u:object_r:node_t:s0 - s15:c0.c255
sid port system_u:object_r:port_t:s0

4.16.1 IP Address Formats

4.16.1.1 IPv4 Address Format
IPv4 addresses are represented in dotted-decimal notation (four numbers, each
ranging from 0 to 255, separated by dots as shown:
192.77.188.166

4.16.1.2 IPv6 Address Formats
IPv6 addresses are written as eight groups of four hexadecimal digits, where each
group is separated by a colon (:) as follows:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

To shorten the writing and presentation of addresses, the following rules apply:
a) Any leading zeros in a group may be replaced with a single '0' as shown:

2001:db8:85a3:0:0:8a2e:370:7334

b) Any leading zeros in a group may be omitted and be replaced with two colons
(::), however this is only allowed once in an address as follows:

2001:db8:85a3::8a2e:370:7334

c) The localhost (loopback) address can be written as:
0000:0000:0000:0000:0000:0000:0000:0001

Or
::1

d) An undetermined IPv6 address i.e. all bits are zero is written as:
::

4.16.2 netifcon
The netifcon statement is used to label network interface objects (e.g. eth0).
It is also possible to use the 'semanage interface' command to associate the
interface to a security context.

Page 231
The SELinux Notebook

The statement definition is:
netifcon netif_id netif_context packet_context

Where:
netifcon The netifcon keyword.
netif_id The network interface name (e.g. eth0).
netif_context The security context allocated to the network
interface.
packet_context The security context allocated packets. Note that
these are defined but currently unused.
The iptable SECMARK services should be used to
label packets.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
# The following netifcon statement has been taken from the
# MLS policy that shows an interface name of lo with the same
# security context assigned to both the interface and packets.

netifcon lo system_u:object_r:lo_netif_t:s0 - s15:c0.c255
system_u:object_r:unlabeled_t:s0 - s15:c0.c255

semanage(8) Command example:

semanage interface -a -t netif_t eth2

This command will produce the following file in the default <policy_name>
policy store and then activate the policy:
/etc/selinux/<policy_name>/modules/active/interfaces.local:

# This file is auto-generated by libsemanage
# Do not edit directly.

netifcon eth2 system_u:object_r:netif_t:s0 system_u:object_r:netif_t:s0

4.16.3 nodecon
The nodecon statement is used to label network address objects that represent IPv4
or IPv6 IP addresses and network masks.

Page 232
The SELinux Notebook

It is also possible to add SELinux these outside the policy using the 'semanage
node' command that will associate the node to a security context.

The statement definition is:
nodecon subnet netmask node_context

Where:
nodecon The nodecon keyword.
subnet The subnet or specific IP address in IPv4 or IPv6
format.
Note that the subnet and netmask values are
used to ensure that the node_context is
assigned to all IP addresses within the subnet
range.
netmask The subnet mask in IPv4 or IPv6 format.
node_context The security context for the node.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
# The MLS policy nodecon statement using an IPv4 address:

nodecon 127.0.0.1 255.255.255.255 system_u:object_r:lo_node_t:
s0 - s15:c0.c255

# The MLS policy nodecon statement for the multicast address
# using an IPv6 address:

nodecon ff00:: ff00:: system_u:object_r:multicast_node_t:
s0 - s15:c0.c255

semanage(8) Command example:
semanage node -a -t node_t -p ipv4 -M 255.255.255.255 127.0.0.2

This command will produce the following file in the default <policy_name>
policy store and then activate the policy:
/etc/selinux/<policy_name>/modules/active/nodes.local:

Page 233
The SELinux Notebook

# This file is auto-generated by libsemanage
# Do not edit directly.

nodecon ipv4 127.0.0.2 255.255.255.255 system_u:object_r:node_t:s0

4.16.4 portcon
The portcon statement is used to label udp or tcp ports.
It is also possible to add a security context to ports outside the policy using the
'semanage port' command that will associate the port (or range of ports) to a
security context.

The statement definition is:
portcon protocol port_number port_context

Where:
portcon The portcon keyword.
protocol The protocol type. Valid entries are udp or tcp.
port_number The port number or range of ports. The ranges are
separated by a hyphen (-).
port_context The security context for the port or range of ports.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Examples:
# The MLS policy portcon statements:
portcon tcp 20 system_u:object_r:ftp_data_port_t:s0
portcon tcp 21 system_u:object_r:ftp_port_t:s0
portcon tcp 600-1023 system_u:object_r:hi_reserved_port_t:s0
portcon udp 600-1023 system_u:object_r:hi_reserved_port_t:s0
portcon tcp 1-599 system_u:object_r:reserved_port_t:s0
portcon udp 1-599 system_u:object_r:reserved_port_t:s0

semanage(8) Command example:

semanage port -a -t reserved_port_t -p udp 1234

This command will produce the following file in the default <policy_name>
policy store and then activate the policy:
/etc/selinux/<policy_name>/modules/active/ports.local:

Page 234
The SELinux Notebook

# This file is auto-generated by libsemanage
# Do not edit directly.

portcon udp 1234 system_u:object_r:reserved_port_t:s0

4.17 Modular Policy Support Statements
This section contains language statements used to support policy modules.

4.17.1 module
This statement is mandatory for loadable modules (non-base) and must be the first
line of any module policy source file. The identifier should not conflict with other
module names within the overall policy, otherwise it will over-write an existing
module when loaded via the semodule command. The semodule -l command
can be used to list all active modules within the policy.

The statement definition is:
module module_name version_number;

Where:
module The module keyword.
module_name The module name.
version_number The module version number in M.m.m format
(where M = major version number and m = minor
version numbers).
The statement is valid in:
Monolithic Policy Base Policy Module Policy
No No Yes

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
# Using the module statement to define a loadable module called
# bind with a version 1.0.0:

module bind 1.8.0;

4.17.2 require
The require statement is used for two reasons:

Page 235
The SELinux Notebook

1. Within loadable module policy source files to indicate what policy
components are required from an external source file (i.e. they are not
explicitly defined in this module but elsewhere). The examples below show
the usage.
2. Within a base policy source file, but only if preceded by the optional
Statement to indicate what policy components are required from an external
source file (i.e. they are not explicitly defined in the base policy but
elsewhere). The examples below show the usage.

The statement definition is:
require { rule_list }

Where:
require The require keyword.
require_list One or more specific statement keywords with their
required identifiers in a semi-colon (;) separated list
enclosed within braces ({}).
The valid statement keywords are:
• role, type, attribute, user, bool,
sensitivity and category. The keyword is
followed by one or more identifiers in a comma (,)
separated list, with the last entry being terminated
with a semi-colon (;).
• class. The class keyword is followed by a single
object class identifier and one or more permissions.
Multiple permissions consist of a space separated
list enclosed within braces ({}). The list is then
terminated with a semi-colon (;).
The examples below show these in detail.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
No Yes - But only if Yes
proceeded by the
optional Statement.

Conditional Policy (if) Statement optional Statement require Statement
Yes - But only if proceeded by Yes No
the optional Statement.

Examples:
# A series of require statements showing various entries:

require {

Page 236
The SELinux Notebook

role system_r;
class security { compute_av compute_create compute_member
check_context load_policy compute_relabel compute_user
setenforce setbool setsecparam setcheckreqprot };
class capability2 { mac_override mac_admin };
}

#
require {
attribute direct_run_init, direct_init, direct_init_entry;
type initrc_t;
role system_r;
attribute daemon;
}

#
require {
type nscd_t, nscd_var_run_t;
class nscd { getserv getpwd getgrp gethost shmempwd shmemgrp
shmemhost shmemserv };
}

4.17.3 optional
The optional statement is used to indicate what policy statements may or may not
be present in the final compiled policy. The statements will be included in the policy
only if all statements within the optional { rule list } can be expanded
successfully, this is generally achieved by using a require Statement at the start of
the list.

The statement definition is:
optional { rule_list } [ else { rule_list } ]

Where:
optional The optional keyword.
rule_list One or more statements enclosed within braces
({}). The list of valid statements is given in
Table 16.
else An optional else keyword.
rule_list As the rule_list above.

The statement is valid in:

Page 237
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
No Yes Yes

Conditional Policy (if) Statement optional Statement require Statement
Yes Yes Yes

Examples:
# Use of optional block in a base policy source file.

optional {
require {
type unconfined_t;
} # end require

allow acct_t unconfined_t:fd use;
} # end optional

# Use of optional / else blocks in a base policy source file.

optional {
require {
type ping_t, ping_exec_t;
} # end require

allow dhcpc_t ping_exec_t:file { getattr read execute };
.....
require {
type netutils_t, netutils_exec_t;
} # end require
allow dhcpc_t netutils_exec_t:file { getattr read execute };
.....
type_transition dhcpc_t netutils_exec_t:process netutils_t;
...
} else {
allow dhcpc_t self:capability setuid;
.....
} # end optional

4.18 Xen Statements
Xen policy supports additional policy language statements: iomemcon,
ioportcon, pcidevicecon and pirqcon that are discussed in the sections that
follow.
To compile these additional statements using semodule(8), ensure that the
semanage.conf(5) file has the policy-target=xen entry.

4.18.1 iomemcon
The sid statement declares the actual SID identifier and is defined at the start of a
policy source file.

Page 238
The SELinux Notebook

The statement definition is:
iomemcon addr context;

Where:
iomemcon The iomemcon keyword.
addr The memory address to apply the context. This may also be a
range that consists of a start and end address separated by a
hypen (-).
context The security context to be applied.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
iomemcon 0xfebd9 system_u:object_r:nicP_t;

iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t;

4.18.2 ioportcon
The sid statement declares the actual SID identifier and is defined at the start of a
policy source file.

The statement definition is:
ioportcon port context;

Where:
ioportcon The ioportcon keyword.
port The port to apply the context. This may also be a range that
consists of a start and end port number separated by a hypen
(-).
context The security context to be applied.

The statement is valid in:

Page 239
The SELinux Notebook

Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
ioportcon 0xeac0 system_u:object_r:nicP_t;

ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t;

4.18.3 pcidevicecon
The sid statement declares the actual SID identifier and is defined at the start of a
policy source file.

The statement definition is:
pcidevicecon pci_id context;

Where:
pcidevicecon The pcidevicecon keyword.
pci_id The PCI indentifer.
context The security context to be applied.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
pcidevicecon 0xc800 system_u:object_r:nicP_t;

4.18.4 pirqcon
The sid statement declares the actual SID identifier and is defined at the start of a
policy source file.

The statement definition is:
pirqcon irq context;

Page 240
The SELinux Notebook

Where:
pirqcon The pirqcon keyword.
irq The interrupt request number.
context The security context to be applied.

The statement is valid in:
Monolithic Policy Base Policy Module Policy
Yes Yes No

Conditional Policy (if) Statement optional Statement require Statement
No No No

Example:
pirqcon 33 system_u:object_r:nicP_t;

Page 241
The SELinux Notebook

5. The Reference Policy

5.1 Introduction
The Reference Policy is now the standard policy source used to build GNU/Linux
SELinux policies. This provides a single source tree with supporting documentation
that can be used to build policies for different purposes such as: confining important
daemons, supporting MLS / MCS type policies and locking down systems so that all
processes are under SELinux control.
This section details how the Reference Policy is:
1. Constructed and types of policy builds supported.
2. Adding new modules to the build.
3. Installation as a full Reference Policy source or as Header files.
4. Impact of the migration process being used to convert compiled module files
(*.pp) to CIL.
5. Modifying the configuration files to build new policies.
6. Explain the support macros.

5.2 Reference Policy Overview
Strictly speaking the 'Reference Policy' should refer to the policy taken from the
master repository or the latest released version (see
https://github.com/TresysTechnology/refpolicy/wiki). This is because most Linux
distributors take a released version and then tailor it to their specific requirements, for
example the Fedora distribution is built from the standard Reference Policy but
modified and distributed by Red Hat as a source RPM, for example:
selinux-policy-3.12.1-179.fc20.src.rpm48
The master Reference Policy repository can be checked out using the following:
# Check out the core policy:
git clone https://github.com/TresysTechnology/refpolicy.git
cd refpolicy
# Add the contibuted modules (policy/modules/contrib)
git submodule init
git submodule update

Figure 5.1 shows the layout of the reference policy source tree, that once installed
would be located at:
/etc/selinux/<NAME>/src/policy
Where the <NAME> entry is taken from the build.conf file as discussed in the
Reference Policy Build Options - build.conf section. The Installing and Building
the Reference Policy Source section explains a simple build plus information on
building the Fedora source.

48
These RPMs can be obtained from http://koji.fedoraproject.org.

Page 242
The SELinux Notebook

Reference Policy Source Tree
SELinux Policy
config
./ appconfig-mcs --------- Policy Store -------------
Application
appconfig-mls specific /etc/selinux/<NAME>/modules:
appconfig- configuration
semanage.read.LOCK
.te, .if and .fc semanage.trans.LOCK
standard files admin /etc/selinux/<NAME>/modules/active:
module files
local.users base.pp
build.conf commit_num
file_contexts
doc file_contexts.homedirs
html template
templates files .te, .if and .fc
file_contexts.template
apps homedir_template
Makefile example files + module files netfilter_contexts
dtd seusers.final
users_extra
/etc/selinux/<NAME>/modules/active/modules:
man Reference amavis.pp
kernel .te, .if and .fc
man Policy man amtu.pp
Rules. pages module files ...
ru zabbix.pp
modular
policy --- Policy Configuration Files -----
flask config
flask files .te, .if and .fc /etc/selinux/<NAME>/contexts:
Rules. roles
module files dbus_contexts
monolithic modules netfilter_contexts
/etc/selinux/<NAME>/contexts/files:
file_contexts
file_contexts.homedirs
support Reference /etc/selinux/<NAME>/policy:
services .te, .if and .fc
+ Policy macros module files
policy.23
Policy ------------------------------------
configuration SELinux Configuration Files
files
/etc/selinux/config
system .te, .if and .fc /etc/selinux/semanage.conf
support module files /etc/selinux/restorecond.conf
/etc/sestatus
Policy support
/etc/selinux/<NAME>/setrans.conf
scripts

Figure 5.1: The Reference Policy Source Tree - When building a modular policy, files are added to the policy store. For monolithic builds the
policy store is not used.

Page 243
The SELinux Notebook

The Reference Policy can be used to build two different formats of policy
infrastructure:
1. Loadable Module Policy - A policy that has a base module for core services
and has the ability to load / unload modules to support applications as required
49
. This is now the standard used by GNU / Linux distributions.
2. Monolithic Policy - A policy that has all the required policy information in a
single base policy and does not require the services of the module
infrastructure (semanage(8) or semodule(8)). These are more suitable
for embedded or minimal systems.
Each of the policy types are built using module files that define the specific rules
required by the policy as detailed in the Reference Policy Module Files section. Note
that the monolithic policy is built using the the same module files by forming a single
'base' source file.
The Reference Policy relies heavily on the m4(1) macro processor as the majority of
supporting services are m4 macros.
There are tools such as SLIDE (SELinux integrated development environment) that
can be used to make the task of policy development and testing easier when using the
Reference Policy source or headers. SLIDE is an Eclipse plugin and details can be
found at:
http://oss.tresys.com/projects/slide

5.2.1 Distributing Policies
It is possible to distribute the Reference Policy in two forms:
1. As source code that is then used to build policies. This is not the general way
policies are distributed as it contains the complete source that most
administrators do not need. The Reference Policy Source section describes the
source and the Installing and Building the Reference Policy Source section
describes how to install the source and build a policy.
2. As 'Policy Headers'. This is the most common way to distribute the Reference
Policy. Basically, the modules that make up 'the distribution' are pre-built and
then linked to form a base and optional modules. The 'headers' that make-up
the policy are then distributed along with makefiles and documentation. A
policy writer can then build policy using the core modules supported by the
distribution, and using development tools they can add their own policy
modules. The Reference Policy Headers section describes how these are
installed and used to build modules.
The policy header files for F-20 are distributed in a number of rpms as
follows:
selinux-policy-3.12.1-179.fc20.noarch.rpm - Contains
the SELinux /etc/selinux/config file, man pages and the 'Policy
Header' development environment that is located at
/usr/share/selinux/devel

49
These can be installed by system administrators as required. The dynamic loading / unloading of
policies as applications are loaded is not yet supported.

Page 244
The SELinux Notebook

selinux-policy-doc-3.12.1-179.fc20.noarch.rpm -
Contains the html policy documentation that is located at
/usr/share/doc/selinux-policy/html
selinux-policy-minimum-3.12.1-179.fc20.noarch.rpm
selinux-policy-mls-3.12.1-179.fc20.noarch.rpm
selinux-policy-targeted-3.12.1-179.fc20.noarch.rpm
These three rpms contain policy configuration files and the packaged
policy modules (*.pp). They will be used to form the particular policy
type in /usr/share/selinux/<NAME>, the install process will then
install the policy in the appropriate /etc/selinux/<NAME> directory.
Normally only one policy would be installed and active, however for
development purposes all can be installed.
selinux-policy-sandbox-3.12.1-179.fc20.noarch.rpm
Contains the sandbox module for use by the policycoreutils-
sandbox package. This will be installed as a module for one of the three
main policies described above.

5.2.2 Policy Functionality
As can be seen from the policies distributed with F-20 above, they can be classified
by the name of the functionality they support (taken from the NAME entry of the
build.conf as shown in Table 19), for example the Fedora policies support:
minimum - MCS policy that supports a minimal set of confined daemons within
their own domains. The remainder run in the unconfined_t space.
targeted - MCS policy that supports a greater number of confined daemons
and can also confine other areas and users (this also supports the older 'strict'
policy).
mls - MLS policy for server based systems.

5.2.3 Reference Policy Module Files
The reference policy modules are constructed using a mixture of policy language
statements, support macros and access interface calls using three principle types of
source file:
1. A private policy file that contains statements required to enforce policy on the
specific GNU / Linux service being defined within the module. These files are
named <module_name>.te.
For example the ada.te file shown below has two statements:
a) one to state that the ada_t process has permission to write to the
stack and memory allocated to a file.
b) one that states that if the unconfined module is loaded, then allow
the ada_t domain unconfined access. Note that if the flow of this
statement is followed it will be seen that many more interfaces and
macros are called to build the final raw SELinux language statements.

Page 245
The SELinux Notebook

An expanded module source is shown in the Module Expansion
Process section.
2. An external interface file that defines the services available to other modules.
These files are named <module_name>.if.
For example the ada.if file shown below has two interfaces defined for
other modules to call (see also Figure 5.2 that shows a screen shot of the
documentation that can be automatically generated):
a) ada_domtrans - that allows another module (running in domain
$1) to run the ada application in the ada_t domain.
b) ada_run - that allows another module to run the ada application in
the ada_t domain (via the ada_domtrans interface), then
associate the ada_t domain to the caller defined role ($2) and
terminal ($3).
Provided of course that the caller domain has permission.
It should be noted that there are two types of interface specification:
Access Interfaces - These are the most common and define interfaces that
.te modules can call as described in the ada examples. They are
generated by the interface macro as detailed in the the interface
Macro section.
Template Interfaces - These are required whenever a module is required
in different domains and allows the type(s) to be redefined by adding a
prefix supplied by the calling module. The basic idea is to set up an
application in a domain that is suitable for the defined SELinux user and
role to access but not others. These are generated by the template
macro as detailed in the template Macro section that also explains the
openoffice.if template.
3. A file labeling file that defines the labels to be added to files for the specified
module. These files are named <module_name>.fc. The build process will
amalgamate all the .fc files and finally form the file_contexts file that
will be used to label the filesystem.
For example the ada.fc file shown below requires that the specified files are
all labeled system_u:object_r:ada_exec_t:s0.
The <module_name> must be unique within the reference policy source tree and
should reflect the specific GNU / Linux service being enforced by the policy.
The module files are constructed using a mixture of:
1. Policy language statements as defined in the SELinux Policy Language
section.
2. Reference Policy macros that are defined in the Reference Policy Macros
section.
3. External interface calls defined within other modules (.te and .if only).
An example of each file taken from the ada module is as follows:

Page 246
The SELinux Notebook

ada.te file contents:
policy_module(ada, 1.4.1)

########################################
#
# Declarations
#

attribute_role ada_roles;
roleattribute system_r ada_roles;

type ada_t;
type ada_exec_t;
application_domain(ada_t, ada_exec_t)
role ada_roles types ada_t;

########################################
#
# Local policy
#

allow ada_t self:process { execstack execmem };

userdom_use_inherited_user_terminals(ada_t)

optional_policy(`
unconfined_domain(ada_t)
')

ada.if file contents:
## <summary>GNAT Ada95 compiler.</summary>

########################################
## <summary>
## Execute the ada program in the ada domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
## </param>
#
interface(`ada_domtrans',`
gen_require(`
type ada_t, ada_exec_t;
')

corecmd_search_bin($1)
domtrans_pattern($1, ada_exec_t, ada_t)
')

########################################
## <summary>
## Execute ada in the ada domain, and
## allow the specified role the ada domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
## </param>
## <param name="role">
## <summary>
## Role allowed access.
## </summary>
## </param>
#
interface(`ada_run',`
gen_require(`
attribute_role ada_roles;
')

Page 247
The SELinux Notebook

ada_domtrans($1)
roleattribute $2 ada_roles;
')

ada.fc file contents:
/usr/bin/gnatbind -- gen_context(system_u:object_r:ada_exec_t,s0)
/usr/bin/gnatls -- gen_context(system_u:object_r:ada_exec_t,s0)
/usr/bin/gnatmake -- gen_context(system_u:object_r:ada_exec_t,s0)

/usr/libexec/gcc(/.*)?/gnat1 -- gen_context(system_u:object_r:ada_exec_t,s0)

5.2.4 Reference Policy Documentation
One of the advantages of the reference policy is that it is possible to automatically
generate documentation as a part of the build process. This documentation is defined
in XML and generated as HTML files suitable for viewing via a browser.
The documentation for Fedora can be viewed in a browser by
file:///usr/share/doc/selinux-policy/html/index.html once
the selinux-policy-doc rpm has been installed.
The documentation for the Reference Policy source will be available at
<location>/src/policy/doc/html once make html has been executed
(the <location> is the location of the installed source after make install-
src has been executed as described in the Installing The Reference Policy Source
section). The Reference Policy documentation may also be available at a default
location of /usr/share/doc/refpolicy-VERSION/html if make
install-doc has been executed (where VERSION is the entry from the source
VERSION file.
Figure 5.2 shows an example screen shot of the documentation produced for the ada
module interfaces.

Figure 5.2: Example Documentation Screen Shot

Page 248
The SELinux Notebook

5.3 Reference Policy Source
This section explains the source layout and configuration files, with the actual
installation and building covered in the Installing and Building the Reference Policy
Source section.
The source has a README file containing information on the configuration and
installation processes that has been used within this section (and updated with the
authors comments as necessary). There is also a VERSION file that contains the
Reference Policy release date which can be used to obtain the original source from the
repository located at:
https://github.com/TresysTechnology/refpolicy/wiki

5.3.1 Source Layout
Figure 5.1 shows the layout of the reference policy source tree, that once installed
would be located at:
/etc/selinux/<NAME>/src/policy
The following sections detail the source contents:
• Reference Policy Files and Directories - Describes the files and their location.
• Source Configuration Files - Details the contents of the build.conf and
modules.conf configuration files.
• Source Installation and Build Make Options - Describes the make targets.
• Modular Policy Build Process - Describes how the various source files are
linked together to form a base policy module (base.conf) during the build
process.
The Installing and Building the Reference Policy Source section then describes how
the initial source is installed and configured to allow a policy to be built.

5.3.2 Reference Policy Files and Directories
Table 18 shows the major files and their directories with a description of each taken
from the README file. All directories are relative to the root of the Reference Policy
source directory ./policy.
Two of these configuration files (build.conf and modules.conf) are further
detailed in the Source Configuration Files section as they define how the policy will
be built.
During the build process, a file is generated in the ./policy directory called either
policy.conf or base.conf depending whether a monolithic or modular policy
is being built. This file is explained in the Modular Policy Build Structure section.
File / Directory Name Comments
Makefile General rules for building the policy.
Rules.modular Makefile rules specific to building loadable module
policies.
Rules.monolithic Makefile rules specific to building monolithic policies.

Page 249
The SELinux Notebook

File / Directory Name Comments
build.conf Options which influence the building of the policy, such as
the policy type and distribution. This file is described in the
Reference Policy Build Options - build.conf section.
config/appconfig-<type> Application configuration files for all configurations of the
Reference Policy where <type> is taken from the
build.conf TYPE entry that are currently: standard,
MLS and MCS). These files are used by SELinux-aware
programs and described in the SELinux Configuration Files
section.
config/file_contexts.subs_dist Used to configure file context aliases (see the
contexts/files/file_contexts.subs and file_contexts.subs_dist
File section).
config/local.users The file read by load policy for adding SELinux users to the
policy on the fly.
Note that this file is not used in the modular policy build.
doc/html/* When make html has been executed, contains the in-policy
XML documentation, presented in web page form .
doc/policy.dtd The doc/policy.xml file is validated against this DTD.
doc/policy.xml This file is generated/updated by the conf and html make
targets. It contains the complete XML documentation
included in the policy.
doc/templates/* Templates used for documentation web pages.
man/* Various man pages for modules (ftp, http etc.)
support/* Tools used in the build process.
policy/flask/initial_sids This file has declarations for each initial SID.
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/flask/security_classes This file has declarations for each security class.
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/flask/access_vectors This file defines the common permissions and class specific
permissions. The file is described in the Modular Policy
Build Structure section.
policy/modules/* Each directory represents a layer in Reference Policy. All of
the modules are contained in one of these layers. The
contrib modules are supplied externally to the Reference
Policy, then linked into the build.
The files present in each directory are:
metadata.xml - describes the layer.
<module_name>.te, .if & .fc - contains policy
source as described in the Reference Policy Module Files
section.
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/support/* Reference Policy support macros. These are described in the
Reference Policy Macros section.
policy/booleans.conf This file is generated/updated by the conf make target. It
contains the booleans in the policy, and their default values.
If tunables are implemented as booleans, tunables
will also be included. This file will be installed as the

Page 250
The SELinux Notebook

File / Directory Name Comments
/etc/selinux/NAME/booleans file (note that this is
not true for any system that implements the modular policy -
see the Booleans, Global Booleans and Tunable Booleans
section).
policy/constraints This file defines constraints on permissions in the form of
boolean expressions that must be satisfied in order for
specified permissions to be granted. These constraints are
used to further refine the type enforcement rules and the role
allow rules. Typically, these constraints are used to restrict
changes in user identity or role to certain domains.
(Note that this file does not contain the MLS / MCS
constraints as they are in the mls and mcs files described
below).
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/context_defaults This would contain any specific default_user,
default_role, default_type and/or
default_range rules required by the policy.
policy/global_booleans This file defines all booleans that have a global scope, their
default value, and documentation. See the Booleans, Global
Booleans and Tunable Booleans section.
policy/global_tunables This file defines all tunables that have a global scope, their
default value, and documentation. See the Booleans, Global
Booleans and Tunable Booleans section.
policy/mcs This contains information used to generate the
sensitivity, category, level and
mlsconstraint statements used to define the MCS
configuration.
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/mls This contains information used to generate the
sensitivity, category, level and
mlsconstraint statements used to define the MLS
configuration.
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/modules.conf This file contains a listing of available modules, and how
they will be used when building Reference Policy.
To prevent a module from being used, set the module to
"off". For monolithic policies, modules set to "base" and
"module" will be included in the policy. For modular
policies, modules set to "base" will be included in the base
module; those set to "module" will be compiled as individual
loadable modules.
This file is described in the Reference Policy Build Options -
modules.conf section.
policy/policy_capabilities This file defines the policy capabilities that can be enabled in
the policy.
The file usage in policy generation is described in the
Modular Policy Build Structure section.
policy/users This file defines the users included in the policy.
The file usage in policy generation is described in the

Page 251
The SELinux Notebook

File / Directory Name Comments
Modular Policy Build Structure section.
securetty_types These files are not part of the standard Reference Policy
setrans.conf distribution but are added by Fedora source updates.

Table 18: The Reference Policy Files and Directories

5.3.3 Source Configuration Files
There are two major configuration files (build.conf and modules.conf) that
define the policy to be built and are detailed in this section.

5.3.3.1 Reference Policy Build Options - build.conf
This file defines the policy type to be built that will influence its name and where the
source will be located once it is finally installed. An example file content is shown in
the Installing and Building the Reference Policy Source section where it is used to
install and then build the policy.
Table 19 explains the fields that can be defined within this file, however there are a
number of m4 macro parameters that are set up when this file is read by the build
process makefiles. These macro definitions are shown in Table 20 and are also used
within the module source files to control how the policy is built with examples shown
in the ifdef / ifndef Parameters section.
Option Type Comments
OUTPUT_POLICY Integer Set the version of the policy created when building a
monolithic policy. This option has no effect on modular
policy.
TYPE String Available options are standard (uses RBAC/TE), mcs
(uses RBAC/TE/MCS) and mls (uses RBAC/TE/MLS).
The mls and mcs options control the enable_mls, and
enable_mcs policy blocks.
NAME String Sets the name of the policy; the NAME is used when
installing files to e.g., /etc/selinux/NAME and
/usr/share/selinux/NAME. If not set, the policy
type field (TYPE) is used.
DISTRO String Enable distribution-specific policy. Available options are
(optional) redhat, rhel4, gentoo, debian, and suse. This
option controls distro_redhat, distro_rhel4,
distro_suse policy blocks.
UNK_PERMS String Set the kernel behaviour for handling of permissions
defined in the kernel but missing from the policy. The
permissions can either be allowed, denied, or the policy
loading can be rejected. See the SELinux Filesystem for
more details. If not set, then it will be taken from the
semanage.conf file.
DIRECT_INITRC Boolean If 'y' sysadm will be allowed to directly run init scripts,
(y|n) instead of requiring the run_init tool. This is a build
option instead of a tunable since role transitions do not work
in conditional policy. This option controls
direct_sysadm_daemon policy blocks.

Page 252
The SELinux Notebook

Option Type Comments
MONOLITHIC Boolean If 'y' a monolithic policy is built, otherwise a modular
(y|n) policy is built.
UBAC Boolean If 'y' User Based Access Control policy is built. The default
(y|n) for Red Hat is 'n'. These are defined as constraints in the
policy/constraints file. Note Version 1 of the
Reference Policy did not have this entry and defaulted to
Role Based Access Control.
The UBAC option is described at
http://blog.siphos.be/2011/05/selinux-user-based-access-
control/.
CUSTOM_BUILDOPT String Space separated list of custom build options.
MLS_SENS Integer Set the number of sensitivities in the MLS policy.
Ignored on standard and MCS policies.
MLS_CATS Integer Set the number of categories in the MLS policy.
Ignored on standard and MCS policies.
MCS_CATS Integer Set the number of categories in the MCS policy.
Ignored on standard and MLS policies.
QUIET Boolean If 'y' the build system will only display status messages and
(y|n) error messages. This option has no effect on policy.

Table 19: build.conf Entries

m4 Parameter Name in From build.conf Comments
Makefile entry
enable_mls TYPE Set if MLS policy build enabled.
enable_mcs TYPE Set if MCS policy build enabled.
enable_ubac UBAC Set if UBAC set to 'y'.
mls_num_sens MLS_SENS The number of MLS sensitivities
configured.
mls_num_cats MLS_CATS The number of MLS categories configured.
mcs_num_cats MCS_CATS The number of MCS categories configured.
distro_$(DISTRO) DISTRO The distro name or blank.
direct_sysadm_daemon DIRECT_INITRC If DIRECT_INITRC entry set to 'y'.
hide_broken_symtoms This is set up in the Makefile and can be
used in modules to hide errors with
dontaudit rules (or even allow rules).

Table 20: m4 parameters set at build time - These have been extracted from the
Reference Policy Makefile file.

5.3.3.2 Reference Policy Build Options - policy/modules.conf
This file controls what modules are built within the policy with example entries as
follows:
# Layer: kernel
# Module: kernel
# Required in base
#

Page 253
The SELinux Notebook

# Policy for kernel threads, proc filesystem,and unlabeled processes and
# objects.
#
kernel = base

# Module: amanda
#
# Automated backup program.
#
amanda = module

# Layer: admin
# Module: ddcprobe
#
# ddcprobe retrieves monitor and graphics card information
#
ddcprobe = off

As can be seen the only active line (those without comments50) is:
<module_name> = base | module | off

Where:
module_name The name of the module to be included within the build.
base The module will be in the base module for a modular policy
build (build.conf entry MONOLITHIC = n).
module The module will be built as a loadable module for a modular
policy build. If a monolithic policy is being built
(build.conf entry MONOLITHIC = y), then this module
will be built into the base module.
off The module will not be included in any build.

Generally it is up to the policy distributor to decide which modules are in the base and
those that are loadable, however there are some modules that MUST be in the base
module. To highlight this there is a special entry at the start of the modules interface
file (.if) that has the entry <required val="true"> as shown below (taken
from the kernel.if file):

## <summary>
## Policy for kernel threads, proc filesystem,
## and unlabeled processes and objects.
## </summary>
## <required val="true">
## This module has initial SIDs.
## </required>

The modules.conf file will also reflect that a module is required in the base by
adding a comment 'Required in base' when the make conf target is executed
(as all the .if files are checked during this process and the modules.conf file
updated).

50
The comments are also important as they form part of the documentation when it is generated by
the make html target.

Page 254
The SELinux Notebook

# Layer: kernel
# Module: kernel
# Required in base
#
# Policy for kernel threads, proc filesystem,and unlabeled processes and objects.
#
kernel = base

Theose marked as required in base are shown in Table 21 (note that F-20 and
the standard reference policy are different)
Layer Module Name Comments
kernel corecommands Core policy for shells, and generic programs in:
/bin, /sbin, /usr/bin, and /usr/sbin.
The .fc file sets up the labels for these items.
All the interface calls start with
'corecmd_'.
kernel corenetwork Policy controlling access to network objects and also contains the
initial SIDs for these.
The .if file is large and automatically generated. All the
interface calls start with 'corenet_'.
kernel devices This module creates the device node concept and provides the
policy for many of the device files. Notable exceptions are the
mass storage and terminal devices that are covered by other
modules (that is a char or block device file, usually in /dev). All
types that are used to label device nodes should use the dev_node
macro.
Additionally this module controls access to three things:
1. the device directories containing device nodes.
2. device nodes as a group
3. individual access to specific device nodes covered by
this module.
All the interface calls start with 'dev_'.
kernel domain Contains the core policy for forming and managing domains.
All the interface calls start with 'domain_'.
kernel files This module contains basic filesystem types and interfaces and
includes:
1. The concept of different file types including basic files,
mount points, tmp files, etc.
2. Access to groups of files and all files.
3. Types and interfaces for the basic filesystem layout (/,
/etc, /tmp, /usr, etc.).
4. Contains the file initial SID.
All the interface calls start with 'files_'.
kernel filesystem Contains the policy for filesystems and the initial SID.
All the interface calls start with 'fs_'.
kernel kernel Contains the policy for kernel threads, proc filesystem, and
unlabeled processes and objects. This module has initial SIDs.
All the interface calls start with 'kernel_'.
kernel mcs Policy for Multicategory security. The .te file only contains
attributes used in MCS policy.
All the interface calls start with 'mcs_'.
kernel mls Policy for Multilevel security. The .te file only contains

Page 255
The SELinux Notebook

Layer Module Name Comments
attributes used in MLS policy.
All the interface calls start with 'mls_'.
kernel selinux Contains the policy for the kernel SELinux security interface
(selinuxfs).
All the interface calls start with 'selinux_'.
kernel terminal Contains the policy for terminals.
All the interface calls start with 'term_'.
kernel ubac Disabled by Fedora but enabled on standard Ref Policy.
Support user-based access control.
system application Enabled by Fedora but not standard Ref Policy.
Defines attributes and interfaces for all user apps.
system setrans Enabled by Fedora but not standard Ref Policy.
Support for mcstransd(8).

Table 21: Mandatory modules.conf Entries

5.3.3.2.1 Building the modules.conf File
The file can be created by an editor, however it is generally built initially by make
conf that will add any additional modules to the file. The file can then be edited to
configure the required modules as base, module or off.
As will be seen in the Installing and Building the Reference Policy Source section, the
Red Hat reference policy source comes with a number of pre-configured files that are
used to produce the required policy including multiple versions of the
modules.conf file.

5.3.4 Source Installation and Build Make Options
This section explains the various make options available that have been taken from
the README file. Table 22 describes the general make targets, Table 23 describes the
modular policy make targets and Table 24 describes the monolithic policy make
targets.
Make Target Comments
install-src Install the policy sources into /etc/selinux/NAME/src/policy,
where NAME is defined in the build.conf file. If it is not defined,
then TYPE is used instead. If a build.conf does not have the information,
then the Makefile will default to the current entry in the
/etc/selinux/config file or default to refpolicy. A pre-
existing source policy will be moved to
/etc/selinux/NAME/src/policy.bak.
conf Regenerate policy.xml, and update/create modules.conf and
booleans.conf. This should be done after adding or removing
modules, or after running the bare target. If the configuration files exist,
their settings will be preserved. This must be run on policy sources that
are checked out from the CVS repository before they can be used.
Note that if make bare has been executed before this make target, or it
is a first build, then the modules/kernel/corenetwork.??.in
files will be used to generate the corenetwork.te and
corenetwork.if module files. These *.in files may be edited to

Page 256
The SELinux Notebook

Make Target Comments
configure network ports etc. (see the # network_node examples
entries).
clean Delete all temporary files, compiled policies, and file_contexts.
Configuration files are left intact.
bare Do the clean make target and also delete configuration files, web page
documentation, and policy.xml.
html Regenerate policy.xml and create web page documentation in the
doc/html directory.
install-appconfig Installs the appropriate SELinux-aware configuration files.

Table 22: General Build Make Targets

Make Target Comments
base Compile and package the base module. This is the default target for
modular policies.
modules Compile and package all Reference Policy modules configured to be built as
loadable modules.
MODULENAME.pp Compile and package the MODULENAME Reference Policy module.
all Compile and package the base module and all Reference Policy modules
configured to be built as loadable modules.
install Compile, package, and install the base module and Reference Policy
modules configured to be built as loadable modules.
load Compile, package, and install the base module and Reference Policy
modules configured to be built as loadable modules, then insert them into
the module store.
validate Validate if the configured modules can successfully link and expand.
install-headers Install the policy headers into /usr/share/selinux/NAME. The
headers are sufficient for building a policy module locally, without requiring
the complete Reference Policy sources. The build.conf settings for this
policy configuration should be set before using this target.
install-docs Build and install the documentation and example module source with
Makefile. The default location is /usr/share/doc/refpolicy-
VERSION, where the version is the value in the VERSION file.

Table 23: Modular Policy Build Make Targets

Make Target Comments
policy Compile a policy locally for development and testing. This is the default
target for monolithic policies.
install Compile and install the policy and file contexts.
load Compile and install the policy and file contexts, then load the policy.
enableaudit Remove all dontaudit rules from policy.conf.
relabel Relabel the filesystem.
checklabels Check the labels on the filesystem, and report when a file would be
relabeled, but do not change its label.
restorelabels Relabel the filesystem and report each file that is relabeled.

Page 257
The SELinux Notebook

Table 24: Monolithic Policy Build Make Targets

5.3.5 Booleans, Global Booleans and Tunable Booleans
The three files booleans.conf, global_booleans and global_tunables
are built and used as follows:
booleans.conf This file is generated / updated by make conf, and
contains all the booleans in the policy with their
default values. If tunable and global booleans are
implemented then these are also included.
This file can also be delivered as a part of the Fedora
reference policy source as shown in the Installing and
Building the Reference Policy Source section. This is
generally because other default values are used for
booleans and not those defined within the modules
themselves (i.e. distribution specific booleans). When
the make install is executed, this file will be used to set
the default values.
Note that if booleans are updated locally the policy
store will contain a booleans.local file.
In SELinux enabled systems that support the policy
store features (modular policies) this file is not
installed as /etc/selinux/NAME/booleans.
global_booleans These are booleans that have been defined in the
global_tunables file using the gen_bool
macro. They are normally booleans for managing the
overall policy and currently consist of the following
(where the default values are false):
secure_mode
global_tunables These are booleans that have been defined in module
files using the gen_tunable macro and added to the
global_tunables file by make conf. The
tunable_policy macros are defined in each
module where policy statements or interface calls are
required. They are booleans for managing specific
areas of policy that are global in scope. An example is
allow_execstack that will allow all processes
running in unconfined_t to make their stacks
executable.

5.3.6 Modular Policy Build Structure
This section explains the way a modular policy is constructed, this does not really
need to be known but is used to show the files used that can then be investigated if
required.

Page 258
The SELinux Notebook

When make all or make load or make install are executed the
build.conf and modules.conf files are used to define the policy name and
what modules will be built in the base and those as individual loadable modules.
Basically the source modules (.te, .if and .fc) and core flask files are rebuilt in
the tmp directory where the reference policy macros51 in the source modules will be
expanded to form actual policy language statements as described in the SELinux
Policy Language section. Figure 5.3 shows these temporary files that are used to form
the base.conf52 file during policy generation.
The base.conf file will consist of language statements taken from the module
defined as base in the modules.conf file along with the constraints, users etc.
that are required to build a complete policy.
The individual loadable modules are built in much the same way as shown in Figure
5.4.
Base Policy Component Description Policy Source File Name ./policy/tmp
(relative to ./policy/policy) File Name
The object classes supported by the flask/security_classes pre_te_files.conf
kernel.
The initial SIDs supported by the kernel. flask/initial_sids

The object class permissions supported flask/access_vectors
by the kernel.
This is either the expanded mls or mcs mls or mcs
file depending on the type of policy
being built.
These are the policy capabilities that can policy_capabilities
be configured / enabled to support the
policy.
This area contains all the attribute, modules/*/*.te all_attrs_types.conf
modules/*/*.if
bool, type and typealias
statements extracted from the *.te and
*.if files that form the base module.
Contains the global and tunable bools global_bools.conf global_bools.conf
extracted from the conf files. global_tunables.conf

Contains the rules extracted from each of base modules only_te_rules.conf
the modules .te and .if files defined
in the modules.conf file as 'base'.
Contains the expanded users from the users all_post.conf
users file.
Contains the expanded constraints from constraints
the constraints file.
Contains the default SID labeling modules/*/*.te
extracted from the *.te files.
Contains the fs_use_xattr, modules/*/*.te
modules/*/*.if
fs_use_task, fs_use_trans and
genfscon statements extracted from
each of the modules .te and .if files
defined in the modules.conf file as
51
These are explained in the Reference Policy Macros section.
52
The base.conf gets built for modular policies and a policy.conf file gets built for a
monolithic policy.

Page 259
The SELinux Notebook

Base Policy Component Description Policy Source File Name ./policy/tmp
(relative to ./policy/policy) File Name
'base'.
Contains the netifcon, nodecon and modules/*/*.te
modules/*/*.if
portcon statements extracted from
each of the modules .te and .if files
defined in the modules.conf file as
'base'.
Contains the expanded file context file modules/*/*.fc base.fc.tmp
entries extracted from the *.fc files
defined in the modules.conf file as
'base'.
Expanded seusers file. seusers seusers

These are the commands used to compile, link and load the base policy module:
checkmodule base.conf -o tmp/base.mod
semodule_package -o base.conf -m base_mod -f base_fc -u users_extra -s tmp/seusers
semodule -s $(NAME) -b base.pp) -i and each module .pp file
The 'NAME' is that defined in the build.conf file.

Figure 5.3: Base Module Build - This shows the temporary build files used to build
the base module 'base.conf' as a part of the 'make' process. Note that the modules
marked as base in modules.conf are built here.

Base Policy Component Description Policy Source File Name ./policy/tmp
(relative to ./policy/policy) File Name
For each module defined as 'module' in modules/*/<module_name>.te <module_name>.tmp
modules/*/<module_name>.if
the modules.conf configuration file,
a source module is produced that has
been extracted from the *.te and *.if
file for that module.
For each module defined as 'module' in tmp/<module_name>.tmp <module_name>.mod
the modules.conf configuration file,
an object module is produced from
executing the checkmodule command
shown below.
For each module defined as 'module' in modules/*/<module_name>.fc base.fc.tmp
the modules.conf configuration file,
an expanded file context file is built from
the <module_name>.fc file.
This command is used to compile each module:
checkmodule tmp/<module_name>.tmp -o tmp/<module_name>.mod

Each module is packaged and loaded with the base module using the following commands:
semodule_package -o base.conf -m base_mod -f base_fc -u users_extra -s tmp/seusers
semodule -s $(NAME) -b base.pp) -i and each module .pp file
The 'NAME' is that defined in the build.conf file.

Figure 5.4: Module Build - This shows the module files and the temporary build files
used to build each module as a part of the 'make' process (i.e. those modules marked
as module in modules.conf).

Page 260
The SELinux Notebook

5.3.7 Creating Additional Layers
One objective of the reference policy is to separate the modules into different layers
reflecting their 'service' (e.g. kernel, system, app etc.). While it can sometimes be
difficult to determine where a particular module should reside, it does help separation,
however because the way the build process works, each module must have a unique
name.
If a new layer is required, then the following will need to be completed:
1. Create a new layer directory ./policy/modules/LAYERNAME that
reflects the layer's purpose.
2. In the ./policy/modules/LAYERNAME directory create a
metadata.xml file. This is an XML file with a summary tag and optional
desc (long description) tag that should describe the purpose of the layer and
will be used as a part of the documentation. An example is as follows:
<summary>ABC modules for the XYZ components.</summary>

5.4 Installing and Building the Reference Policy Source
This section will give a brief overview of how to build the Reference Policy for an
MCS modular build that is similar (but not the same) as the Fedora targeted policy.
The Fedora F-20 version of the targeted policy build is discussed but building without
using the rpm spec file is more complex.

5.4.1 Building Standard Reference Policy
This will run through a simple configuration process and build of a reference policy
similar to the Fedora targeted policy. By convention the source is installed in a central
location and then for each type of policy a copy of the source is installed at
/etc/selinux/<NAME>/src/policy.
The basic steps are:
1. Install master Reference Policy Source and add the contributed modules:
# Check out the core policy:
git clone https://github.com/TresysTechnology/refpolicy.git
cd refpolicy
# Add the contibuted modules (policy/modules/contrib)
git submodule init
git submodule update

2. Edit the build.conf file to reflect the policy to be built, the minimum
required is setting the NAME = entry. An example file with NAME =
refpolicy-test is as follows:
############################################
# Policy build options
#

# Policy version

Page 261
The SELinux Notebook

# By default, checkpolicy will create the highest version policy it supports.
# Setting this will override the version. This only has an effect for
# monolithic policies.
#OUTPUT_POLICY = 18

# Policy Type
# standard, mls, mcs. Note Red Hat always build the MCS Policy Type
# for their 'targeted' version.
TYPE = mcs

# Policy Name
# If set, this will be used as the policy name. Otherwise the policy type
# will be used for the name. This entry is also used by the
# 'make install-src' process to copy the source to the:
# /etc/selinux/<NAME>/src/policy directory.
NAME = refpolicy-test

# Distribution
# Some distributions have portions of policy for programs or configurations
# specific to the distribution. Setting this will enable options for the
# distribution. redhat, gentoo, debian, suse, and rhel4 are current options.
# Fedora users should enable redhat.
DISTRO = redhat

# Unknown Permissions Handling
# The behaviour for handling permissions defined in the kernel but missing
# from the policy. The permissions can either be allowed, denied, or
# the policy loading can be rejected.
# allow, deny, and reject are current options. Fedora use allow for all
# policies except MLS that uses 'deny'.
UNK_PERMS = allow

# Direct admin init
# Setting this will allow sysadm to directly run init scripts, instead of
# requiring run_init. This is a build option, as role transitions do not
# work in conditional policy.
DIRECT_INITRC = n

# Build monolithic policy. Putting y here will build a monolithic policy.
MONOLITHIC = n

# User-based access control (UBAC)
# Enable UBAC for role separations. Note Fedora disables UBAC.
UBAC = n

# Custom build options. This field enables custom build options. Putting
# foo here will enable build option blocks foo. Options should be separated
# by spaces.
CUSTOM_BUILDOPT =

# Number of MLS Sensitivities
# The sensitivities will be s0 to s(MLS_SENS-1). Dominance will be in
# increasing numerical order with s0 being lowest.
MLS_SENS = 16

# Number of MLS Categories.
# The categories will be c0 to c(MLS_CATS-1).
MLS_CATS = 1024

# Number of MCS Categories
# The categories will be c0 to c(MLC_CATS-1).
MCS_CATS = 1024

# Set this to y to only display status messages during build.
QUIET = n

3. Run make install-src to install source at policy build location.
4. Change to the /etc/selinux/<NAME>/src/policy directory where an
unconfigured basic policy has been installed.

Page 262
The SELinux Notebook

5. Run make conf to build an initial policy/booleans.conf and
policy/modules.conf files. For this simple configuration these files will
not be edited.
This process will also build the
policy/modules/kernel/corenetwork.te / corenetwork.if
files if not already present. These would be based on the contents of
corenetwork.te.in and corenetwork.if.in configuration files
(for this simple configuration these files will not be edited).
6. Run make load to build the policy, add the modules to the store and install
the binary kernel policy plus its supporting configuration files.
Note that if policy stores have been migrated, the store will default to
/var/lib/selinux/refpolicy-test, with the modules in
active/modules/400/<module_name>, there will also be a CIL
version of the module (see Policy Store Migration for details).
7. The policy should now be built and can be checked using tools such as
apol(8) or loaded by editing the /etc/selinux/config file, running
'touch /.autorelabel' and rebooting the system.

5.4.2 Building the Fedora Policy
Building Fedora policies by hand is complex as they use the
rpmbuild/SPECS/selinux-policy.spec file, therefore this section will
give an overview of how this can be achieved, the reader can then experiment (the
spec file gives an insight). The build process assumes that an equivelent 'targeted'
policy will be built named 'targeted-179'.
Install the source as follows:
rpm -Uvh selinux-policy-3.12.1-179.fc20.src.rpm

The rpmbuild/SOURCES directory contents should be as follows with comments
on how the files should be installed:
File Name Comments
serefpolicy-3.12.1.tgz The Reference Policy version 2.20120725
This should be unpacked into:
rpmbuild/SOURCES/serefpolicy-3.12.1
policy-f20-base.patch Fedora changes to Reference Policy version 2.20120725.
These patches should be used to update the above
patch -p1 <policy-f20-base.patch
serefpolicy-contrib-3.12.1.tgz The Reference Policy contribution modules from version
2.20120725
Unpack the files, apply the policy-f20-contrib.patch and
then installed into:
./serefpolicy-3.12.1/policy/modules/contrib
policy-f20-contrib.patch Fedora changes to Reference Policy contribution modules.
Once the above has been completed, run make conf from ./serefpolicy-3.12.1
to initialise the build (it creates two important files in ./serefpolicy-

Page 263
The SELinux Notebook

3.12.1/policy/modules/kernel called corenetwork.te and
corenetwork.if).
config.tgz Fedora changes to Reference Policy version 2.20120725
application config files.
These should be unpacked to update the ./serefpolicy-
3.12.1/config versions (some will be added and others
updated).
permissivedomains.pp Contains Fedora domains currently sets to permissive. In
selinux-policy-3.12.1-179.fc20 there are 31 permissive
domains. Copy this to ./serefpolicy-3.12.1 as it will then
be built into the policy.
selinux-policy.conf Allows the build process to determine network information.
Not required for this exercise as the corenetwork.te and
corenetwork.if files have been built.
Makefile.devel Fedora makefile when using headers. This can replace the
./serefpolicy-3.12.1/support/Makefile.devel
booleans.subs_dist Common files installed for each policy type. Not required for
customizable_types this exercise.
file_contexts.subs_dist

Used to build "targeted" policy
booleans-targeted.conf Replace the ./serefpolicy-
3.12.1/policy/booleans.conf file with this version.
modules-targeted-base.conf Concatenate both files and copy this to become:
modules-targeted-contrib.conf ./serefpolicy-3.12.1/policy/modules.conf
securetty_types-targeted Replace the ./serefpolicy-3.12.1/config/appconfig-
mcs/securetty_types file with this version.
setrans-targeted.conf Not required for this exercise.
users-targeted Replace the ./serefpolicy-3.12.1/policy/users file with
this version.
Used to build "minimum" policy
booleans-minimum.conf

modules-targeted-base.conf Uses the targeted modules.conf.
modules-targeted-contrib.conf
securetty_types-minimum

setrans-minimum.conf

users-minimum

Used to build "mls" policy
booleans-mls.conf

modules-mls-base.conf

modules-mls-contrib.conf

securetty_types-mls

setrans-mls.conf

users-mls

The basic steps are:
1. Edit the build.conf file to reflect the policy to be built:

Page 264
The SELinux Notebook

############################################
# Policy build options
#

# Policy version
# By default, checkpolicy will create the highest version policy it supports.
# Setting this will override the version. This only has an effect for
# monolithic policies.
#OUTPUT_POLICY = 18