Introduction
This blog will describe how you can make use of digital signature based IMA appraisal to enforce the run time integrity of immutable files – and to ensure the authenticity of all Oracle supplied components within their run time environment. Measurement for mutable files is also possible, but is beyond the scope of this blog.
Integrity measurement has been built into every version of UEK, but the required digital signatures are only available starting in OL9. Starting with OL9, Oracle digitally signs all executable files contained within every rpm at build time.
Beginning with Oracle Linux 9, customers can use IMA to appraise whether an executable has been accidentally or intentionally modified from its original version. IMA, Linux’s Integrity Measurement Architecture, is a highly customizable policy based security framework. In this article, we’ll be focusing on digital signature based IMA.
Background
IMA appraisal can be used with either hashes or digital signatures. Both methods store either the hash or the signature in an extended attribute. Later, when the file is opened, the extended attribute is verified and the user defined policy based action is taken if the appraisal fails.
Until the release of OL9, hash based IMA appraisal was the most common method used. This involved the end-user generating a hash for every file on their machine. Afterwards, IMA could be used to validate if the hash was correct. This approach was not without gaps and required the use of Extended Verification Module (EVM) to protect the filesystem extended attributes. Without using EVM, this method of appraisal was susceptible to an offline attack since the hash can easily be generated and stored in the extended attribute.
With OL9, it is now possible to use digital signature based IMA appraisal. Offline modifications to extended attributes are not possible with this approach, since the extended attribute is now an Oracle signature. This reduces the burden on the administrators of the system and enables rapid deployment of this feature to significantly enhance the security and integrity posture of the system.
The rest of this blog describes various approaches to install and set up digital signature based IMA appraisal in OL9 and walks through a simple IMA policy to get started with using the feature.
IMA RPM Plugin
IMA uses a security extended file attribute called security.ima. With a standard OL9 install, the signature is NOT added to the extended attribute by default. In order for this extended file attribute to be applied when a RPM is installed, a package called rpm-plugin-ima must be installed first.
Installation Methods
There are various ways to install this feature, three different methods are described below. It is important to note that enabling an IMA policy to use digital signature base IMA appraisal on a machine that was not installed with the rpm-plugin-ima will not function properly. Each of the installation methods uses the rpm-plugin-ima in some fashion.
Add Signatures to a Preinstalled OL9 Setup
This is not the preferred installation method, but a preinstalled OL9 setup can be converted to have the security.ima extended attributes applied to all immutable files. This is an easy way to do an evaluation of this feature. Before beginning, make sure the system is running the latest version of OL9.
With a standard OL9 install, the signature is NOT added to the extended attribute by default. To see this, the getfattr command can be used to view the extended attributes. For example, the security.ima extended attribute for vim can be viewed:
$ getfattr -m security.ima -d /usr/bin/vim
Here nothing is returned.
The new rpm-plugin-ima rpm must be installed for the extended attributes to be applied:
$ dnf install rpm-plugin-ima
After this rpm is installed, any new rpms added or updated on the machine shall have the security.ima extended attribute added. With the example above, do a reinstall of vim:
$ dnf reinstall vim-enhanced
and check the extended attributes with getfattr:
$ getfattr -m security.ima -d /usr/bin/vim getfattr: Removing leading '/' from absolute path names # file: usr/bin/vim security.ima=0sAwIEmiKuyQIAVIJ2Fz80fFOllixdq8GMa6TkCuIjZ4mqskLdF3vhdEOIS2+66EF1cD/y7ZeD8ZlHPh2OuaC6MOqCkLrWcoO76iLIN8RHjwJj0Zb9xM3JPVcb771GXQY2qA71ITXW46Gd6/ynUGhB4py8+dhksOv3/DkOWCrejKyGNDGzyKF336gIWRyryAE3hi0NOvU/iTLmHBWD7GOD6mXQKrs5X7z0k1BF1/UGRA6KFhN/B5g1LgnZMVbdtp7AGqeI8jGu2MwP+wNESmBxTdWbr45mnseXaSPUesQG8ODwxuvzy5bdGq3PDZexQoETImXADTOIYpkfVMjvCyFUdhChwZe8dEmdXN3jCFd4sLlbRKBObodJvx7YuxHOsOGRmnGN/RtYWM3xM09qHKu+669GD1YZdWnEmyToCMFYv5+uLGipMwG5N0u0GFb7KQImp6h6snBw+MxtlcbJMGAdox23UCPbr2tVtrH4MP+CnwaY3fK0MQA01jU1BaIacBS3oeJY6q45GhSvAdICDP7joOP5chvuj7U8+sxBmVQ5BfED1mDM3K8rtE3KXtKY1QNX5VWejTRz6V8z5CLHZGbpWceHiSQ+DfoQANisYgA5j6LhGXWkMfVsEWC1Ut9MKNIyC6Qj1/ioZcC4tjPk9uJaJpN8Vg4RMvkgRC5KdhAgL82wrl3XHdy2iOQ=
After rpm-plugin-ima is installed, all new rpms added to the machine will have the extended attribute applied. Anything installed prior to then will not. Therefore, on a currently running OL9 machine, it is necessary to reinstall every rpm with the following command:
$ dnf reinstall '*'
All immutable files will now contain the security.ima extended attribute.
Kickstart Installation Method
If the use of kickstart install is preferred, a few additional lines need to be added to the kickstart script. First, the rpm-plugin-ima package must be added. Find the %packages section in the kickstart and add:
rpm-plugin-ima
At the bottom of the kickstart add:
%pre-install --interpreter /bin/bash cd / rpm2cpio /run/install/repo/AppStream/Packages/rpm-plugin-ima-*.rpm | cpio -idmv %end
This pre-install script will add the rpm plugin to the installer. The installer will then apply the signatures appropriately.
Oracle Linux Image Tools Installation Method
Oracle Linux Image Tools provide another method to create an install image. Oracle has a git repository that provides tools to build Oracle Linux images for cloud deployment [1]. With just a few modifications to the provided properties file, an image can be created [2].
A modified version has been created to build an OL9 image with IMA support. Currently, this version is located here [3].
To use this modified version, make sure the env.properties file contains:
DISTR=ol9-ima-slim KERNEL=uek
Signing keys
The keys within the .ima keyring are used for signature validation. The public signing key for all IMA components is located in /etc/keys/x509_ima.der.
Using the keyctl show command, verify that the IMA key has been loaded into the .ima keyring . If two keys are shown as below, everything is setup correctly.
$ keyctl show %:.ima Keyring 992191781 ---lswrv 0 0 keyring: .ima 46567484 ---lswrv 0 0 \_ asymmetric: Oracle CA Server: 5952d573978004cefc13a65d13eb7fa4d302af63 290840318 ---lswrv 0 0 \_ asymmetric: Oracle IMA signing key: 197a175bd58f2a0b3552c9f2df10c4c09a22aec9
Any number of keys can be added to IMA keyring; however, they must be signed by a system kernel key. The system kernel keys comprise of the .builtin, .secondary_trusted_keyring or the .machine keyrings. Only the machine owner can make changes to the system keyrings. This makes it so root cannot arbitrarily install any key into the .ima keyring.
Setting up IMA Policy
The IMA policy [4] can be constructed to do digital signature based IMA appraisal. This section describes a fairly simple policy. It is up to the end user to determine the correct policy that covers their needs.
In this example, the IMA policy restricts user1 to only be allowed to execute IMA signed binary applications. Therefore, user1 shall not be able to bring their own application(s) and run them.
In this example user1 is defined as:
id uid=1000(user1) gid=1000(user1) groups=1000(user1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
As root, create a file called /root/ima-policy with the following contents:
appraise func=BPRM_CHECK appraise_type=imasig uid=1000 appraise func=MMAP_CHECK appraise_type=imasig uid=1000
Next apply the IMA policy in securityfs.
$ cat /root/ima-policy > /sys/kernel/security/ima/policy
The IMA policy can be viewed using:
$ cat /sys/kernel/security/ima/policy appraise func=BPRM_CHECK uid=1000 appraise_type=imasig appraise func=MMAP_CHECK uid=1000 appraise_type=imasig
Until the machine is rebooted, user1 will only be allowed to execute binary files that have been properly signed. To apply the policy automatically on subsequent reboots, the policy file can be added to /etc/ima:
$ mkdir -p /etc/ima $ cp /root/ima-policy /etc/ima
Notes on the IMA RPM Plugin
This feature uses a rpm-plugin called ima-plugin. As described in the rpm-plugin man page:
RPM plugins provide functionality that is not suited to be used everywhere. They may not be built or shipped on some platforms or may not be installed or be disabled on some systems. This allows plugins to interface with systems that may not acceptable as a dependency for RPM and to provide functionality that may be unwanted under some circumstances."
It is possible that there may be some workloads not suitable for using this feature. An example would be the current implementation of Podman. Podman can be controlled by a non-privileged user. When a container is created, some files, owned by root, are copied and then verified by a non-privileged user. During the verification step, the extended attributes are also verified. If the ima-plugin is used, it applies the signature to the security.ima extended attribute. This extended attribute may only be created or updated by root, which will cause the verification to fail.
A workaround for this problem is to disable the plugin with dnf. This can be done with the –disableplugin option when installing a program found to create extended attributes by a non-privileged user. For any rpm installed with the plugin disabled, the IMA policy being used must exclude these programs from its appraisal policy.
It is not expected this will be a problem for a majority of the applications within our yum repository.