The software described in this documentation is either in Extended Support or Sustaining Support. See https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdf for more information.
Oracle recommends that you upgrade the software described by this documentation as soon as possible.
An SELinux policy describes the access permissions for all users, programs, processes, and files, and for the devices upon which they act. You can configure SELinux to implement either Targeted Policy or Multilevel Security (MLS) Policy.
Targeted Policy applies access controls to a limited number of
processes that are believed to be most likely to be the targets of
an attack on the system. Targeted processes run in their own
SELinux domain, known as a confined domain,
which restricts access to files that an attacker could exploit. If
SELinux detects that a targeted process is trying to access
resources outside the confined domain, it denies access to those
resources and logs the denial. Only specific services run in
confined domains. Examples are services that listen on a network
for client requests, such as httpd,
named, and sshd, and
processes that run as root
to perform tasks on
behalf of users, such as passwd. Other
processes, including most user processes, run in an unconfined
domain where only DAC rules apply. If an attack compromises an
unconfined process, SELinux does not prevent access to system
resources and data.
Multilevel Security (MLS) Policy applies access controls to
multiple levels of processes with each level having different
rules for user access. Users cannot obtain access to information
if they do not have the correct authorization to run a process at
a specific level. In SELinux, MLS implements the Bell–LaPadula
(BLP) model for system security, which applies labels to files,
processes and other system objects to control the flow of
information between security levels. In a typical implementation,
the labels for security levels might range from the most secure,
top secret
, through secret
,
and classified
, to the least secure,
unclassified
. For example, under MLS, you might
configure a program labelled secret
to be able
to write to a file that is labelled top secret
,
but not to be able to read from it. Similarly, you would permit
the same program to read from and write to a file labelled
secret
, but only to read
classified
or unclassified
files. As a result, information that passes through the program
can flow upwards through the hierarchy of security levels, but not
downwards.