i am not a kernel hacker… but i am just curious what i can find out about SELinux… that part of Linux contributed by the NSA.

“If you don’t treat security like a religious fanatic, you are going to be hurt like you can’t imagine. And Linus never took seriously the religious fanaticism around security,” said Dave Aitel, a former National Security Agency research scientist and founder of Immunity, a Florida-based security company.

Source: http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/



let us hear the official version: from: http://blog.namei.org/

SELinux Project Wiki

This is the official Security Enhanced Linux (SELinux) project page. Here you will find resources for users, administrators, vendors and developers.

For an account, send email to jmorris@namei.org.

What is SELinux

SELinux is a security enhancement to Linux which allows users and administrators more control over access control.

Access can be constrained on such variables as which users and applications can access which resources.

These resources may take the form of files.

Standard Linux access controls, such as file modes (-rwxr-xr-x) are modifiable by the user and the applications which the user runs.

Conversely, SELinux access controls are determined by a policy loaded on the system which may not be changed by careless users or misbehaving applications.

SELinux also adds finer granularity to access controls.

Instead of only being able to specify who can read, write or execute a file, for example, SELinux lets you specify who can unlink, append only, move a file and so on.

SELinux allows you to specify access to many resources other than files as well, such as network resources and interprocess communication (IPC).

For more information about SELinux see the FAQ and other resources listed here.

from: https://github.com/SELinuxProject/selinux/wiki

SELinux Userspace

This is the upstream repository for the Security Enhanced Linux (SELinux) userland libraries and tools. The software provided by this project complements the SELinux features integrated into the Linux kernel and is used by Linux distributions. The tools provide the following capabilities:

* Policy compilation – low-level tools that perform the conversion of the text-based SELinux policy language into the format used by the kernel for enforcement.

* Policy management – tools (e.g., semodule and semanage) and libraries (e.g., libsemanage) used to install, remove, and update SELinux policies on running systems.

* Policy development – tools to aid in the creation and updating of policies (e.g., audit2why and audit2allow).

* SELinux services – libraries (e.g., libselinux) for applications that must be aware of SELinux or enforce access control decisions using SELinux (e.g., Dbus).

* SELinux utilities – low-level utilities (e.g., setenforce and restorecon) for administering and SELinux-enabled system.

The software can be obtained as tested releases or from the development repository

from: https://en.wikipedia.org/wiki/SELinux



Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including United States Department of Defense–style mandatory access controls (MAC).

SELinux is a set of kernel modifications and user-space tools that have been added to various Linux distributions. Its architecture strives to separate enforcement of security decisions from the security policy itself and streamlines the volume of software charged with security policy enforcement.[2][3] The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency.

The security of an „unmodified“ Linux system (a system without SELinux) depends on the correctness of the kernel, of all the privileged applications, and of each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a „modified“ system (based on an SELinux kernel) depends primarily on the correctness of the kernel and its security-policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not necessarily pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.

From a purist perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies.

SELinux was designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Originally, the patches that make up SELinux had to be explicitly applied to the Linux kernel source; SELinux has been merged into the Linux kernel mainline in the 2.6 series of the Linux kernel.

The United States National Security Agency (NSA), the original primary developer of SELinux, released the first version to the open source development community under the GNU GPL on December 22, 2000.[5] The software merged into the mainline Linux kernel 2.6.0-test3, released on 8 August 2003. Other significant contributors include Red Hat, Network Associates, Secure Computing Corporation, Tresys Technology, and Trusted Computer Solutions. Experimental ports of the FLASK/TE implementation have been made available via the TrustedBSD Project for the FreeBSD and Darwin operating systems.

Security-Enhanced Linux implements the Flux Advanced Security Kernel (FLASK). Such a kernel contains architectural components prototyped in the Fluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multilevel security. FLASK, in turn, was based on DTOS, a Mach-derived Distributed Trusted Operating System, as well as Trusted Mach, a research project from Trusted Information Systems that had an influence on the design and implementation of DTOS.

