User:Pietinger/Draft/IMA
Even though this page is in the user namespace, corrections and additions are much appreciated! This is simply wiki policy, this page can be moved to the main wiki as soon as it achieves critical mass more.
I wrote this article so that I can link to it in the Gentoo forums if users have questions about it.
IMA
IMA means Integrity Measurement Architecture and is a Linux Security Module (LSM) of the kernel. I wrote this article because it is enabled in the default configuration of sys-kernel/gentoo-sources, but is not useful for most users.
Understanding IMA
There are several articles that try to explain what IMA is and how it works. I am dissatisfied with all these articles ... because they do not explain what IMA is useful for at all. It's worth noting that all articles only want to work with systemd ... If you have OpenRC, you probably won't be able to understand some things.
The usefulness of IMA also depends on how it was “put together”. Yes, there are some combinations that are useful and others that are impossible. I am trying here to explain IMA so that you understand what it is and how it works. To understand it, you need to know several things about IMA at the same time ... which unfortunately is not possible if I explain it linearly. So for now, just save the following points as given and don't ask for the meaning yet.
Before I continue, I would like to make a short excursion to SELinux. If you know it, you can skip this paragraph.
The Linux Security Module SELinux can be operated in two modes: It checks system accesses and only reports (logs) violations of the policy, or it prevents (prohibits; makes impossible) accesses if they are not permitted by the policy. Now you might think that the first mode is completely pointless, as it does not protect the system. No, there are two reasons why it is not pointless. The first reason is that as long as you don't have a policy that allows everything that is necessary, you still have to find out what should be allowed. So you could say that this “learning mode” is very helpful. The second reason is rather rare (but necessary for understanding IMA): In companies, there is often a central log server that receives log messages from other servers. This means that all log entries of all important servers are monitored 24x7 by the operating of this company on this (highly secured) log server. It is possible that a server is deliberately checked by SELinux but is still allowed to continue in the event of a security breach and this is only monitored on the log server.
Back to IMA - the main statement for IMA is:
IMA checks files (1) for changes (2) and can take action (3) if a change is detected. As soon as IMA has been activated by the system start, it can no longer be switched off (4) - not even by root.
The question immediately arises:
- WHICH (1) files, and HOW (2) does IMA check this, and WHAT (3) can IMA do? What implication (4) does this have?
- The key question would be (7): Where and how does this help me to make a system more secure?
1. The answer to the first question could be disappointing: IMA is a little bit clumsy - it can only be configured very coarsely. It is not possible to select specific files or directories, because IMA wants to check everything. So mainly you can only choose between:
1a) All files, or
1b) all files that belonging to some user - e.g. root, or
1c) all files that are executable, or
1d) all executable files that belong to some user - especially all executable files that belong root.
(There are some other possibilities regarding SELinux, but I want to hide them for now).
Which files are checked is determined by a policy that you must give to IMA. The possible ways of giving IMA a policy must be considered again. See below (5).
2. IMA checks whether a file has been changed by calculating the hash of a file and comparing it with a PRESENT hash of this file. Yes, this means that before IMA is started for the first time, a hash MUST be created for all files that are to be monitored by IMA. For example: In case (1c), this means that all executable files require a hash. However, this answer raises a new question:
If I can create a hash for all executable files, anyone can do that, can't they? See more below (6).
3. Just like SELinux, IMA can either
3a) “only” log every violation, or
3b) prevent access (complete: neither read, nor write, nor executable.) This is called “appraise” mode in IMA and is activated by the kernel command line parameter “ima_appraise=enforce”.
Now think for a moment what would happen if IMA checks all files (1a), or all files belonging root (1b) and works in this Appraise mode? What happens at system startup when DHCPCD changes the /etc/resolv.conf file? Yes, after this change IMA would forbid any access to this file ... your Linux could no longer do any DNS resolving (because no process can read this file). So this is not an option. If all files are checked, IMA can/may only be operated in monitoring mode. This "log" mode (1a/1b+3a) is used by many companies to check whether there have been changes in the system (and the operator knows that some messages are harmless; or an automatic filter removes harmless messages). The appraise mode (3b) is actually only possible with (1c) or (1d) (there are special options only if you also have SELinux in use at the same time).
4. Once IMA has been activated at system startup, nothing and nobody can switch it off. But what happens if we want to use IMA to prohibit access (3b)? What would happen if we do a world update for our Gentoo system? Any new file would no longer be readable and executable. In fact, it is no longer possible to update our executables ... at least not as long as IMA is still active (in appraise mode 3b). The only way to do an update is: We have to restart Linux - with IMA disabled. Yes, for this we either need
4a) our boot manager (or UEFI) has a second entry where it boot our kernel with a different kernel command line parameter: “ima_appraise=off”, or
4b) a second kernel (with this built-in command line parameter) on our hard disk, or
4c) a kernel (with this built-in command line parameter) on a USB stick.
5. There are predefined policies and you can use your own policy and pass it to IMA. There are actually only two ways to pass your own policy under OpenRC:
5a) A custom rc-script, or
5b) an embedded (self-built) initramfs (It must be an embedded initramfs so that an external CPIO initramfs cannot be deleted/moved).
6. If you can create a hash for a file, anyone with root access can do so. IMA would "only" protect you from automated online attacks that, for example, want to download an executable file (or modify the BASH). However, if your system has already been broken and a person with a root shell is active on your system, they can find out that IMA is active, download a file (or create a new file) and give this file a hash so that IMA accepts (and executes) this file. Therefore there is another feature:
All hashes can be signed! Yes, you can decide whether you use IMA
6a) with simple hashes, or
6b) an IMA with signed hashes (signed by IMA itself OR signed by EVM).
Of course you already know what it means to sign something. You need a key pair where you sign something with a key (Secret Key), and the other key (Open Key == Certificate) is used to check the signature for authenticity. (The secret key must of course not be on the system.) So if you want (6b), you not only have to give IMA a policy, but also the certificate, so that IMA (or EVM) can also check the signature.
7. The answer to this question will show you why IMA is so misunderstood.
If you don't have a company with an operating department that is manned 24x7, then the solution (3a) should not help you (don't forget that an intruder with root access can switch everything off, e.g. move your RC script (temporarily) and delete the /var/log/messages and then do a reboot; read more in 8 ).
However, if you want to use IMA in Appraise mode (3b), you will have to accept a reboot before every world-update (and also after that to get back to a kernel booted with activated IMA). Yes, if you cannot install pre-compiled packages WITH already signed files (from a build-server; unfortunately we don't currently have with Gentoo) you need a way to reboot the system with IMA disabled. Perhaps this is one reason why so few (Gentoo) people want to install IMA in this mode. This leads to a new question - really the last one:
8. If I can do reboot an other kernel (without activated IMA), can IMA protect me in any way ?
Now we have to distinguish between an (8a) online attack and an (8b) offline tampering (=intruder has physical access to the computer and can boot his own bootCD):
8a) This depends on whether the attacker is running an automated routine online or whether the attacker has a root shell online and can look around on your system.
The “simple” solutions (3b+4a/4b+5a+6a) already help against automated attacks, but not against online root shell attacks (or offline tampering).
To secure AFTER an online intrusion with root shell, you must be the only one who can use a kernel with IMA disabled. This means you must not provide a way to reboot to a kernel that has IMA disabled. This means that options (4a), (4b) and (5a) are unsafe. You will need a kernel on an external medium (e.g. USB stick). This is solution (3b+4c+5b+6b).
8b) To protect yourself against offline tampering, you also need the secure solution from (8a) (=3b+4c+5b+6b) and additionally SecureBoot. The attacker cannot even use his own boot CD as long as they cannot disable SecureBoot. However, if they does this (by resetting the BIOS), you will see during the next boot process that SecureBoot has no longer taken place (this is also the reason why you shut down a machine every time you leave it for a longer period of time and only start the system when you use it again - then you have to check if SecureBoot was active).
Other articles
Perhaps you would like to read this now: https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture
Would you really have understood IMA with this article?
Of course we also have an article about IMA in our Wiki: Integrity_Measurement_Architecture
Summary
You can only use IMA sensibly if you either use a build server, accept having to reboot before and after every “emerge”, or have a 24x7 operating department.
IMA cannot protect you from an intrusion into your system - it protects you after an intrusion has happened.
Either by preventing any modification of executable files, or at least by alerting you that something has been changed. But it does not prevent the copying of files to a remote server ... IMA is therefore only a PART of a security strategy and requires other parts, such as the use of MAC (SELinux or AppArmor), a hardened kernel, a firewall, filtering of internet user traffic (proxies) and encryption of important data.
You could compare this to the two castle walls of a medieval castle: SELinux + the hardened kernel + firewall are the first, outer castle wall. If this has been stormed, then IMA should try to protect the system further as the second, inner castle wall.