SE Linux


Dec 9, 2013 (4 years and 5 months ago)


to allow root to do everything and non-
privileged users to do nothing, Flask
provides more granular security levels
that apply both to file access privileges
and to inter process communication and
a whole range of additional features.
As is the case with other packages, SE
Linux has only limited potential for com-
pensating the weaknesses in protocols or
applications, but it does help to mitigate
their effect. The security server is the
central element in the Flask architectural
model and responsible for any security
based decisions. The name is derived
from the original Mach implementations
where it used to be a userspace process,
but on Linux the server runs as a kernel
Object managers are the second
Flask component. They manage security
attributes, ensure appropriate bindings
for the objects (files, processes, sockets
…) and enforce the decisions made
by the security server. Object managers
are well-known kernel subsystems, such
as process managers, file systems, or
sockets whose functionality have been
Security decisions are reached by
reference to so-called security contexts,
which are basically a container for a
group of security attributes. A context
comprises the user ID, the user’s role, a
type and an optional MLS (Multi Level
Security) level. Only legal combintations
that the security server recognizes are
Practical Abstraction
The individual components of a security
context originate from the abstraction
levels introduced by SE Linux. These
levels simplify the task of coping with
the complex reality of all possible types
access. Access control must specify the
conditions under which each program is
granted access to specific objects.
The first abstraction layer concerns
users. The fact that SE Linux user
administration is not based on the Linux
user ID has several advantages, for
example, the SE Linux user ID cannot
umors about mathematicians who
can break any conceivable code
abound in various urban legends.
But is IT security itself merely a myth?
The National Security Agency (NSA)
begs to differ on this issue, and has
become actively involved in enhancing
Linux security. One of the more notable
results is Security Enhanced Linux
(SE Linux), which started life as an
experimental prototype [1].
SE Linux provides additional access
control features for Linux. It uses
policies to decide what parts of the
system users will have access to – that
is, what files a process running with
the privileges of a specific account can
access, or what network connections the
process can open.
Non-privileged users cannot influence
the policy, which is applied as a
mandatory control by the admin user. SE
Linux thus implements MAC (Mandatory
Access Control, see insert “Important
Terms”). However, granular security
does impact the complexity of SE Linux.
To run a program securely on SE
Linux, the admin user needs to know
every file the process opens and every
subroutine it calls. But the level of
security the admin user can achieve
makes it well worth the effort.
Practical Concepts – not only
for Linux
The SE Linux security model was not
originally designed for Linux. The NSA
originally developed the architectural
prototypes for the Mach kernel [13] in
co-operation with Secure Computing
[12] (of TIS Firewall Toolkit fame): DT
Mach (Distributed Trusted Mach) and
DTOS (Distributed Trusted Operating
System). The Linux port was first
introduced when continued develop-
ment led to the release of Flask (the Flux
Advanced Security Kernel).
The Flask system’s task is to ensure
data integrity and trustworthiness – in
other words, it provides access controls.
Where a normal Linux kernel might tend
Sophisticated access controls are fundamental to a secure Linux environment.
SE Linux,which was developed by the National Security Agency (NSA) and
released under GPL,is a complex system that allows the administrator
granular control over privileges.This article looks into the background,basics,
installation and practical applications.
Practical Applications for Security Enhanced Linux
Security Rules
February 2003
SE Linux
Peter Doeberl,
be changed after logging on. To change
their privileges users have to change
either their role (an additional security
attribute), or their type (the third
attribute class).
To help the admin user keep track,
despite the sheer bulk and complexity of
the rules involved, multiple Linux users
can be combined to form a single non-
privileged user. The generic SE Linux
user, “user_u”, is an example of this
feature. In fact, the policy only needs to
be customized for users who require
more than the default privileges assigned
to “user_u”.
On SE Linux the term “user” is
normally applied to actual people with
interactive access to the system, with
“system_u” being the exception.
However, there is no need to add
pseudo-users for specific processes,
as the privileges assigned to these -
processes are defined by the individual
type. Having said this, some programs
still need to be run as their own user
accounts – in fact, file system privileges,
for which SE Linux does not provide an
abstraction, require this. Separate user
management means that both of these
independent components must allow an
action to make it succeed.
Freely definable roles provide the next
layer of abstraction (RBAC, Role-Based
Access Control). It is possible to run
multiple processes and applications
within the context of a single role. Roles
are modelled on the tasks performed by a
process or file. The sample configuration
detailed in the following sections uses
three roles: “system_r”, “sysadm_r”, and
“user_r”. System processes run in the
context of the “system_r” role, normal
users are assigned “user_r”, and
the “sysadm_r” role is provided for
administrative users.
Forceful Types
Types provide an additional abstraction
layer (TE, Type Enforcement); in fact
whether access is allowed or denied will
finally be decided by reference to the
type. The rules define what types can
access what other types. You may also
discover references to domains, but the
difference between domains and types is
purely linguistic. Types that are bound to
processes are referred to as domains,
although no internal distinction is made.
SE Linux defines the type by reference
to the role, and not by investigating the
user ID or filename. And privileges are
ascertained by the types assigned to a
role. A user working in the context of the
“user_r” role will not be able to load a
kernel module, not even if she is root,
but she will be allowed to load a kernel
module when working in the context of
the “sysadm_r” role, provided she is
permitted to assume this role.
After issuing the “newrole” command
to change your role and after completing
authentication, a new process is launched
for the new role. Of course this assumes
that role changes are permissible on
the current machine, and that the user
is allowed to occupy both roles. As
changing a domain is merely a specific
way of changing a type, again a new
process is required to change from
one domain to another. The following
conventions are recommended to help
keep track of users, types, roles and
• user: “_u”
• role: “_r”
• type or domain: “_t”
The “_u” suffix is not used for users of
Linux systems to help distinguish
between the two models.
Enforcing Decisions
To allow practical applications, security
attributes are combined to form a
security context. The security context of
a subject (a process) or an object (a file,
socket, IPC object …) comprises a
February 2003
DAC:Discretionary Access Control (the typical Linux procedure) allows users to modify access
privileges to their own objects at their own discretion.DAC commonly refers to user ID based access
control.Whether or not an action is permitted is decided by evaluating the user ID of the subject
and the object owner.There are only two types of users:normal users and superusers.
Domain:Security attribute of a process within the TE (Type Enforcement) model.SE Linux TE
does not differentiate between types and domains.However,types that refer to subjects (that
is,processes) are commonly referred to as domains.
Label:Symbolic descriptor for subjects and objects that allow SE Linux to reach a decision on
whether to allow or deny access.A label contains the security attributes which are applied by a
central policy.In the case of SE Linux the label resides within the security context.
MAC:Mandatory Access Control refers to a policy administrator defining access privileges
centrally.Users and their processes are not allowed to edit the policy,which governs all access.
Many definitions assume a special form of MLS for MAC,and thus refer to generic MAC as
non-discretionary access control.
MLS:Multi Level Security assigns a security level to subjects and objects,in line with layers of
security for important documents:confidential,secret,top secret.Only users with sufficient security
clearance are allowed access to objects.
Object:Refers to any component accessed,such as files,directories or network sockets.
Permissions:Depend on the object type.For files they could be read,write,create,rename,or
execute,for example – for processes possibly fork,ptrace,or signal.
PSID:The persistent SID is the permanent version of a security ID.A PSID is considered persistent
when it survives after rebooting.It represents the binding between an object and its security
context,as in the case of files,for example.
Policy:This set of rules defines who can access what,where and with what privileges.
RBAC:Role Based Access Control describes access control by means of roles.In SE Linux permissions
derive from the types and domains associated with a role.
Role:Roles simplify user management.Users are assigned roles depending on the tasks they
need to perform.Permissions are assigned to users via their roles;users can be assigned to roles
Security Context:A combination of user ID,role and type.To retain compatibility to other security
models,the security context is a text string whose content is parsed by the security server.
SID:The security ID is a number that points to a tangible security context.This binding is applied by
the SE Linux security server at runtime.
Subject:Active component in a system,that is a process.
TE:Type enforcement defines access by domains (subject classes) to types (classes of objects),or
other domains by reference to an access matrix.SE Linux simplifies this model and also describes
domains as types.The matrix defines permitted interactions between types.
Type:Security attribute of an object within the TE (type enforcement) model.
User:SE Linux user management is independent of the Linux user ID.
Important Terms
system. One interesting idea that the
developers of SE Linux are looking into
[11], is the concept of binding SIDs
to IPSEC security associations, thus
allowing networked applications running
on various SE Linux hosts to be run at
the same security layer.
Before access occurs, the object
manager sends the security contexts of
both the subject and the object to the
security server, which will make a rule-
based decision. If a process attempts to
access a file, the object manager registers
the “open()” call and asks the security
server to legitimize the attempt (see
Figure 1). In contrast to normal Linux
kernels, the manager will issue the same
request for each write or read access. A
normal kernel will only make this deci-
sion once on initial access. If the rights
of the open file are changed, the process
can continue reading – SE Linux would
prevent this from happening.
The Access Vector Cache (AVC) is
designed to prevent system performance
from suffering under the load generated
by requests of this type. The security
server’s responses are stored in the cache,
allowing faster processing of known
requests. And this means that total
performance is not noticeably affected by
continual clearance requests. If the per-
missions defined in the SE Linux policy
change, the security server marks any
modified entries in the AVC as invalid.
Figure 2 clarifies this type of access.
Each process is run in a protected
context of its own. User ID “0” has no
influence on this, unless the rules contain
explicit instructions to the contrary. This
allows you to confine processes and
enable or disable system calls. You can
also precisely define any files that the
process will be allowed to read, write,
or create. You can even remove any
privileges that might be harmful to the
system from processes that require more
extensive privileges (in order to bind
ports below 1024, for example). Even if
an attacker attains root access, she will
still be confined to the jail.
The SE Linux sources are covered by
the GPL and can be downloaded from the
NSA [1] and Sourceforge [3] websites. In
our lab environment we installed the
complete package [2] on a minimal SuSE
7.3 system. As SE Linux is based on Red
Hat, some minimal changes are required
before installing. Note that SE Linux
currently supports the Ext 2, Ext 3, and
ReiserFS file systems.
Installing SE Linux
Root privileges are required to install SE
Linux. Expanding the archive will create
the “lsm-2.4” subdirectory with the
revised kernel, and “selinux” with the
required programs and rules. The kernel
comprises the LSM (Linux Security
Modules) [4] patches, which add the
hooks the kernel requires to implement
SE Linux as a kernel module. The SuSE
kernel does not support SE Linux, as the
extensive modifications it contains pre-
vent the admin user from installing the
LSM and SE Linux patches. Unless other-
three-part colon-separated text string.
Attributes are the user, the user’s role,
and the type, for example “system_u:
The security server assigns a security
context to each process. The security
context comprises a set of rules, the
parent process, and the user ID
for the process. The rules must define
what processes can spawn what
child processes. This technique would
stop a compromised sendmail process
launching “/bin/tcsh”, for example.
In order to specify the security context,
the rules assign a label to each object.
The permissions are far more granular
than the privileges usually assigned by
Linux. In the case of files, for example,
SE Linux distinguishes between read,
write, create, rename, and execute per-
missions. Process permissions can allow
or deny fork, ptrace, or signalling.
At runtime SE Linux does not always
use an extensive string representation,
instead assigning numbers (so-called
SIDs, Security Identifiers) to represent
the strings. These integers are only
valid locally and temporarily, however,
persistent SIDs (PSIDs) can be assigned
to file system objects. Their security
context binding is stored in the file
February 2003
SE Linux
A number of tools are required to compile
SE Linux.The tools are included in the
following RPM packages for SuSE Linux 7.3:
• “d”series:bison,gettext,flex,pam_devel,
openssl_devel,patch,slang (for scurses.h)
and yacc
• “a”series:diffutils,ncurses (for libcurses),
texinfo (for makeinfo),and util-linux
(for more)
• “ap”series:sharutils
You may require additional packages
depending on your own configuration.
SuSE Packages for SE Linux
Figure 1:When a subject attempts to access an object the object manager intervenes by consulting the
security server and asking for confirmation that the access request is legitimate
Enforce policy
Object Manager
to object
Security Server
Security Policy
Query privileges/permissions
(file, socket)
Figure 2:The security server’s decision to permit or deny access is cached as an access vector to
accelerate the handling of this request in the future
Enforce policy
Object Manager Access Vector Cache
(stores decision)
Security Server
Security Policy
from cache
in cache
If answer is not cached:
pass on query
Query privileges/
wise designated, the new “selinux”
subdirectory is used as the starting point
for any subsequent steps. If you are in a
hurry, you can place the whole installa-
tion in the capable hands of a makefile:
“make quickinstall”, however, the more
roundabout approach also has its points
of interest. You will need a few tools for
the installation, the “SuSE Packages for
SE Linux” box gives details.
A few modifications to the LSM kernel
are also required for SE Linux. The
appropriate patches are located in the
“selinux/module” subdirectory. Simply
issue the “make insert” command here.
To write the kernel to “/boot” auto-
matically you will need to uncomment
the line containing “export INSTALL_
PATH=/boot” – but again you can leave
this step to a patch file.
An additional patch changes the kernel
image filename to “/boot/vmlinuz-
selinux”, thus retaining the original
kernel, which is particularly useful while
performing tests and for troubleshooting
later. The last two patches referred to are
available from [6]:
patch -p0
patch -p0
The new kernel still needs to be con-
figured for the local machine, although
you can use an existing “.config” as a ref-
erence point. SE Linux requires “Network
Packet Filtering” from “Networking
Options” and one or two “Security
Options” (Figure 3). The “NSA SELinux
Development Support” module is a big
help when defining your own sets of
rules. It launches SE Linux in permissive
mode, instead of enforcing mode, which
means that any actions that break the
rules will not be prevented, but merely
logged. The kernel is then generated with
the following:
make dep
&& make bzImage && make modules
&& make modules_install
&& make bzlilo && make clean
The next step is to make the boot loader
aware of the new kernel and its features.
SE Linux automatically boots to
Permissive Mode with development
support, but you can set the boot option
“enforcing=1” to change this.
It is usually a good idea to add
two boot configurations to the existing
configuration: the first entry should boot
SE Linux with “enforcing=1” set. No
additional parameters should be defined
for the second entry, and should boot SE
Linux in permissive mode. Enforcing
mode should be the default to prevent
security measures being disabled on
Enabling or Disabling GUI
Before starting the installation pro-
cedure, you might like to check whether
your machine boots to runlevel 3
(without GUI login). The display
managers have not been adapted to
reflect the new login pattern and will not
work. Instead of editing your “/etc/init-
tab” you can simply add “append=3” to
the SE Linux entries in “/etc/lilo.conf”,
and then launch “lilo” to enable the
newly modified configuration.
If you really need a GUI login, you can
use a modified GDM for Red Hat, which
is available from [3] or the KDM Patch
from [8]. You can easily launch X11
by typing “startx” to run KDE or Gnome
on SE Linux, but unfortunately there are
no rules for the desktop environments.
The SE Linux
package has a
number of modified
userspace programs.
Most of them
are installed in
the directory below
exceptions being
OpenSSH, login,
the cron daemon,
and such like.
Follow the normal make procedure,
“make && make install”, in “selinux/
module” and “selinux/libsecure”. Other
tools will require two patches available
from [6]:
patch -p0<utils_makefile_
patch -p0<utils_libncurses.diff
You cannot compile the sources on SuSE
Linux without applying these patches.
The “selinux/utils/Makefile” contains
“./configure” commands for most tools,
and you can also configure the options
here. “make && make install” in the
“utils” subdirectory will create and
install these packages; this also applies
to the setfiles tool in the “selinux/set-
files” subdirectory.
A Soft Landing Without Hard
You will need to remove one further
obstacle before configuring SE Linux.
The “/etc/localtime” is a hard link (see
also the “SE Linux Tips” insert), and
this is something SE Linux cannot
handle, as it means two different security
entries pointing to the same inode.
cp localtime localtime.hl
rm localtime
mv localtime.hl localtime
To prevent “SuSEconfig” from redefining
this hard link, you will need to set the
“TIMEZONE="timezone"” entry in “/etc
/rc.config” to “YAST_ASK”. SuSE 8.0 or
newer stores this entry in “/etc/syscon
fig/clock”. If the system uses other hard
links, SE Linux will issue a warning
when defining security contexts.
As almost all the files that influence
SE Linux behavior are stored below
February 2003
Figure 3:When defining a configuration with “make xconfig”,a few optional
security modules need to be added to the kernel:“Capabilities Support”and
“NSA SELinux Support”are mandatory and “Development Support”is useful
/home/[^/]* -d system_u:object_r:user_home_dir_t
/var/run(/.*) system_u:object_r:var_run_t
/var/run/.*\.*pid <<none>>
Listing 1:File Contexts
user will not be able to access the “/root”
In practical applications, roles are
used to permit or deny access to various
programs. One example of this is the
“insmod” program. The members of the
“sysadm_r” role and the system itself are
allowed to use the program, as both roles
comprised the “insmod_t” domain (that
is, type). In contrast, normal users with
the “user_r” role assignment will not
have permission. This prevents users
with the “user_r” role assignment from
loading kernel modules. Even if a user
escalates her privileges to root (user
ID 0), she will not be able to load any
modules, unless she additionally has
access to the “sysadm_r” role.
Security Contexts for Files
and Processes
The files below “file_contexts”
assign security contexts to file system
entries. “types.fc” contains non-specific,
program independent assignments, and
application specific assignments are
located below “program”. Taking a
look at these files should help to shed
some light on how SE Linux works
(see Listing 1). Each line starts with a
file system entry, which can easily be
characterized by a regular expression.
The “^” and “$” anchors at the start
and end of the lines can be omitted
as SE Linux will add these controlling
characters automatically.
The file entry may be followed by a file
type, which is supplied as a parameter
with a minus sign prepended. “-d”
represents a directory entry, and the rule
will thus apply to directories only. Enter
“--” instead, if the rule is meant for
normal files only.
The security context is shown at the
end of the line. It always includes the
user, “system_u”, the role, “object_r”,
and a corresponding type. Files created at
SE Linux runtime are automatically
assigned the user, role and type defined
for the process that created them. To
avoid creating a security context, you can
also specify “<<none>>” at this point.
If a file matches multiple rules, SE
Linux will apply the last line the file
matches. The second line in Listing 1
matches all the file system entries below
“/var/run” and assigns the “system_u:
object_r:var_run_t” security context to
them. The next line removes this
assignment for any of the entries ending
in “.pid”.
This just goes to show how important
the order is: Mixing up line 2 and 3
would assign the security context to
the PID files. Thus, entries must be
arranged in ascending order of
specificity. The wrong order will often
produce unexpected results.
“selinux/policy”, this directory will be
the starting point for the next few steps.
Comments in the configuration files are
indicated by hash signs, “#”, as you
would expect. The content of these files
is interpreted by the “m4” macro pre-
processor; many admins will be familiar
with this tool from configuring sendmail.
The macros help simplify more complex
configurations, however, the initial steps
and normal use will not mean you
needing to brush up on your “m4” skills.
Configuring SE Linux
The “users” file assigns a usable role
to every user, and the system policy
will only apply to user accounts listed
in the file. The first thing you should
do is delete the sample users “jdoe”
and “jadmin”. The entries follow the
“user username roles role;” pattern or,
if multiple roles are permitted, “user
username roles { role1 role2 };”.
There are three additional pre-defined
users: “system_u”. the system user,
“root”, and “user_u”. Any users not
explicitly named are automatically
assigned to the default user “user_u”
and assume the “user_r”. Thus, you do
not need to add every single Linux user
to this file. The following line contains a
sample entry for a non-privileged user:
user foo roles { user_r bar_r };
To assign additional permissions to a
user, you can allow the user access to the
“sysadm_r” role. If the entry for a user
specifies multiple roles, the user can
change roles at any time. The “sysadm_r”
role will assign root equivalent SE Linux
permissions to the user, however, this
does not imply root privileges on the
underlying Linux system, as SE Linux
access control works on top of the
standard Linux access control. Thus, the
February 2003
SE Linux
1 Jul 5 17:36:36 max kernel:avc:denied { read } for pid=616 exe=/sbin/mingetty path=/2/fd/10 dev=00:03
ino=163850 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:init_t tclass=lnk_file
2 Jul 5 17:36:36 max kernel:
3 Jul 5 17:36:36 max kernel:avc:denied { read } for pid=616 exe=/sbin/mingetty path=/450/maps dev=00:03
ino=29491213 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:postfix_master_t tclass=file
4 Jul 5 17:36:36 max kernel:
5 Jul 5 17:36:36 max kernel:avc:denied { getattr } for pid=616 exe=/sbin/mingetty path=/450/maps
dev=00:03 ino=29491213 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:postfix_master_t
Listing 2:Mingetty Error Messages
#add SE Linux utilities and man pages to path and manpath
uname -r | grep --silent selinux
if ["$?"="0"];then
Listing 3:Extending Paths
The different terms used for type
enforcement – that is “type” for files and
“domain” for processes – are reflected
in the names of the configuration files.
The “selinux/policy/domains/program”
directory contains files which end in
“.te” (type enforcement), which are used
to define permissible access types (that
is what domain is allowed what kind
of access to what type). Only the type
definitions are significant in “*.te” files,
but not file names, user IDs or roles.
To allow permissions to be assigned as
foreseen, you will need to assign security
contexts to your processes. Files ending
in “.fc” (file context) in the “selinux/
policy/file_contexts/program” sub-
directory are responsible for this task.
The security context of a process is
derived from the security context of the
program file, which is defined by an
“*.fc” file.
Customized Settings
SE Linux will only perform as designed if
you tailor it to reflect your current
distribution. As the defaults are Red Hat
specific, you will need to modify them to
correspond to a SuSE system. This
particularly applies to the file system
entries in the left column of the “*.fc”
files, as these two distributions use
different paths for various programs.
To avoid the time-consuming process
of modifying these files manually, you
might like to check out the additional
SuSE rules located at [7]. To simplify
the process of applying modified SE
Linux rules in the future, the specific
rules have been organized in the
“suse.fc” and “suse.te” files. You will
need to copy “suse.fc” to the
directory, and “suse.te” needs to be
copied to “selinux/policy/domains/
“selinux/utils/appconfig” contains a
few files used to configure the programs
modified for SE Linux. All of these files
should be copied to “/etc/security” first.
The “default_contexts” file defines what
roles and what type are assigned
by default to local logins, logins via
SSH, and cronjobs. The entries in
“default_type” assign a default type to
each role. The format of these entries is
“role:domain”. You will need to modify
this file, if you define additional roles.
The other files do not need modifying.
The only line in “initrc_context” defines
the security context for any init scripts
run by calling “run_init”. “passwd_
context” and “shadow_context” define
the security context for “/etc/passwd”
and “/etc/shadow”. This allows various
wrapper programs, such as “spasswd”,
to restore the context after “passwd” and
other programs have added to these files.
The “policy/rbac” file is used for
configuring the RBAC mechanism
(Role Based Access Control) and should
not be modified, unless a new role
necessitates this step. The existing rules
do not require any role changes; an
unpremeditated role change could
endanger the security of the whole
system. The file is line based and
adheres to the following syntax:
allow old_role new_role;
In contrast to type changes, which are
defined by rule sets of their own, every
line in this file explicitly permits clearly
defined role changes.
Mingetty with Maxi
If you use SuSE’s mingetty, you should
be prepared for a barrage of messages
about missing permissions (Listing 2).
This mingetty variant needs to parse the
PID directories below “/proc”. As these
directories are assigned to the security
context of the process that owns them,
mingetty would require read permissions
for too many different types, and thus
defeat the aim of SE Linux.
One possible solution is to use the Red
Hat mingetty package [9]. The binary
RPM can be created from the source RPM
by issuing “rpm --rebuild mingetty-1.00-
1.src.rpm” and installed by issuing “rpm
-ihv --force mingetty -1.00-1.rpm”. This
action will overwrite the SuSE counter-
part. The exact path to the newly created
mingetty package will depend on your
distribution, but normally defaults to
After completing these customization
steps, you can create your policy in the
“selinux/policy” by following the “make
&& make install” pattern. The policy is
applied after rebooting your system.
However, “make load” is available
during SE Linux runtime to load the new
policy immediately.
A Question of Policy
The next step uses “make reset” to bind
security contexts to file system entries,
and places a “…security” directory in
the root directories of any file systems
mounted and supported.
February 2003
1 7 system_u:system_r:init_t init [
2 7 system_u:system_r:init_t [keventd]
3 7 system_u:system_r:init_t [kapmd]
4 1 system_u:system_r:kernel_t [ksoftirqd_CPU0]
5 1 system_u:system_r:kernel_t [kswapd]
6 1 system_u:system_r:kernel_t [bdflush]
7 1 system_u:system_r:kernel_t [kupdated]
8 7 system_u:system_r:init_t [kreiserfsd]
214 169 system_u:system_r:syslogd_t/sbin/syslogd
217 166 system_u:system_r:klogd_t/sbin/klogd -c 1
279 172 system_u:system_r:atd_t/usr/sbin/atd
489 176 system_u:system_r:inetd_t/usr/sbin/xinetd -reuse
550 180 system_u:system_r:crond_t/usr/sbin/crond
574 182 system_u:system_r:getty_t/sbin/mingetty --noclear t
575 186 system_u:system_r:local_login_t login -- root
576 182 system_u:system_r:getty_t/sbin/mingetty tty3
577 182 system_u:system_r:getty_t/sbin/mingetty tty4
578 182 system_u:system_r:getty_t/sbin/mingetty tty5
579 182 system_u:system_r:getty_t/sbin/mingetty tty6
603 187 root:sysadm_r:sysadm_t -bash
622 187 root:sysadm_r:sysadm_t ps ax --context
Listing 4:Processes
the “sysadm_r” role – of course this is
also true of other modes. If SE Linux
boots without any errors, issuing “ps ax
--context” will produce similar output
to that shown in Listing 4 – that is, it
will show the processes within their
appropriate security contexts. The third
column in this output lists the security
context in the “user:role:type” format
mentioned previously.
Any processes belonging to a user will
be run with the user’s ID and role. Both
attributes are inherited by any child
processes. The security context for
system processes is not user-definable,
as they will always run with the
permissions of the “system_u” user, and
within the context of the “system_r”
role. Only the domain (that is, the type)
will depend on the actual process. If
every process runs within the context of
the same domain, the files below
“selinux/policy/file_contexts” may not
have been correctly customized.
The fact that child processes inherit
domains can mean that some processes
will still reside in the “initrc_t” domain
after booting. However, this domain is
used exclusively for launching the
scripts below “/etc/init.d/”. The admin
can either stop the RC scripts launching
these programs, or define a domain for
the programs that are launched.
The “ls / --context” command lists
security contexts for files (Listing 5). The
output has some resemblance to “ps”. If
new files are created on shutting down
or booting the system, they will not have
a label or a security context, even if they
are covered by a policy rule. You can
The “…security” directory contains a
database with the PSIDs (Persistent
Security Identifiers), which use the
inodes of the individual files and directo-
ries for the appropriate security context.
Changes are applied on rebooting the
system, but you can enable them in the
current SE Linux session by typing
“make relabel”. This command is also
required if a non SE Linux kernel was
running. Floppy and CD drives are
assigned a security context dynamically
when mounted.
When adding new rules to a system,
you should update the policy first before
changing the security context files.
Failing to do so could mean that
the system does not recognize a new
type that you have applied to files and
directories. In this case, SE Linux would
prevent potentially critical access.
Before booting SE Linux for the first
time, you might like to extend the paths
to include the paths for the manpages
and programs. The easiest way to do this
is to refer to Listing 3, which can be run
as “/etc/profile.local” .
Booting and Logging On
Booting to permissive mode is
recommended to avoid losing control
when incomplete or erroneous rules are
applied. In this case you can change to
February 2003
SE Linux
drwxr-xr-x root root system_u:object_r:root_t./
drwxr-xr-x root root system_u:object_r:root_t../
drwx------ root root
drwxr-xr-x root root system_u:object_r:bin_t bin/
drwxr-xr-x root root system_u:object_r:boot_t boot/
lrwxrwxrwx root root system_u:object_r:root_t cdrom
lrwxrwxrwx root root system_u:object_r:root_t cdrw
drwxr-xr-x root root system_u:object_r:device_t dev/
drwxr-xr-x root root system_u:object_r:etc_t etc/
lrwxrwxrwx root root system_u:object_r:root_t floppy
drwxr-xr-x root root system_u:object_r:user_home_t home/
drwxr-xr-x root root system_u:object_r:lib_t lib/
drwxr-xr-x root root system_u:object_r:lost_found_t lost+found/
drwxr-xr-x root root system_u:object_r:root_t media/
drwxr-xr-x root root system_u:object_r:root_t mnt/
drwxr-xr-x root root system_u:object_r:root_t opt/
dr-xr-xr-x root root system_u:object_r:proc_t proc/
drwx------ root root system_u:object_r:sysadm_home_t root/
drwxr-xr-x root root system_u:object_r:sbin_t sbin/
drwxrwxrwt root root system_u:object_r:tmp_t tmp/
drwxr-xr-x root root system_u:object_r:usr_t usr/
drwxr-xr-x root root system_u:object_r:var_t var/
Listing 5:File System
Avoid hard links:A file referred to by different
names via a common inode is not allowed to
have different privileges.The security context
refers to the inode and thus both names are
placed in the same context,although the file
context configuration might attempt to
assign two different contexts.
Do not convert Ext 2 to Ext 3:If you do use
an Ext 3 file system,it should not be a
converted Ext 2 file system.The “.journal”
file created by this process can cause trouble,
as there is no file type defined for it.
No RAM disk:You should launch SE Linux
without initializing a RAM disk.
Mixing SE Linux and standard Linux:If you
boot a non SE Linux kernel,you should delete
all the “…selinux”directories and regenerate
the security context for the files before
rebooting SE Linux.
Mailing list archive:The archive for the
SE Linux mailing list is only updated
infrequently on the home page [1].You
may prefer to use a different archive [5].
Backing up the configuration:You can
copy the “seliunux/policy”to “/etc/selinux/
policy”in order to simplify backing up the
configuration files.
Faster setfiles:Running “setfiles”can take
quite a while if you have a lot of files to
process.As an alternative,consider running
“setfiles”manually and only processing file
systems that have been modified.The
working directory must be “selinux/policy”.
You will need to issue the “setfiles file
_contexts/file_contexts partition_root”
command.If the file “file_contexts/file
_contexts”does not exist,or is too old,you
can instead use the “make filecontext/file
context”syntax.It is simpler to use “chcon”
rather than “setfiles”for less critical changes.
X server:If you intend to use an X server,
you should follow the steps described in point
4 of the “selinux/README”section in the
installation manual,and then run “startx”.
Our experiments with KDE 2 produced only
a few error messages,and a set of rules for
KDE should remedy the situation.
Root login:The current rule set does not
allow “sshd”to “/root”‘s home directory.
SSH based root login should therefore be
avoided.You can and should switch IDs
and roles later using “su -”and “newrole”.
Boot messages:Looking at the boot
messages provides further insight into SE
Linux.You can ascertain the current SE
Linux mode,for example.
Tips for SE Linux
then issue “make relabel” in the policy
directory to add the missing labels.
You should then watch your machine in
permissive mode for a while, just in case
you need to modify the rules.
Command Line Tools
SE Linux also comprises a few userspace
tools. The “avc_enforcing” program
displays the current SE Linux mode, that
is “enforcing” or “permissive”. The
“avc_toggle” tool allows you to toggle
between modes and does not require any
additional parameters.
Just like the standard Linux “su”
command, “newrole” launches a new
shell with a different role.
The “newrole -r sysadm_r” prompts
the user for a password before changing
to the “sysadm_r” role. The password
prompt ensures that only users, and not
shell scripts, can change roles. The
following conditions must be fulfilled
before a user can change role:
• The user must be a member of both
roles in “users”.
• The role change must be permitted by
the “rbac” file.
The “” is important. It
is located in the “selinux/scripts/”
directory and allows you to create new
rules from kernel messages.
Calling “ --help” will
display the syntax. The “-v” is particu-
larly interesting: it adds a comment
comprising information on the offending
process to the rule. “run_init” is used to
launch init scripts. After prompting for a
password, the program changes to the
“/etc/security/initrc_context” security
context and runs the init script.
Modified Progs for SE Linux
To use SE Linux additional features, the
package contains a number of modified
programs, such as “ps”, “ls”, “find”, “id”,
and “mkdir”. The modified “tar” tool also
backs up the security context of the files.
“runas” launches a program in a
different environment, with a different
role or in a different context, for example.
“chcon” changes the security context
of files and directories, however, these
changes are reverted when you run
“make relabel”.
“setfiles” is used to define a security
context for a file system, and “load
_policy” loads a new policy. “list_sids”
displays the security identifier (SID), and
“sid_to_context” displays the security
context for a SID.
Linux typically allows root to change
other users’ passwords without knowing
their current passwords. This privilege is
hard-coded into tools such as “passwd”,
“chfn”, and “chsh”. All three tools need
write privileges for the password files,
so a simple policy is inappropriate in
this case. Wrappers provide a solution:
“spasswd”, “schfn”, and “schsh” ensure
that users can only change their own
data, unless they have special
permission. Permission does not depend
on the user ID, but on the domain.
Critical modifications also apply
to “login”, “sshd”, and “crond”. As
cron fulfills a large number of system
specific tasks, it is difficult to define
an appropriate rule. The recommended
procedure is to comment out any tasks
you do not require cron to perform, and
define a set of rules for a cron domain
for any remaining tasks. The SuSE crond
is called “cron”, whereas the SE Linux
enhanced version is called “crond”. The
“/etc/init.d/cron” init script will need
some modifications (the “CRON_BIN”
variable defines the name of the binary).
There are also no rules for YaST.
The program requires quite extensive
permissions. As defining a complete
set of rules may be extremely time-
consuming, you can either do without
YaST or run the tool in permissive mode.
SE Linux provides the admin user with
extremely granular control over a system.
However, this potential advantage can
turn out to be troublesome: the more
rules you implement, and the more
complicated they become, the more
difficult it will be to check and trouble-
shoot them. In other words, potential for
error will increase. However, you can
mitigate the danger by defining groups of
rules, such as original, unchanged SE
Linux rules, operating specific rules used
to customize SE Linux for your distribu-
tion, and system specific rules that reflect
local conditions. This allows you to intro-
duce and maintain new rules more easily.
Alternatively, you might consider
reducing the range of tasks a program
performs, instead of defining a large
number of new rules. Your goals will
define your approach: It is easier to
remove a few cronjobs (such as updating
the locate database via “updatedb”) than
defining a few additional crond specific
rules. Many tasks, however, are
indispensable and you will not be able to
avoid defining appropriate rules.■
February 2003
[1] SE Linux home page at NSA:
[2] SE Linux package (36 MB):http://www.
[3] SE Linux project home page at
[4] LSM-Kernel:
[5] Alternative mailing list archive:http://
[6] Patches for SE Linux:
[7] Additional rules for SuSE:
[8] SE Linux patch for KDM:http://www.
[9] Mingetty packaget“mingetty-1.00-1.src
[10]Stephen Smalley,“Configuring the
SELinux Policy”:
[11] Peter Loscocco and Stephen Smalley,
“Integrating Flexible Support for Security
Policies into the Linux Operating System”:
[12] Secure Computing Corporation:
[13] Mach-Kernel:
Carsten Grohmann has been
interested in computers ever since
the KC87 was invented,and started
working with Linux in 1997.
He has been working as a system
administrator since 2000.
Konstantin Agouros started
investigating Unix and the Internet
in 1989,and has been interested
in Linux since 1994.He is responsible
for the Competence Center Security
at Netage.