Source: https://en.wikipedia.org/wiki/SELinux

sudo bash; # become root so you can find (hopefully) all files

find / -name '*selinux*'; # just checkout what is there

/etc/selinux; # /lib/i386-linux-gnu/libselinux.so.1

# === lets checkout the content of this config file:
vim /etc/selinux/semanage.conf;

# Authors: Jason Tang <jtang@tresys.com> #
# Copyright (C) 2004-2005 Tresys Technology, LLC
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# Lesser General Public License for more details.
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
# Specify how libsemanage will interact with a SELinux policy manager.
# The four options are:
# "source" - libsemanage manipulates a source SELinux policy
# "direct" - libsemanage will write directly to a module store.
# /foo/bar - Write by way of 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.
module-store = direct

# When generating the final linked and expanded policy, by default
# semanage will set the policy version to POLICYDB_VERSION_MAX, as
# given in <sepol/policydb.h>. Change this setting if a different
# version is necessary.
#policy-version = 19

# expand-check check neverallow rules when executing all semanage commands.
# Large penalty in time if you turn this on.

# === quit...
# ok if there is "stuff" going on it would be on port 4242
lsof -i -P | grep 4242; # no output
lsof -i -P; # list all open ports and listening services/programs

# === next question: what is libsemanage and is it installed?

dpkg -l|grep libsemanage; # yes it is ii = installed
ii libsemanage-common 2.3-1 all Common files for SELinux policy management libraries
ii libsemanage1:i386 2.3-1+b1 i386 SELinux policy management library

apt-cache show libsemanage-common
Package: libsemanage-common
Source: libsemanage
Version: 2.3-1
Installed-Size: 65
Maintainer: Debian SELinux maintainers <selinux-devel@lists.alioth.debian.org>
Architecture: all
Replaces: libsemanage1 (<= 2.0.41-1), libsemanage1-dev (<< 2.1.6-3~)
Breaks: libsemanage1 (<= 2.0.41-1), libsemanage1-dev (<< 2.1.6-3~)
Description-en: Common files for SELinux policy management libraries
This package provides the common files used by the shared libraries
for SELinux policy management.
Security-enhanced Linux is a patch of the Linux kernel and a
number of utilities with enhanced security functionality designed to
add mandatory access controls to Linux. The Security-enhanced Linux
kernel contains new architectural components originally developed to
improve the security of the Flask operating system. These
architectural components provide general support for the enforcement
of many kinds of mandatory access control policies, including those
based on the concepts of Type Enforcement, Role-based Access
Control, and Multi-level Security.
Description-md5: c7a0a093650c85e838f42492add9b46b
Multi-Arch: foreign
Homepage: http://userspace.selinuxproject.org/
Tag: role::app-data
Section: libs
Priority: optional
Filename: pool/main/libs/libsemanage/libsemanage-common_2.3-1_all.deb
Size: 24580
MD5sum: 0b201e8dac4668c70a6755ef82e0ece1
SHA1: 29b16f92cb55964bae28e113f2d7dd0667257e71
SHA256: 6cee4cf858797141ecb5775f33a82cb7ffb5d2c047a0fb9f4ed08005b9c33671

# === next question: what other software is out there related to selinux:

