1 SELinux #
1.1 About SELinux #
SELinux was developed as an additional Linux security solution that uses the security framework in the Linux kernel. The purpose was to allow for a more granular security policy that goes beyond the standard Discretionary Access Controls (DAC), the traditional file permissions of owner/group/world, and read/write/execute.
SELinux uses labels attached to objects (for example, files and network sockets) to make access control decisions.
The default action of SELinux is to deny any access. SELinux allows only actions that were specifically allowed in the SELinux policy. Another feature of SELinux that increases security is that SELinux allows strict confinement of processes up to the point where the processes cannot access files of other processes on the same system.
SELinux was designed to enhance existing security solutions, not to replace them. For example, discretionary access control (DAC) is still applied, even if the system is using SELinux. If DAC denies access first, SELinux is then not used as the access was already blocked by another mechanism.
1.2 Getting SELinux #
SELinux is installed by default when installing SLE Micro by YaST or is part of the pre-built images.
If SELinux is not set up on your system, run the following command:
#
transactional-update setup-selinux
Reboot your system after the command has finished. The command installs the
SELinux policy if it is not installed, sets the
enforcing
SELinux mode and rebuilds
initrd
.
1.3 SELinux modes #
SELinux can run in one of three modes: disabled
,
permissive
or enforcing
.
Using the disabled
mode means that no rules from the
SELinux policy are applied and your system is not protected. Therefore, we
do not recommend using the disabled
mode.
In the permissive
mode, SELinux is active, the security
policy is loaded, the file system is labeled and access denial entries are
logged. However, the policy is not enforced and thus no access is actually
denied.
In the enforced
mode, the security policy is applied.
Each access that is not explicitly allowed by the policy is denied.
This is the default SELinux mode on
SLE Micro, regardless of the deployment type.
For information about switching between SELinux modes, refer to Section 1.3.1, “Changing the SELinux mode”.
1.3.1 Changing the SELinux mode #
You can switch the SELinux mode temporarily or permanently.
1.3.1.1 Changing the SELinux mode temporarily #
To set SELinux to the permissive
or
enforcing
mode temporarily, use the command
setenforce
.
The setenforce
command has the following syntax:
#
setenforce MODE_ID
where MODE_ID is 0
for the permissive
mode or
1 for the enforced
mode.
Remember that you cannot disable SELinux using the
setenforce
command.
1.3.1.2 Changing the SELinux mode permanently #
To perform changes to the SELinux mode that persists rebooting of the
system, edit the /etc/selinux/config
configuration
file. In this file, you can also disable SELinux on your system. However,
this action is not recommended. If SELinux is possibly causing issues to
your system, switch to the permissive
mode instead and
debug your system.
In the file /etc/selinux/config
, change the value of
SELINUX
to disabled
, or
permissive
, or enforced
as follows:
SELINUX=disabled
The changes in the file are applied after the next reboot.
disabled
mode
If you disable SELinux on your system and then enable it later, make
sure that you relabel your system. When SELinux is disabled and you
perform changes to your file system, the changes are not reflected in
the context anymore (for example, new files do not have any context).
Therefore, you need to relabel your system by using the
restorecon
command, using the
autorelabel
boot parameter, or by creating a file
that will trigger relabeling on the next boot. To create the file, run
the following command:
#
touch /etc/selinux/.autorelabel
After reboot, the file /etc/selinux/.autorelabel
is replaced with another flag file,
/etc/selinux/.relabelled
, to prevent relabeling on
subsequent reboots.
1.3.1.3 Verifying the active SELinux mode #
To verify the mode, run the following command:
#
getenforce
The command should return permissive
or
enforced
, depending on the provided
MODE_ID.
1.3.2 Verifying that SELinux is functional #
If you are performing configuration changes, it may be useful to switch to permissive mode. During this time, users might label files incorrectly, and thus cause problems when switching back to enforcing mode.
To return the system back to its secured state, perform the following steps:
Reset the security context:
>
sudo
restorecon -R /
Switch to enforcing mode by setting
SELINUX=enforcing
in the/etc/selinux/config
.Reboot the system and log in again.
Run the
sestatus -v
command. It should give you an output similar to the following one:>
sudo
sestatus -v
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: requested(insecure) Max kernel policy version: 33 Process contexts: Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Init context: system_u:system_r:init_t:s0 /usr/sbin/sshd system_u:system_r:sshd_t:s0-s0:c0.c1023 File contexts: Controlling terminal: unconfined_u:object_r:user_tty_device_t:s0 /etc/passwd system_u:object_r:passwd_file_t:s0 /etc/shadow system_u:object_r:shadow_t:s0 /bin/bash system_u:object_r:shell_exec_t:s0 \ -> system_u:object_r:shell_exec_t:s0 /bin/login system_u:object_r:login_exec_t:s0 /bin/sh system_u:object_r:bin_t:s0 \ -> system_u:object_r:shell_exec_t:s0 /sbin/agetty system_u:object_r:bin_t:s0 \ -> system_u:object_r:getty_exec_t:s0 /sbin/init system_u:object_r:bin_t:s0 -> \ system_u:object_r:init_exec_t:s0 /usr/sbin/sshd system_u:object_r:sshd_exec_t:s0If the system is not working properly, check the log files in
/var/log/audit/audit.log
. For more details, refer to SELinux troubleshooting.
1.4 SELinux security context #
The security context is a set of information assigned to a file or a process. It consists of SELinux user, role, type, level and category. This information is used to make access control decisions.
- SELinux user
An identity defined in the policy that is authorized for a specific set of roles and for a specific level range. Each Linux user is mapped to only one SELinux user. However, one SELinux user can have several roles.
SELinux does not use the list of user accounts maintained by Linux in
/etc/passwd
, but uses its own database and mapping. By convention, the identity name is suffixed with_u
, for example,user_u
.When a new Linux account is created and the SELinux user is not assigned to the account, the default SELinux user is used. Usually, the default value is
unconfined_u
. For a procedure on how to change the default value, refer to Section 1.7.5.2, “Thesemanage login
command”.- role
Defines a set of permissions that a user can be granted. A role defines which types a user assigned to this role can access. By convention, the role name is suffixed with
_r
, for example,system_r
.- type
The type conveys information on how particular files and processes can interact. A process consists of files with a concrete SELinux type, and it cannot access files outside of this type. By convention, the type name is suffixed with
_t
, for example,var_t
.- level
An optional attribute that specifies the range of levels of clearance in the multilevel security.
- category
An optional attribute that allows you to add categories to processes, files and users. A user can then access files that have the same category.
Here is an example of an SELinux context:
allow user_t bin_t:file {read execute gettattr};
This example rule states that the user who has the context type
user_t
(this user is called the
source object) is allowed to access objects of the class
file with the context type bin_t
(the target), using the permissions read
,
execute
and getattr
.
1.5 SELinux policy overview #
The policy is the key component in SELinux. Your SELinux policy defines rules that specify which objects can access which files, directories, ports and processes on a system. To do this, a security context is defined for all of these.
An SELinux policy contains a huge number of rules. To make it more manageable, policies are often split into modules. This allows the administrator to switch protection on or off for different parts of the system.
When compiling the policy for your system, you will have a choice to either work with a modular policy, or a monolithic policy, where one huge policy is used to protect everything on your system. We strongly recommend using a modular policy and not a monolithic policy. Modular policies are much easier to manage.
SLE Micro is shipped with the targeted
SELinux
policy.
1.5.1 Working with SELinux modules #
As an administrator, you can switch modules on or off. This can be useful if you want to disable only a part of the SELinux policy and you do not want to run a specific service without SELinux protection.
To view all SELinux policy modules in use, run the command:
semodule -l
After you get the name of the module you want to switch off, run the command:
>
sudo
semodule -d MODULENAME
To switch on the policy module, run the command:
>
sudo
semodule -e MODULENAME
1.5.2 Creating policies for containers #
SLE Micro is delivered with a policy that, by default, does not
allow containers to access files outside the container data. On the other
hand, all network access is allowed. Typically, containers are created with
bind mounts and should be able to access other directories, like
/home
or /var
. You may want a
possibility to allow access to these directories or, on the contrary,
restrict some ports to the container even if SELinux is used on your
system. In this case, you need to create new policy rules that enable or
disable the access. SLE Micro provides the Udica tool for this
purpose.
The following procedure describes how to create a custom policy for your containers:
Make sure that SELinux is in the enforcing mode. For details, refer to Section 1.3.1, “Changing the SELinux mode”.
Start a container using the following parameters:
#
podman run -v /home:/home:rw -v /var/:/var/:rw -p 21:21 -it sle15 bashThe container runs with the default policy that does not allow access to the mount points but does not restrict other ports.
You can exit the container.
Obtain the container ID:
#
podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e59f9d0f86f2 registry.opensuse.org/devel/bci/tumbleweed/containerfile/opensuse/bci/ruby:latest /bin/bash 8 minutes ago Up 8 seconds ago 0.0.0.0:21->21/tcp zen_ramanujanCreate a JSON file that Udica will use to create a custom policy for the container:
#
podman inspect e59f9d0f86f2 > OUTPUT_JSON_FILEFor example, substitute OUTPUT_JSON_FILE with
container.json
.Run Udica to generate a policy according to the container parameters:
#
udica -j OUTPUT_JSON_FILE CUSTOM_CONTAINER_POLICYFor example:
#
udica -j container.json custom_policyAccording to the provided instructions, load the policy modules by running:
#
semodule -i custom_policy.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}Run a container with the new policy module by using the
--security-opt
option as follows:#
podman run --security-opt label=type:custom_policy.process -v /home:/home:rw -v /var/:/var/:rw -p 21:21 -it sle15 bash
1.6 SELinux Booleans #
SELinux Booleans support a flexible policy management approach. For example, Booleans enable you to disable a particular policy on one server, while keeping the same policy active on another one. In other words, a Boolean can be understood as a switch for a policy rule. Instead of changing a particular policy, you can switch it off. In the policy code, Booleans are called a tunable. Because Booleans are included in the policy, they are available as soon as a policy is loaded.
The changes to the Booleans value may be persistent or temporary, lasting until the end of the session.
SELinux offers tools that enable you to list and view details or change the state of Booleans. See the following sections for details.
1.6.1 Working with Booleans #
1.6.1.1 Listing Booleans #
You can use the getsebool
or
semanage
command to list currently defined Booleans.
To list all currently defined Booleans, along with their state, run the
following command:
#
getsebool -a
abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
...
To get more details about particular Booleans, you can use the
semanage
command as follows:
#
semanage boolean -l
SELinux boolean State Default Description
abrt_anon_write (off , off) Allow abrt to anon write
abrt_handle_event (off , off) Allow abrt to handle event
abrt_upload_watch_anon_write (on , on) Allow abrt to upload watch anon write
To get the status of an individual Boolean, you can use the following command:
#
getsebool BOOLEAN_NAME
Alternatively, you can just use the grep
command on
the semanage boolean
output:
#
semanage boolean -l | grep BOOLEAN_NAME
1.6.1.2 Toggling Booleans #
The commands setsebool
and semanage
can be used to toggle the value of Booleans. You can change the Boolean status
persistently or just temporarily until the session ends. To change a
Boolean value temporarily, run the following command:
#
setsebool BOOLEAN_NAME BOOLEAN_VALUE
where BOOLEAN_VALUE is either
on
or off
.
To change a Boolean value persistently, run one of the following two commands:
#
setsebool -P BOOLEAN_NAME BOOLEAN_VALUE
Alternatively, using the semanage
command:
#
semanage boolean -m --BOOLEAN_VALUE BOOLEAN_NAME
where BOOLEAN_VALUE is either
on
or off
.
A single Boolean can enable or disable several policy rules. To see
which policy rules are enabled or disabled by specific Booleans,
use the sedispol
tool to analyze the policy file:
#
sedispol /etc/selinux/targeted/policy/policy.32
As the policy rules are usually huge, we recommend setting an output file
by selecting the f
and specifying a file name. After
specifying the file name, press 6
. Then you can inspect
the file.
1.7 Tools for managing SELinux #
SLE Micro provides you with tools to manage SELinux on your system. If the below described tools are not installed on your system, install the tools by running:
#
transactional-update pkg install policycoreutils-python-utils
After successful installation, reboot the system.
1.7.1 Using the Z
option #
Where SELinux is installed and configured, you can use the
-Z
to regular commands like ls
,
id
or ps
. Using this option, you
can display the security context of files or processes. For example, with the
ls
command:
>
ls -Z /etc/shadow
system_u:object_r:shadow_t:s0 /etc/shadow
1.7.2 The chcon
command #
The command name chcon
stands for change context. The
command can change the full security context of a file to the value
provided on the CLI, or it can change parts of the context.
Alternatively, you can provide a file that serves as a reference.
To change the full security context of a file, the command syntax looks as follows:
#
chcon SECURITY_CONTEXT FILENAME
where:
SECURITY_CONTEXT is in the format: SELinux_USER:ROLE:TYPE:LEVEL:CATEGORY. For example, the context could be: system_u:object_r:httpd_config_t:s0.
FILENAME is a path to the file whose context should be changed.
To set a security context according to a provided file that serves as a
reference, run chcon
as follows:
#
chcon --reference=REFERENCE_FILE FILENAME
where:
REFERENCE_FILE is a path to a file that should be used as a reference.
FILENAME is a path to the file whose context should be changed.
Alternatively, you can change only one part of the security context. The
general syntax of the chcon
command is as follows:
#
chcon CONTEXT_OPTION CONTEXT_PART FILENAME
The options and arguments have the following meaning:
depending on the context part, CONTEXT_OPTION can be any of the following:
-u
resp--user
denotes that an SELinux user context will be changed on the provided file:
#
chcon -u system_u logind.conf-r
resp--role
only the role part will be changed in the context of the provided file:
#
chcon -r object_r logind.conf-t
resp--type
only the type part will be changed in the context of the provided file:
#
chcon -t etc_t logind.conf-l
resp--range
only the range part of the security context will be changed:
#
chcon -l s0 logind.conf
CONTEXT_PART is the particular value of the security context to be set.
FILENAME is a path to the file whose context will be changed.
chcon
on symbolic links
By default, when you change the security context on a symbolic link,
the context of the link target is changed and the symbolic link context
is not changed. To force
chcon
to change the context of the symbolic link and
not the link target, use the --no-dereference
option
as shown below:
#
chcon --no-dereference -u system_u -t etc_t network.conf
You can change the context of all files in a directory by using the recursive option:
#
chcon --recursive system_u:object_r:httpd_config_t:s0 conf.d
1.7.3 getenforce
and setenforce
commands #
The getenforce
command returns the current SELinux
mode: Enforcing
, Permissive
or
Disabled
.
#
getenforce
Permissive
The setenforce
command temporarily changes the SELinux
mode to enforcing or permissive. You cannot use this command to disable
SELinux. Remember that the change persists only until the next reboot. To
change the state permanently, follow the description in
Section 1.3.1, “Changing the SELinux mode”.
#
setenforce MODE_ID
where MODE_ID is 0
for the permissive
mode or
1 for the enforced
mode.
1.7.4 The fixfiles
script #
The script enables you to perform the following tasks with the security context:
check if the context is correct
change any incorrect file context labels
relabel your system if you added a new policy
The script syntax is as follows:
#
fixfiles [OPTIONS] ARGUMENT
where:
OPTIONS can be the following:
-l
LOGFILEsaves the output to the provided file
-o
OUTPUT_FILEsaves to the provided output file the names of all files whose file context differs from the default
-F
forces a reset of context
ARGUMENT can be one of the following:
check
shows previous and current file context for an incorrect label without performing any changes
relabel
relabels incorrect file contexts according to the currently loaded policy
restore
restores incorrect file contexts to the default values
verify
lists all files with incorrect file context labels without performing any changes
1.7.5 The semanage
command #
The semanage
command can be used to configure parts of
the policy without the need to recompile the policy from sources. The
command enables you to perform the following tasks:
manage Booleans by using the
boolean
argument. For details about Booleans, refer to Section 1.6.1, “Working with Booleans”.adjust the context of files by using the
fcontext
argumentmanage user mappings using the
login
argumentmanage SELinux users using the
user
argumentmanage SELinux policy modules using the
module
argument
The general command syntax looks as follows:
#
semanage ARGUMENT OPTIONS [OBJECT_NAME]
where:
ARGUMENT is one of the following:
login
,user
,fcontext
,boolean
,module
.OPTIONS depends on the provided ARGUMENT. Common options are described in Common options.
OBJECT_NAME, depending on the provided ARGUMENT, can be a login name, module name, file name or SELinux user.
-a
,--add
adds a provided object
-h
,--help
prints the command help
- --extract
displays commands that were used to change the system (Booleans, file context, and so on)
-l
,--list
lists all objects
-m
,--modify
modifies the provided object
-n
,--noheading
modifies the output of the listing operation by omitting headings
-s
,--seuser
specifies the SELinux user
Other options are specific to particular semanage
commands and are described in corresponding sections.
1.7.5.1 The semanage fcontext
command #
Using the semanage fcontext
command, you can perform
the following tasks:
query file context definitions
add contexts on files
add your own rules
Changes performed to the file context using the semanage
fcontext
command do not require modifications or
recompilation of the policy.
On top of the common options described in
Common options, the semanage
fcontext
command takes the following options:
-e
,--equal
The option enables you to use the context of the provided path context to label files in a different directory (the provided target path). For example, you want to assign the same context as
/home
has to an alternative home directory/export/home
. If you use this option, you need to provide the source path and the target path:#
semanage fcontext -a -e /home /export/home-f
,--ftype
To specify a file type. Use one of the following values:
a
- all files, which is also the default valueb
- a block devicec
- a character deviced
- a directoryf
- regular filesl
- a symbolic linkp
- a named pipes
- a socket
1.7.5.2 The semanage login
command #
The semanage login
enables you the perform the
following tasks:
Mapping of Linux users on a particular SELinux user. For example, to map the Linux user tux on
sysadm_u
, run the command:#
semanage login -a -s sysadm_u tux
Mapping of a group of Linux users on a particular SELinux user. For example, to map users of the writers group on
user_u
, run the command:#
semanage login -a -s user_u %writers
The group is then listed in the output of
semanage login -l
, prefixed with the % character.Keep in mind that the user group should be primary because mapping SELinux users on supplementary groups may result in incompatible mappings.
#
semanage login -m -s staff_u %writers
Mapping of Linux users on a particular SELinux MLS/MCS security range.
Modifying of the already created mapping. For this purpose, just replace the
-a
option with-m
in the previous commands.Setting the default SELinux user for new Linux users. The usual default SELinux user is
unconfined_u
. To change the value tostaff_u
, run the command:#
semanage login -m -s staff_u __default__
1.7.5.3 The semanage boolean
command #
The semanage boolean
command is used to control
Booleans in the SELinux policy.
The command synopsis looks as follows:
semanage boolean [-h] [-n] [ --extract | --deleteall | --list [-C] | --modify ( --on | --off | -1 | -0 ) boolean ]
On top of the common options, you can use the following ones specific
to the semanage boolean
command:
- --list -C
To display a list of local modifications to Booleans.
- -m --on | -1
To switch the provided Boolean on.
- -m --off | -0
To switch the provided Boolean off.
- -D, --deleteall
To delete all local modifications to Booleans.
The most common usage of the command is to switch on or off a
particular Boolean. For example, to switch on the
authlogin_yubikey
Boolean, run:
#
semanage boolean -m on authlogin_yubikey
1.7.5.4 The semanage user
command #
The semanage user
command controls the mapping
between the SELinux user and the roles and MLS/MCS levels.
On top of the common options described in
Common options, the semanage
use
command takes the following options:
- -R [ROLES], --roles [ROLES]
A list of SELinux roles. You can enclose multiple roles within double quotes and separate them by spaces, or you can use the
-R
several times.
Using this command, you can perform the following tasks:
Listing the mapping of SELinux users on roles by running:
#
semanage user -l
Changing the roles assigned to the
user_u
SELinux user:#
semanage user -m -R "system_r unconfined_r user_r"
Assigning to
admin_u
the rolestaff_r
and a categorys0
:#
semanage user -a -R "staff_r -r s0 admin_u
Creating a new SELinux user, for example,
admin_u
with thestaff_r
role. You also need to define the labeling prefix for this user by using the-P
:#
semanage user -a -R "staff_r" -P admin admin_u
1.7.5.5 The semanage module
command #
The semanage module
command can install, remove,
disable or enable SELinux policy modules.
On top of the common options described in
Common options, the semanage
fcontext
command takes the following options:
-d
,--disable
To disable the provided SELinux policy module:
#
semanage module --disable MODULE_NAME
-e
,--enable
To enable the provided SELinux policy module:
#
semanage module --enable MODULE_NAME
1.7.6 The sestatus
command #
The sestatus
gets the status of a system where SELinux
is running.
The generic syntax of the command looks as follows:
sestatus [OPTION]
When run without any options and arguments, the command outputs the following information:
#
sestatus
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: requested (insecure) Max kernel policy version: 33
The command can take the following options:
- -b
Displays the status of Booleans on the system.
- -v
Displays the security context of files and processes listed in the
/etc/sestatus.conf
file.
1.8 SELinux troubleshooting #
1.8.1 Switching on the logging service #
By default, if SELinux is the reason something is not working, a log
message to this effect is sent to the
/var/log/audit/audit.log
file. For the message to be
sent, the auditd service must be running. If you see an empty
/var/log/audit.log
, start the auditd service using
>
sudo
systemctl start auditd
and enable it in the targets of your system, using
>
sudo
systemctl enable auditd
1.8.2 The /var/log/audit
file #
The /var/log/audit
file stores messages of access
denials, service events and so on.
In
Example 1.1: “Example lines from /etc/audit/audit.log
”,
you can see a partial example of the contents of
/var/log/audit/audit.log
.
/etc/audit/audit.log
#type=DAEMON_START msg=audit(1348173810.874:6248): auditd start, ver=1.7.7 format=raw kernel=3.0.13-0.27-default auid=0 pid=4235 subj=system_u:system_r:auditd_t res=success type=AVC msg=audit(1348173901.081:292): avc: denied { write } for pid=3426 comm="smartd" name="smartmontools" dev=sda6 ino=581743 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir type=AVC msg=audit(1348173901.081:293): avc: denied { remove_name } for pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir type=AVC msg=audit(1348173901.081:294): avc: denied { unlink } for pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file type=AVC msg=audit(1348173901.081:295): avc: denied { rename } for pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582373 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file type=AVC msg=audit(1348173901.081:296): avc: denied { add_name } for pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir type=AVC msg=audit(1348173901.081:297): avc: denied { create } for pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file type=AVC msg=audit(1348173901.081:298): avc: denied { write open } for pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file type=AVC msg=audit(1348173901.081:299): avc: denied { getattr } for pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file type=AVC msg=audit(1348173901.309:300): avc: denied { append } for pid=1316
A single message looks as follows:
type=AVC msg=audit(1348173901.081:299): avc: denied { getattr } for pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
Every line of the message can be broken down into sections. For example, the sections in the last line are:
type=AVC
:Every SELinux-related audit log line starts with the type identification, for example,
type=AVC
. Note that a message with thetype=SYSCALL
that follows one with a different type and has the same value ofmsg
may provide further information regarding the event.msg=audit(1348173901.309:300)
:This is the time stamp, which is written in epoch time, the number of seconds that have passed since Jan 1, 1970. You can use
date -d
on the part up to the dot in the epoch time notation to find out when the event happened:>
date -d @1348173901
Thu Sep 20 16:45:01 EDT 2012avc: denied { append }
:The specific action that was denied. In this case, the system has denied the appending of data to a file. While browsing through the audit log file, you can see other system actions, such as write open, getattr and more.
for pid=1316
:the process ID of the command or process that initiated the action
comm="rsyslogd"
:the specific command that was associated with that PID
name="smartmontools"
:the name of the subject of the action
dev=sda6 ino=582296
:the block device and inode number of the file that was involved
scontext=system_u:system_r:syslogd_t
:the source context, which is the context of the initiator of the action
tclass=file
:a class identification of the subject
1.8.3 Analyzing /var/log/audit/audit.log
with audit2allow
#
Instead of interpreting the events in
/var/log/audit/audit.log
yourself, you can use the
audit2allow
command. The command helps analyze the
cryptic log messages in /var/log/audit/audit.log
. An
audit2allow
troubleshooting session always consists of
three different commands. First, you would use audit2allow -w
-a
to present the audit information in a more readable way. The
audit2allow -w -a
by default works on the
audit.log
file. If you want to analyze a specific
message in the audit.log file, copy it to a temporary file and analyze
the file with:
>
sudo
audit2allow -w -i FILENAME
>
sudo
audit2allow -w -i testfile
type=AVC msg=audit(1348173901.309:300): avc: denied { append } for pid=1316 comm="rsyslogd" name="acpid" dev=sda6 ino=582296 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:apmd_log_t tclass=file
- This was caused by:
A missing type enforcement (TE) allow rule.
To generate a loadable module to allow this access, run
>
sudo
audit2allow
To find out which specific rule has denied access, you can use
audit2allow -a
to show the enforcing rules from all
events that were logged into the audit.log
file, or
audit2allow -i FILENAME
to
show it for messages that you have stored in a specific file:
>
sudo
audit2allow -i testfile
#============= syslogd_t ============== allow syslogd_t apmd_log_t:file append;
To create an SELinux module with the name mymodule
that you can load to allow the access that was previously denied, run
>
sudo
audit2allow -a -R -M mymodule
If you want to do this for all events that have been logged into the
audit.log
file, use the -a -M
command arguments. To do it only for specific messages that are in a
specific file, use -i -M
as in the example below:
>
sudo
audit2allow -i testfile -M example
******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i example.pp
As indicated by the audit2allow
command, you can now
run this module by using the semodule -i
command,
followed by the name of the module that audit2allow
has created for you (example.pp
in the above
example).