In the previous article, we talked about SELinux. My impression of this security system is twofold. On the one hand, there is never too much security in IT, and SELinux contains everything you need to protect the OS and applications from unauthorized access. On the other hand, it looks too cumbersome and unnecessarily complex, which makes its use impractical. More than once or twice in the user manuals for installing commercial software, I have seen recommendations to execute setenforce 0 before starting the installation.
A solution that has half the functionality of SELinux, but is much easier to configure and operate, can be more reliable protection, if only because it is not scary to delve into all these domains, policies and roles. This is exactly what AppArmor offers.
Like SELinux, AppArmor is a Mandatory Access Control (MAC) implementation based on the Linux Security Modules (LSM) architecture. Apparmor's security model is about binding access control attributes not to users, but to programs. AppArmor provides isolation through profiles that are loaded into the kernel, usually at boot.
AppArmor differs from other Linux MAC implementations in its path-based approach, and it also allows mixing of enforcement and alert profiles. In addition, AppArmor uses file attachments to facilitate development and has a much shallower barrier to entry than SELinux itself.
DAC and MAC
The Discretionary Access Control (DAC) architecture restricts access to critical resources based on the attributes of the subjects or the group to which they belong. These attributes determine the access rights to the resources of the file system. Each admin is well aware of the importance of privileges to read (Read), recording (Write), and execution (eXecute).
These attributes apply to three categories of users: user (owner), group (group), others (other). The owner category refers to one single OS user, while a group can contain many OS users. The rest category includes those users who do not belong to the first two.
The DAC model gives the resource owner the right to determine the type of access for the specified categories of users. This differentiation of access is suitable for protecting against unintentional user actions and allows you to answer the following questions:
- What FS resources are available to a given OS user for reading, writing and executing?
- What FS resources are available to this group for reading, writing and executing?
- What FS resources are available to other users for reading, writing and executing?
- Which user has sufficient rights to run this process?
Figure: 1 DAC and MAC security systems.
The Mandatory Access Control (MAC) security system assumes centralized control over access policy rules, in which ordinary users do not have the ability to make any changes to them. The policy designer determines which programs or processes can perform certain actions on system resources. MAC focuses more on programs than on users and solves the problem of delimiting process access to OS resources.
In essence, the MAC design tries to copy the delineation of access privileges to documentation in the physical world. If a certain employee has the right to read documents marked "top secret", then he also has access to standard confidential and internal documents. The converse is however not true. The same is true in the context of the access privileges of OS processes in the MAC architecture. So, if a program can read the file / etc / sudoers, then it also has access to / etc / hosts, but the reverse is also not true.
Installing and configuring AppArmor
Basic AppArmor elements are preinstalled in Ubuntu Server, as for management tools and a set of application profiles, they must be installed separately.
[admin@server ~]$ sudo aptitude install apparmor-utils apparmor-profiles
Checking the status before setting.
[admin@server ~]$ sudo apparmor_status
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
/snap/snapd/10492/usr/lib/snapd/snap-confine
/snap/snapd/10492/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/sbin/tcpdump
...
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
The last lines indicate the enforce and complain modes. What are these regimes in short?
- In Enforce mode, the kernel enforces the rules written in the profile file. Violations are not allowed and the corresponding entry goes to the logs.
- In Complain mode, AppArmor only registers violations without blocking the actions themselves.
The content of the apparmor-profiles package is located in the folder
/usr/share/apparmor/extra-profiles/
, there are more than a hundred ready-made profiles there.
[admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |head total 484 -rw-r--r-- 1 root system 1724 May 19 2020 README drwxr-xr-x 3 root system 4096 Dec 8 10:14 abstractions/ -rw-r--r-- 1 root system 1319 May 19 2020 bin.netstat -rw-r--r-- 1 root system 1815 May 19 2020 etc.cron.daily.logrotate -rw-r--r-- 1 root system 948 May 19 2020 etc.cron.daily.slocate.cron -rw-r--r-- 1 root system 722 May 19 2020 etc.cron.daily.tmpwatch -rw-r--r-- 1 root system 2623 May 19 2020 sbin.dhclient [admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |wc -l 118
Before the profile becomes active, you need to transfer it from the folder
/usr/share/apparmor/extra-profiles/
to
/etc/apparmor.d/
. Now it can be studied and, if desired, changed. Let's take something simpler, for example
/etc/apparmor.d/bin.ping
.
...
#include <tunables/global>
profile ping /{usr/,}bin/{,iputils-}ping flags=(complain) {
#include <abstractions/base>
#include <abstractions/consoles>
#include <abstractions/nameservice>
capability net_raw,
capability setuid,
network inet raw,
network inet6 raw,
/{,usr/}bin/{,iputils-}ping mixr,
/etc/modules.conf r,
# Site-specific additions and overrides. See local/README for details.
#include <local/bin.ping>
}
Everything is pretty clear, except for the mixr flags. The description of the flag values is below:
- r - read;
- w - record
- a - incremental writing to the end of the file, from the English append;
- k - lock files;
- l - create symbolic links to executable files;
- m - loading executable files into memory;
- cx - transition to the lower level profile during execution;
- Cx - transition to the lower-level profile when executed with cleaning environment variables;
- ix - execution inheritance;
- px - requires the definition of a discrete security profile for the resource;
- Px - the definition of a discrete security profile for the resource is required, the environment variables are cleared;
- ux - do not check the launch of new processes;
- Ux - do not check the launch of new processes and clean up environment variables;
You can also specify
Capabilities
the Linux kernels that the process is allowed to use. Their full list is in the corresponding page of the manual.
To switch from learning mode to forced mode, you need to execute the command
aa-enforce <prog_name>, - aa-complain <prog_name>
. If now, after enabling the forced mode, ping tries to do something, AppArmor will block it.
[admin@server ~]$ sudo aa-enforce ping
Setting /usr/bin/ping to enforce mode.
[admin@server ~]$ sudo cp /usr/bin/man /usr/bin/ping
[admin@server ~]$ /usr/bin/ping ping
/usr/bin/ping: can't open the manpath configuration file /etc/manpath.config
If you need to create a new profile, then it is not difficult. First you need to create a template using the command
aa-autodep
, and then populate it by running
aa-genprof
. An example of an interactive dialog aa-genprof free at the link .
Used materials
- LINUX SECURITY PRIMER: SELINUX AND SMACK FRAMEWORKS
- AppArmor
- AppArmor, Russian-language documentation