apt-cache search selinux|more
checkpolicy - SELinux policy compiler
debian-handbook - reference book for Debian users and system administrators
joe-jupp - reimplement the joe Debian package using jupp
jupp - user friendly full screen text editor
libselinux1 - SELinux runtime shared libraries
libselinux1-dev - SELinux development headers
python-selinux - Python bindings to SELinux shared libraries
ruby-selinux - Ruby bindings to SELinux shared libraries
selinux-utils - SELinux utility programs
libsemanage-common - Common files for SELinux policy management libraries
libsemanage1 - SELinux policy management library
libsemanage1-dev - Header files and libraries for SELinux policy manipulation
python-semanage - Python bindings for SELinux policy management
ruby-semanage - Ruby bindings to for SELinux policy management
libsepol1 - SELinux library for manipulating binary security policies
libsepol1-dev - SELinux binary policy manipulation library and development files
policycoreutils - SELinux core policy utilities
python-sepolicy - Python binding for SELinux Policy Analyses
postgresql-contrib-9.4 - additional facilities for PostgreSQL
selinux-basics - SELinux basic support
python-sepolgen - Python module used in SELinux policy generation
libseaudit-dev - Security Enhanced Linux audit message parser development
libseaudit4 - Security Enhanced Linux audit message parsing library
libsefs-dev - Security Enhanced Linux file context management development
libsefs4 - Security Enhanced Linux file context management
libsetools-java - SETools Java bindings (architecture-independent)
libsetools-tcl - SETools Tcl bindings
python-setools - SETools Python bindings
setools - tools for Security Enhanced Linux policy analysis setools-gui - GUI tools for Security Enhanced Linux policy analysis libtomoyotools3 - lightweight Linux Mandatory Access Control system - library
tomoyo-tools - lightweight Linux Mandatory Access Control system

# === testing out those tools:
apt-get install setools setools-gui;

More from the Wiki:

SELinux users and roles do not have to be related to the actual system users and roles. For every current user or process, SELinux assigns a three string context consisting of a username, role, and domain (or type). This system is more flexible than normally required: as a rule, most of the real users share the same SELinux username, and all access control is managed through the third tag, the domain. The circumstances under which a process is allowed into a certain domain must be configured in the policies. The command


allows for the launching of a process into an explicitly specified context (user, role and domain), but SELinux may deny the transition if it is not approved by the policy.

Files, network ports, and other hardware also have an SELinux context, consisting of a name, role (seldom used), and type. In case of file systems, mapping between files and the security contexts is called labeling. The labeling is defined in policy files but can also be manually adjusted without changing the policies. Hardware types are quite detailed, for instance,


(all files in the folder /bin) or


(PostgreSQL port, 5432). The SELinux context for a remote file system can be specified explicitly at mount time.

SELinux adds the


switch to the shell commands




, and some others, allowing the security context of the files or process to be seen.

Typical policy rules consist of explicit permissions; which domains the user must possess to perform certain actions with the given target (read, execute, or, in case of network port, bind or connect), and so on. More complex mappings are also possible, involving roles and security levels.

A typical policy consists of a mapping (labeling) file, a rule file, and an interface file, that define the domain transition. These three files must be compiled together with the SELinux tools to produce a single policy file. The resulting policy file can be loaded into the kernel, making it active. Loading and unloading policies does not require a reboot. The policy files are either hand written or can be generated from the more user friendly SELinux management tool. They are normally tested in permissive mode first, where violations are logged but allowed. The


tool can be used later to produce additional rules that extend the policy to allow all legitimate activities of the application being confined.


SELinux features include:

  • clean separation of policy from enforcement
  • well-defined policy interfaces
  • support for applications querying the policy and enforcing access control (for example, crond running jobs in the correct context)
  • independence of specific policies and policy languages
  • independence of specific security-label formats and contents
  • individual labels and controls for kernel objects and services
  • support for policy changes
  • separate measures for protecting system integrity (domain-type) and data confidentiality (multilevel security)
  • flexible policy
  • controls over process initialization and inheritance and program execution
  • controls over file systems, directories, files, and open file descriptors
  • controls over sockets, messages, and network interfaces
  • controls over the use of „capabilities“
  • cached information on access-decisions via the Access Vector Cache (AVC)[6]


SELinux is available with commercial support as part of Red Hat Enterprise Linux (RHEL) version 4 and all future releases. This presence is also reflected in corresponding versions of CentOS and Scientific Linux. The supported policy in RHEL4 is the targeted policy which aims for maximum ease of use and thus is not as restrictive as it might be. Future versions of RHEL are planned to have more targets in the targeted policy which will mean more restrictive policies. SELinux has been implemented in Android since version 4.3[7]

