8

Chapter 2. SELinux Policy Overview

7.

init

then re executes itself so that it can transition to a different domain, if the policy defines

it. For the targeted policy, there is no transition defined and

init

remains in the

unconfined_t

domain.

8. At this point,

init

continues with its normal boot.

The reason for

init

to re execute itself is to accommodate stricter SELinux policy controls. The

objective of a re execution is to transition to a new domain with its own granular rules. The only way

a process can gain a domain is during execution, meaning such programs are the only entry points

into the domains. For example, if the policy has a specific domain for

init

such as

init_t

, there has

to be a method to get from the initial SID, such as

kernel

, to the proper runtime domain for

init

.

Because this transition may need to occur,

init

is coded to re execute itself after loading the policy.

This transition with

init

happens if the rule

domain_auto_trans(kernel_t, init_exec_t,

target_domain_t )

is present in the policy. This rule states that an automatic transition occurs

on anything executing from the

kernel_t

domain that executes a file of type

init_exec_t

. When

this execution occurs, the new process is assigned the domain

target_domain_t

, using an actual

target domain such as

init_t

.

2.4. File System Security Contexts

This section covers how file system security contexts are defined and stored.

SELinux stores file security labels in xattrs

1

. For more information about xattrs, read the manual pages

for

attr(5)

,

getfattr(1)

, and

setfattr(1)

. Xattrs are stored as name value property pairs as 

sociated with files. SELinux uses the security.selinux attribute. The xattrs can be stored with

files on a disk or in memory with pseudo file systems. Currently, most file system types support the

API for xattr, which allows for retrieving attribute information with

getxattr(2)

.

Some non persistent objects can be controlled through the API. The pseudo tty system controlled

through

/dev/pts

is manipulated through

setxattr(2)

, enabling programs such as

sshd

to change

the context of a tty device. Information about the tty is exported and available through

getxattr(2)

.

However,

libselinux

provides a more useful set of functions layered on top of the xattr API, such

as

getfilecon(3)

,

setfilecon(3)

, and

setfscreatecon(3)

.

Tip

It is recommended to use libselinux when managing file attributes in SELinux programmatically.

There are two approaches to take for storing file security labels on a file system, such as ext2 or ext3.

One approach is to label every file system object (all files) with an individual security attribute

2

. Once

these labels are on the file system, the xattrs become authoritative for holding the state of security

labels on the system.

The other option is to label the entire file system with a single security attribute. This is called genfs

labeling. One example of this is with ISO9660 file systems, which are used for CD ROMs and

.iso

files. This example from

$SELINUX_SRC/genfs_contexts

defines the context for every file on an

ISO9660 file system.

1. Extended attributes are also called EAs. To be more concise, the term xattr is used in this guide.

2. These are defined initially for the system in $SELINUX_SRC/file_contexts/types.fc.

This

file

uses

regular

expression

matching

to

associate

the

files

on

a

particular

path

with a particular security label. These contexts are rendered into the installed version at

/etc/selinux/targeted/contexts/files/file_contexts,

and are used during installation of

the operating system and software packages, or for checking or restoring files to their original state.