Security Guide
- About This Guide
- 1 Security and Confidentiality
- I Authentication
- II Local Security
- III Network Security
- IV Confining Privileges with AppArmor
- 18 Introducing AppArmor
- 19 Getting Started
- 20 Immunizing Programs
- 21 Profile Components and Syntax
- 22 AppArmor Profile Repositories
- 23 Building and Managing Profiles with YaST
- 24 Building Profiles from the Command Line
- 25 Profiling Your Web Applications Using ChangeHat
- 26 Confining Users with
pam_apparmor - 27 Managing Profiled Applications
- 28 Support
- 29 AppArmor Glossary
- V SELinux
- VI The Linux Audit Framework
- A GNU Licenses
30 Configuring SELinux
In this chapter, you will learn how to set up and manage SELinux on openSUSE Leap. The following topics are covered:
Why Use SELinux?
Understanding SELinux
Setting Up SELinux
Managing SELinux
30.1 Why Use 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 what is offered by the default existing permissions of Read, Write, and Execute, and beyond assigning permissions to the different capabilities that are available on Linux. SELinux does this by trapping all system calls that reach the kernel, and denying them by default. This means that on a system that has SELinux enabled and nothing else configured, nothing will work. To allow your system to do anything, as an administrator you will need to write rules and put them in a policy.
An example explains why a solution such as SELinux (or its counterpart AppArmor) is needed:
“One morning, I found out that my server was hacked. The server was
running a fully patched SLES installation. A firewall was configured on
it and no unnecessary services were offered by this server. Further
analysis learned that the hacker had come in through a flaky PHP script
that was a part of one of the Apache virtual hosts that were running on
this server. The intruder had managed to get access to a shell, using the
wwwrun account that was used by
the Apache Web server. As this
wwwrun user, the intruder had
created several scripts in the /var/tmp and the
/tmp directories, which were a part of a botnet that
was launching a Distributed Denial of Service attack against several
servers.”
The interesting thing about this hack is that it occurred on a server where nothing was really wrong. All permissions where set OK, but the intruder had managed to get into the system. What becomes clearly evident from this example is that in some cases additional security is needed—a security that goes beyond what is offered by using SELinux. As a less complete and less complex alternative, AppArmor can be used.
AppArmor confines specific processes in their abilities to read/write and execute files (and other things). Its view is mostly that things that happen inside a process cannot escape.
SELinux instead uses labels attached to objects (for example, files, binaries, network sockets) and uses them to determine privilege boundaries, thereby building up a level of confinement that can span more than a process or even the whole system.
SELinux was developed by the US National Security Agency (NSA), and since the beginning Red Hat has been heavily involved in its development. The first version of SELinux was offered in the era of Red Hat Enterprise Linux 4™, around the year 2006. In the beginning it offered support for essential services only, but over the years it has developed into a system that offers many rules that are collected in policies to offer protection to a broad range of services.
SELinux was developed in accordance with some certification standards like Common Criteria and FIPS 140. Because some customers specifically requested solutions that met these standards, SELinux rapidly became relatively popular.
As an alternative to SELinux, Immunix, a company that was purchased by Novell in 2005, had developed AppArmor. AppArmor was built on top of the same security principles as SELinux, but took a completely different approach, where it was possible to restrict services to exactly what they needed to do by using an easy to use wizard-driven procedure. Nevertheless, AppArmor has never reached the same status as SELinux, even if there are some good arguments to secure a server with AppArmor rather than with SELinux.
Because many organizations are requesting SELinux to be in the Linux distributions they are using, SUSE is offering support for the SELinux framework in openSUSE Leap. This does not mean that the default installation of openSUSE Leap will switch from AppArmor to SELinux in the near future.
30.1.1 Support Status #
The SELinux framework is supported on openSUSE Leap. This means that openSUSE Leap offers all binaries and libraries you need to be able to use SELinux on your server. You may however miss some software that you may be familiar with from other Linux distributions.
SELinux support is at a fairly early stage in openSUSE Leap, which means that unexpected behavior may occur. To limit this risk as much as possible, it is best to use only the binaries that have been provided by default on openSUSE Leap.
30.1.2 Understanding SELinux Components #
Before starting the configuration of SELinux, you should know a bit about how SELinux is organized. Three components play a role:
The security framework in the Linux kernel
The SELinux libraries and binaries
The SELinux policy
The default kernel of openSUSE Leap supports SELinux and the tools that are needed to manage it. The most important part of the work of the administrator with regard to SELinux is managing the policy.
In the SELinux policy, security labels are applied to different objects on a Linux server. These objects typically are users, ports, processes and files. Using these security labels, rules are created that define what is and what is not allowed on a server. Remember, by default SELinux denies everything, and by creating the appropriate rules you can allow the access that is strictly necessary. Rules should therefore exist for all programs that you want to use on a system. Alternatively, you should configure parts of a system to run in unconfined mode, which means that specific ports, programs, users, files and directories are not protected by SELinux. This mode is useful if you only want to use SELinux to protect some essential services, while you are not specifically worried about other services. To get a really secure system, you should avoid this.
To ensure the appropriate protection of your system, you need an SELinux policy. This must be a tailor-made policy in which all files are provided with a label, and all services and users have a security label as well to express which files and directories can be accessed by which user and processed on the server. Developing such a policy is a tremendous amount of work.
The complexity of SELinux is also one of the main arguments against using it. Because a typical Linux system is so very complex, it is easy to overlook something and leave an opening that intruders can abuse to get into your system. And even if it is set up completely the way it should be, it still is very hard for an administrator to overlook all aspects with SELinux. With regard to the complexity, AppArmor takes a completely different approach and works with automated procedures that allow the administrator to set up AppArmor protection and understand exactly what is happening.
Note that a freely available SELinux policy might work on your server, but is unlikely to offer the same protection as a custom policy. SUSE also does not support third-party policies.
30.2 Policy #
As mentioned, the policy is the key component in SELinux. It 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. On an SELinux system where the policy has been
applied to label the file system, you can use the ls
-Z command on any directory to find the security context for
the files in that directory.
Example 30.1: “Security Context Settings Using ls -Z”
shows the security context settings for the directories in the
/ directory of a openSUSE Leap system with an
SELinux-labeled file system.
Example 30.1: Security Context Settings Using ls -Z #
ls -Z system_u:object_r:bin_t bin system_u:object_r:boot_t boot system_u:object_r:device_t dev system_u:object_r:etc_t etc system_u:object_r:home_root_t home system_u:object_r:lib_t lib system_u:object_r:lib_t lib64 system_u:object_r:lost_found_t lost+found system_u:object_r:mnt_t media system_u:object_r:mnt_t mnt system_u:object_r:usr_t opt system_u:object_r:proc_t proc system_u:object_r:default_t root system_u:object_r:bin_t sbin system_u:object_r:security_t selinux system_u:object_r:var_t srv system_u:object_r:sysfs_t sys system_u:object_r:tmp_t tmp system_u:object_r:usr_t usr system_u:object_r:var_t var
The most important line in the security context is the context type. This is the part of the security context that ends in _t. It tells SELinux which kind of access the object is allowed. In the policy, rules are specified to define which type of user or which type of role has access to which type of context. For example, this can happen by using a rule like the following:
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 class "file"
with the context type bin_t (the target), using the
permissions read, execute and getattr.
The standard policy that you are going to use contains a huge amount of rules. To make it more manageable, policies are often split into modules. This allows 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. It is strongly recommended to use a modular policy and not a monolithic policy. Modular policies are much easier to manage.
30.3 Installing SELinux Packages and Modifying GRUB 2 #
The easiest way to make sure that all SELinux components are installed is by using YaST. The procedure described below shows what to do on an installed openSUSE Leap:
Log in to your server as
rootand start YaST.Select ›
› and select the entire C category for installation.
› and make sure that , and are selected. Now enter the keyword
selinuxand click . You now see a list of packages.Make sure that all the packages you have found are selected and click to install them.
Figure 30.1: Selecting all SELinux Packages in YaST #
After installing the SELinux packages, you need to modify the GRUB 2 boot loader. Do this from YaST, select › › . Now add the following parameters to the :
security=selinux selinux=1 enforcing=0
These options are used for the following purposes:
security=selinuxThis option tells the kernel to use SELinux and not AppArmor
selinux=1This option switches on SELinux
enforcing=0This option puts SELinux in permissive mode. In this mode, SELinux is fully functional, but does not enforce any of the security settings in the policy. Use this mode for configuring your system. To switch on SELinux protection, when the system is fully operational, change the option to
enforcing=1and addSELINUX=enforcingin/etc/selinux/config.
After installing the SELinux packages and enabling the SELinux GRUB 2 boot options, reboot your server to activate the configuration.
30.4 SELinux Policy #
The policy is an essential component of SELinux. openSUSE Leap 42.2 includes the minimum SELinux reference policy in the package selinux-policy-minimum. The examples in this chapter refer to this policy if not stated otherwise.
Tip
To install a different policy, you need to download it from https://build.opensuse.org/package/binaries/security:SELinux/selinux-policy?repository=SLE_12 and install:
sudo zypper in selinux-policy-targeted-version_number.noarch.rpm
After installing the policy, you are ready to start file system labeling. Run
restorecon -Rv /
to start the /sbin/setfiles command to label all files
on your system. The
/etc/selinux/minimum/contexts/files/file_contexts
input file is used. The file_contexts file needs to
match your actual file system as much as possible. Otherwise, it can lead
to a completely unbootable system. If that happens, modify the records in
file_contexts with the semanage
fcontext command to match the real structure of the file system
your server is using. For example
semanage fcontext -a -t samba_share_t /etc/example_file
changes the file type from the default etc_t to
samba_share_t and adds the following record to the
related file_contexts.local file:
/etc/example_file unconfined_u:object_r:samba_share_t:s0
Then run
restorecon -v /etc/example_file
for the type change to take effect.
Before doing this, make sure to read the rest of this chapter, so you
fully understand how context type is applied to files and directories. Do
not forget to make a backup of the file_contexts
file before starting.
Note: The User nobody
While using semanage, you may get a message that
complains about the home directory of
nobody. In this case, change
the login shell of user nobody
to /sbin/nologin. Then the settings of
nobody match the current
policy settings.
After another reboot SELinux should be operational. To verify this, use
the command sestatus -v. It should give you an output
similar to
Example 30.2: “Verifying that SELinux is functional”.
Example 30.2: Verifying that SELinux is functional #
sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 26 Policy from config file: minimum Process contexts: Current context: root:staff_r:staff_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:sysadm_t /usr/sbin/sshd system_u:system_r:sshd_t File contexts: Controlling term: root:object_r:user_devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
30.5 Configuring SELinux #
At this point you have a completely functional SELinux system and it is
time to further configure it. In the current status, SELinux is
operational but not in enforcing mode. This means that it does not limit
you in doing anything, it logs everything that it should be doing if it
were in enforcing mode. This is good, because based on the log files you
can find what it is that it would prevent you from doing. As a first
test, put SELinux in enforcing mode and find out if you can still use
your server after doing so: check that the option
enforcing=1 is set in the GRUB 2 configuration file,
while SELINUX=enforcing is set in
/etc/selinux/config. Reboot your server and see if
it still comes up the way you expect it to. If it does, leave it like
that and start modifying the server in a way that everything works as
expected. However, you may not even be able to boot the server properly.
In that case, switch back to the mode where SELinux is not enforcing and
start tuning your server.
Before you start tuning your server, verify the SELinux installation.
You have already used the command sestatus -v to view
the current mode, process, and file contexts. Next, run
semanage boolean -l
which lists all Boolean switches that are available, and at the same time verifies that you can access the policy. Example 30.3, “Getting a List of Booleans and Verifying Policy Access” shows part of the output of this command.
Example 30.3: Getting a List of Booleans and Verifying Policy Access #
semanage boolean -l SELinux boolean Description ftp_home_dir -> off ftp_home_dir mozilla_read_content -> off mozilla_read_content spamassassin_can_network -> off spamassassin_can_network httpd_can_network_relay -> off httpd_can_network_relay openvpn_enable_homedirs -> off openvpn_enable_homedirs gpg_agent_env_file -> off gpg_agent_env_file allow_httpd_awstats_script_anon_write -> off allow_httpd_awstats_script_anon_write httpd_can_network_connect_db -> off httpd_can_network_connect_db allow_ftpd_full_access -> off allow_ftpd_full_access samba_domain_controller -> off samba_domain_controller httpd_enable_cgi -> off httpd_enable_cgi virt_use_nfs -> off virt_use_nfs
Another command that outputs useful information at this stage is
semanage fcontext -l
It shows the default file context settings as provided by the policy (see Example 30.4: “Getting File Context Information” for partial output of this command).
Example 30.4: Getting File Context Information #
semanage fcontext -l /var/run/usb(/.*)? all files system_u:object_r:hotplug_var_run_t /var/run/utmp regular file system_u:object_r:initrc_var_run_t /var/run/vbe.* regular file system_u:object_r:hald_var_run_t /var/run/vmnat.* socket system_u:object_r:vmware_var_run_t /var/run/vmware.* all files system_u:object_r:vmware_var_run_t /var/run/vpnc(/.*)? all files system_u:object_r:vpnc_var_run_t /var/run/watchdog\.pid regular file system_u:object_r:watchdog_var_run_t /var/run/winbindd(/.*)? all files system_u:object_r:winbind_var_run_t /var/run/wnn-unix(/.*) all files system_u:object_r:canna_var_run_t /var/run/wpa_supplicant(/.*)? all files system_u:object_r:NetworkManager_var_run_t /var/run/wpa_supplicant-global socket system_u:object_r:NetworkManager_var_run_t /var/run/xdmctl(/.*)? all files system_u:object_r:xdm_var_run_t /var/run/yiff-[0-9]+\.pid regular file system_u:object_r:soundd_var_run_t
30.6 Managing SELinux #
The base SELinux configuration is now operational and it can now be configured to secure your server. In SELinux, an additional set of rules is used to define exactly which process or user can access which files, directories, or ports. To do this, SELinux applies a context to every file, directory, process, and port. This context is a security label that defines how this file, directory, process, or port should be treated. These context labels are used by the SELinux policy, which defines exactly what should be done with the context labels. By default, the policy blocks all non-default access, which means that, as an administrator, you need to enable all features that are non-default on your server.
30.6.1 Viewing the Security Context #
As already mentioned, files, directories, and ports can be labeled.
Within each label, different contexts are used. To be able to perform
your daily administration work, the type context is what you are most
interested in. As an administrator, you will mostly work with the type
context. Many commands allow you to use the -Z option
to list current context settings. In
Example 30.5: “The default context for directories in the root directory”
you can see what the context settings are for the directories in the
root directory.
Example 30.5: The default context for directories in the root directory #
ls -Z dr-xr-xr-x. root root system_u:object_r:bin_t:s0 bin dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot drwxr-xr-x. root root system_u:object_r:cgroup_t:s0 cgroup drwxr-xr-x+ root root unconfined_u:object_r:default_t:s0 data drwxr-xr-x. root root system_u:object_r:device_t:s0 dev drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib64 drwx------. root root system_u:object_r:lost_found_t:s0 lost+found drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media drwxr-xr-x. root root system_u:object_r:autofs_t:s0 misc drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 mnt2 drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 mounts drwxr-xr-x. root root system_u:object_r:autofs_t:s0 net drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt dr-xr-xr-x. root root system_u:object_r:proc_t:s0 proc drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 repo dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root dr-xr-xr-x. root root system_u:object_r:bin_t:s0 sbin drwxr-xr-x. root root system_u:object_r:security_t:s0 selinux drwxr-xr-x. root root system_u:object_r:var_t:s0 srv -rw-r--r--. root root unconfined_u:object_r:swapfile_t:s0 swapfile drwxr-xr-x. root root system_u:object_r:sysfs_t:s0 sys drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp -rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 tmp2.tar -rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 tmp.tar drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr drwxr-xr-x. root root system_u:object_r:var_t:s0 var
In the listing above, you can see the complete context for all
directories. It consists of a user, a role, and a type. The s0 setting
indicates the security level in Multi Level Security environments. These
environments are not discussed here. In such an environment, make sure
that s0 is set. The Context Type defines what kind of activity is
permitted in the directory. Compare, for example, the
/root directory, which has the
admin_home_t context type, and the
/home directory, which has the
home_root_t context type. In the SELinux policy,
different kinds of access are defined for these context types.
Security labels are not only associated with files, but also with other
items, such as ports and processes. In
Example 30.6: “Showing SELinux settings for processes with ps Zaux”
for example you can see the context settings for processes on your
server.
Example 30.6: Showing SELinux settings for processes with ps Zaux #
ps Zaux LABEL USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND system_u:system_r:init_t root 1 0.0 0.0 10640 808 ? Ss 05:31 0:00 init [5] system_u:system_r:kernel_t root 2 0.0 0.0 0 0 ? S 05:31 0:00 [kthreadd] system_u:system_r:kernel_t root 3 0.0 0.0 0 0 ? S 05:31 0:00 [ksoftirqd/0] system_u:system_r:kernel_t root 6 0.0 0.0 0 0 ? S 05:31 0:00 [migration/0] system_u:system_r:kernel_t root 7 0.0 0.0 0 0 ? S 05:31 0:00 [watchdog/0] system_u:system_r:sysadm_t root 2344 0.0 0.0 27640 852 ? Ss 05:32 0:00 /usr/sbin/mcelog --daemon --config-file /etc/mcelog/mcelog.conf system_u:system_r:sshd_t root 3245 0.0 0.0 69300 1492 ? Ss 05:32 0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid system_u:system_r:cupsd_t root 3265 0.0 0.0 68176 2852 ? Ss 05:32 0:00 /usr/sbin/cupsd system_u:system_r:nscd_t root 3267 0.0 0.0 772876 1380 ? Ssl 05:32 0:00 /usr/sbin/nscd system_u:system_r:postfix_master_t root 3334 0.0 0.0 38320 2424 ? Ss 05:32 0:00 /usr/lib/postfix/master system_u:system_r:postfix_qmgr_t postfix 3358 0.0 0.0 40216 2252 ? S 05:32 0:00 qmgr -l -t fifo -u system_u:system_r:crond_t root 3415 0.0 0.0 14900 800 ? Ss 05:32 0:00 /usr/sbin/cron system_u:system_r:fsdaemon_t root 3437 0.0 0.0 16468 1040 ? S 05:32 0:00 /usr/sbin/smartd system_u:system_r:sysadm_t root 3441 0.0 0.0 66916 2152 ? Ss 05:32 0:00 login -- root system_u:system_r:sysadm_t root 3442 0.0 0.0 4596 800 tty2 Ss+ 05:32 0:00 /sbin/mingetty tty2
30.6.2 Selecting the SELinux Mode #
In SELinux, three different modes can be used:
- Enforcing:
This is the default mode. SELinux protects your server according to the rules in the policy, and SELinux logs all of its activity to the audit log.
- Permissive:
This mode is useful for troubleshooting. If set to Permissive, SELinux does not protect your server, but it still logs everything that happens to the log files.
- Disabled:
In this mode, SELinux is switched off completely and no logging occurs. The file system labels however are not removed from the file system.
You have already read how you can set the current SELinux mode from GRUB 2 while booting using the enforcing boot parameter.
30.6.3 Modifying SELinux Context Types #
An important part of the work of an administrator is setting context types on files to ensure appropriate working of SELinux.
If a file is created within a specific directory, it inherits the context type of the parent directory by default. If, however, a file is moved from one location to another location, it retains the context type that it had in the old location.
To set the context type for files, you can use the semanage
fcontext command. With this command, you write the new context
type to the policy, but it does not change the actual context type
immediately! To apply the context types that are in the policy, you need
to run the restorecon command afterward.
The challenge when working with semanage fcontext is
to find out which context you actually need. You can use
semanage fcontext -l
to list all contexts in the policy, but it may be a bit hard to find out the actual context you need from that list as it is rather long (see Example 30.7: “Viewing Default File Contexts”).
Example 30.7: Viewing Default File Contexts #
semanage fcontext -l | less SELinux fcontext type Context / directory system_u:object_r:root_t:s0 /.* all files system_u:object_r:default_t:s0 /[^/]+ regular file system_u:object_r:etc_runtime_t:s0 /\.autofsck regular file system_u:object_r:etc_runtime_t:s0 /\.autorelabel regular file system_u:object_r:etc_runtime_t:s0 /\.journal all files X:>>None>> /\.suspended regular file system_u:object_r:etc_runtime_t:s0 /a?quota\.(user|group) regular file system_u:object_r:quota_db_t:s0 /afs directory system_u:object_r:mnt_t:s0 /bin directory system_u:object_r:bin_t:s0 /bin/.* all files system_u:object_r:bin_t:s0
There are three ways to find out which context settings are available for your services:
Install the service and look at the default context settings that are used. This is the easiest and recommended option.
Consult the man page for the specific service. Some services have a man page that ends in
_selinux, which contains all the information you need to find the correct context settings.When you have found the right context setting, apply it using
semanage fcontext. This command takes-tcontext type as its first argument, followed by the name of the directory or file to which you want to apply the context settings. To apply the context to everything that already exists in the directory where you want to apply the context, you add the regular expression(/.*)?to the name of the directory. This means: optionally, match a slash followed by any character. The examples section of thesemanageman page has some useful usage examples forsemanage. For more information on regular expressions, see for example the tutorial at http://www.regular-expressions.info/.Display a list of all context types that are available on your system:
seinfo -t
Since the command by itself outputs an overwhelming amount of information, it should be used in combination with
grepor a similar command for filtering.
30.6.4 Applying File Contexts #
To help you apply the SELinux context properly, the following
procedure shows how to set a context using semanage
fcontext and restorecon. You will
notice that at first attempt, the Web server with a non-default
document root does not work. After changing the SELinux context,
it will:
Create the
/webdirectory and then change to it:sudo mkdir /web && cd /web
Use a text editor to create the file
/web/index.htmlthat contains the text welcome to my Web site.Open the file
/etc/apache2/default-server.confwith an editor, and change the DocumentRoot line toDocumentRoot /webStart the Apache Web server:
sudo systemctl start apache2
Open a session to your local Web server:
w3m localhost
You will receive a Connection refused message. Press Enter, and then
qto quit w3m.Find the current context type for the default Apache
DocumentRoot, which is/srv/www/htdocs. It should be set tohttpd_sys_content_t:ls -Z /srv/www
Set the new context in the policy and press Enter:
semanage fcontext -a -f "" -t httpd_sys_content_t '/web(/.*) ?'
Apply the new context type:
restorecon /web
Show the context of the files in the directory
/web. You will see that the new context type has been set properly to the/webdirectory, but not to its contents.ls -Z /web
Apply the new context recursively to the
/webdirectory. The type context has now been set correctly.restorecon -R /web
Restart the Web server:
sudo systemctl restart apache2
You should now be able to access the contents of the
/webdirectory.
30.6.5 Configuring SELinux Policies #
The easiest way to change the behavior of the policy is by working with Booleans. These are on-off switches that you can use to change the settings in the policy. To find out which Booleans are available, run
semanage boolean -l
It will show a long list of Booleans, with a short description of
what each of these Booleans will do for you. When you have found the
Boolean you want to set, you can use setsebool -P,
followed by the name of the Boolean that you want to change. It is
important to use the -P option at all times when using
setsebool. This option writes the setting to the
policy file on disk, and this is the only way to make sure that the
Boolean is applied automatically after a reboot.
The procedure below gives an example of changing Boolean settings
List Booleans that are related to FTP servers.
semanage boolean -l | grep ftp
Turn the Boolean off:
setsebool allow_ftpd_anon_write off
Note that it does not take much time to write the change. Then verify that the Boolean is indeed turned off:
semanage boolean -l|grep ftpd_anon
Reboot your server.
Check again to see if the
allow_ftpd_anon_writeBoolean is still turned on. As it has not yet been written to the policy, you will notice that it is off.Switch the Boolean and write the setting to the policy:
setsebool -P allow_ftpd_anon_write
30.6.6 Working with SELinux Modules #
By default, SELinux uses a modular policy. This means that the
policy that implements SELinux features is not just one huge policy, but
it consists of many smaller modules. Each module covers a specific part
of the SELinux configuration. The concept of the SELinux module was
introduced to make it easier for third party vendors to make their
services compatible with SELinux. To get an overview of the SELinux
modules, you can use the semodule -l command. This
command lists all current modules in use by SELinux and their
version numbers.
As an administrator, you can switch modules on or off. This can be useful if you want to disable only a part of SELinux and not everything to run a specific service without SELinux protection. Especially in the case of openSUSE Leap, where there is not a completely supported SELinux policy yet, it can make sense to switch off all modules that you do not need so that you can focus on the services that really do need SELinux protection. To switch off an SELinux module, use
semodule -d modulename
If you want to switch it on again, you can use
semodule -e modulename
As an administrator, you do not typically change the contents of the
policy files that come from the SELinux Policy RPM. You would rather use
semanage fcontext to change file contexts. If you are
using audit2allow to generate policies for your
server, you should change the policy files after all.
To change the contents of any of the policy module files,
compile the changes into a new policy module file. To do this,
first install the selinux-policy-devel package.
Then, in the directory where the files created by
audit2allow are located, run:
make -f /usr/share/selinux/devel/Makefile
When make has completed, you can manually load the
modules into the system, using semodule -i.
30.7 Troubleshooting #
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. That is, if the
auditd service is running. If you see an empty
/var/log/audit, start the auditd service using
sudo systemctl start auditd
and enable it in the targets of your system, using
sudo systemctl enable auditd
In
Example 30.8: “Example Lines from /etc/audit/audit.log”
you can see a partial example of the contents of
/var/log/audit/audit.log
Example 30.8: Example Lines from /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
At first look, the lines in audit.log are a bit hard
to read. However, on closer examination they are not that hard to
understand. Every line 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
type=AVCmsg=audit(1348173901.309:300):This is the time stamp, which unfortunately is written in epoch time, the number of seconds that have passed since Jan 1, 1970. You can use
date -don the part up to the dot in the epoch time notation to find out when the event has happened:date -d @1348173901 Thu Sep 20 16:45:01 EDT 2012
avc: 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
Instead of interpreting the events in audit.log yourself, there is
another approach. You can use the audit2allow command,
which 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:
audit2allow -w -i file_name
Example 30.9: Analyzing Audit Messages #
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:
Missing type enforcement (TE) allow rule.
To generate a loadable module to allow this access, run
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 to the audit.log file, or
audit2allow -i file_name to
show it for messages that you have stored in a specific file:
Example 30.10: Viewing Which Lines Deny Access #
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
audit2allow -a -R -M mymodule
If you want to do this for all events that have been logged to the
audit.log, 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:
Example 30.11: Creating a Policy Module Allowing an Action Previously Denied #
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).