In free community supported GNU/Linux distributions, Fedora was one of the earliest adopters, including support for it by default since Fedora Core 2. Other distributions include support for it such as Debian as of the etch release[8] and Ubuntu as of 8.04 Hardy Heron.[9] As of version 11.1, openSUSE contains SELinux „basic enablement“.[10] SUSE Linux Enterprise 11 features SELinux as a „technology preview“.[11]

Use scenarios

SELinux can potentially control which activities a system allows each user, process and daemon, with very precise specifications. However, it is mostly used to confine daemons[citation needed] like database engines or web servers that have more clearly defined data access and activity rights. This limits potential harm from a confined daemon that becomes compromised. Ordinary user-processes often run in the unconfined domain, not restricted by SELinux but still restricted by the classic Linux access rights.

Command-line utilities include:[12]








































,[26] and




To put SELinux into enforcing mode:

$ sudo setenforce 1

To query the SELinux status:

$ getenforce

Comparison with AppArmor

SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take. Another popular alternative is called AppArmor and is available on SUSE Linux Enterprise Server (SLES), openSUSE and Ubuntu platforms. AppArmor was developed as a component to the now-defunct Immunix Linux platform. Because AppArmor and SELinux differ radically from one another, they form distinct alternatives for software control. Whereas SELinux re-invents certain concepts in order to provide access to a more expressive set of policy choices, AppArmor was designed to be simple by extending the same administrative semantics used for DAC up to the mandatory access control level.

There are several key differences:

  • One important difference is that AppArmor identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link.
    • As a result, AppArmor can be said not to be a type enforcement system, as files are not assigned a type; instead, they are merely referenced in a configuration file.
  • SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.[28]
  • Since it endeavors to recreate traditional DAC controls with MAC-level enforcement, AppArmor’s set of operations is also considerably smaller than those available under most SELinux implementations. For example, AppArmor’s set of operations consist of: read, write, append, execute, lock, and link.[29] Most SELinux implentations will support numbers of operations orders of magnitude more than that. For example, SELinux will usually support those same permissions, but also includes controls for mknod, binding to network sockets, implicit use of POSIX capabilities, loading and unloading kernel modules, various means of accessing shared memory, etc.
  • There are no controls in AppArmor for categorically bounding POSIX capabilities. Since the current implementation of capabilities contains no notion of a subject for the operation (only the actor and the operation itself) it is usually the job of the MAC layer to prevent privileged operations on files outside the actor’s enforced realm of control (i.e. „Sandbox“). AppArmor can prevent its own policy from being altered, and prevent filesystems from being mounted/unmounted, but does nothing to prevent users from stepping outside their approved realms of control.
    • For example, it may be deemed beneficial for help desk employees to change ownership or permissions on certain files even if they don’t own them (for example, on a departmental file share). You obviously don’t want to give the user(s) root on the box so you give them



      . Under SELinux you (or your platform vendor) can configure SELinux to deny all capabilities to otherwise unconfined users, then create confined domains for the employee to be able to transition into after logging in, one that can exercise those capabilities, but only upon files of the appropriate type.

  • There is no notion of multi-level security with AppArmor, thus there is no hard BLP or Biba enforcement available.
  • AppArmor configuration is done using solely regular flat files. SELinux (by default in most implementations) uses a combination of flat files (used by administrators and developers to write human readable policy before it’s compiled) and extended attributes.
  • SELinux supports the concept of a „remote policy server“ (configurable via /etc/selinux/semanage.conf) as an alternative source for policy configuration. Central management of AppArmor is usually complicated considerably since administrators must decide between configuration deployment tools being run as root (to allow policy updates) or configured manually on each server.

Similar systems

See also: Samsung Knox

Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, in its first implementation[30] sandboxed individual applications in lightweight Vservers. Also, the NSA has adopted some of the SELinux concepts in Security-Enhanced Android.[31]

See also



„SELinux Related Work“. NSA.gov.

Related Manpages:




Related Events:



Related Mailinglists:


Related Links:

tresys.com Security Engineering Beneath the Surface

8840 Stanford Blvd
Suite 2100
Columbia, MD 21045