2022-04-21 19:04:33 +03:00
---
2024-02-13 13:39:20 +03:00
nav_order: 110
2022-04-21 19:04:33 +03:00
---
# Using Linux IMA with OSTree
{: .no_toc }
1. TOC
{:toc}
2024-02-24 18:36:23 +03:00
<!-- SPDX - License - Identifier: (CC - BY - SA - 3.0 OR GFDL - 1.3 - or - later) -->
2022-04-21 19:04:33 +03:00
## Linux IMA
The [Linux Integrity Measurement Architecture ](https://sourceforge.net/p/linux-ima/wiki/Home/ )
provides a mechanism to cryptographically sign the digest of a regular
file, and policies can be applied to e.g. require that code executed
by the root user have a valid signed digest.
The alignment between Linux IMA and ostree is quite strong. OSTree
provides a content-addressable object store, where files are intended
to be immutable. This is implemented with a basic read-only bind mount.
While IMA does not actually prevent mutating files, any changed (or unsigned)
files would (depending on policy) not be readable or executable.
## IMA signatures and OSTree checksum
Mechanically, IMA signatures appear as a `security.ima` extended attribute
2022-04-21 23:19:14 +03:00
on the file. This is a signed digest of just the file content (and not
any metadata)
2022-04-21 19:04:33 +03:00
2022-04-21 23:19:14 +03:00
OSTree's checksums in contrast include not just the file content, but also
metadata such as uid, gid and mode and extended attributes;
2022-04-21 19:04:33 +03:00
Together, this means that adding an IMA signature to a file in the OSTree
2022-04-21 23:19:14 +03:00
model appears as a new object (with a new digest). A nice property is that
this enables the transactional addition (or removal) of IMA signatures.
However, adding IMA signatures to files that were previously unsigned
also today duplicates disk space.
2022-04-21 19:04:33 +03:00
## Signing
To apply IMA signatures to an OSTree commit, there is an `ima-sign`
command implemented currently in the [ostree-rs-ext ](https://github.com/ostreedev/ostree-rs-ext/ )
project.
### Generating a key
There is documentation for this in `man evmctl` and the upstream IMA
page; we will not replicate it here.
### Signing a commit
`ima-sign` requires 4 things:
- An OSTree repository (could be any mode; `archive` or e.g. `bare-user` )
- A ref or commit digest (e.g. `exampleos/x86_64/stable` )
2022-04-21 23:19:14 +03:00
- A digest algorithm (usually `sha256` , but you may use e.g. `sha512` as well)
2022-04-21 19:04:33 +03:00
- An RSA private key
You can then add IMA signatures to all regular files in the commit:
```
$ ostree-ext-cli ima-sign --repo=repo exampleos/x86_64/stable sha256 /path/to/key.pem
```
Many different choices are possible for the signing model. For example,
your build system could store individual components/packages in their own
ostree refs, and sign them at build time. This would avoid re-signing
all binaries when creating production builds. Although note you
still likely want to sign generated artifacts from unioning individual
components, such as a dpkg/rpm database or equivalent and cache files
such as the `ldconfig` and GTK+ icon caches, etc.
### Applying a policy
Signing a commit by itself will have little to no effect. You will also
need to include in your builds an [IMA policy ](https://sourceforge.net/p/linux-ima/wiki/Home/#defining-an-lsm-specific-policy ).
### Linux EVM
The EVM subsystem builds on IMA, and adds another signature which
covers most file data, such as the uid, gid and mode and selected
security-relevant extended attributes.
2022-04-21 23:19:14 +03:00
This is quite close to the ostree native checksum - the ordering
of the fields is different so the checksums are physically different, but
logically they are very close.
2022-04-21 19:04:33 +03:00
However, the focus of the EVM design seems to mostly
be on machine-specific signatures with keys stored in a TPM.
Note that doing this on a per-machine basis would add a new
`security.evm` extended attribute, and crucially that
*changes the ostree digest* - so from ostree's perspective,
these objects will appear corrupt.
In the future, ostree may learn to ignore the presence of `security.evm`
extended attributes.
There is also some support for "portable" EVM signatures - by
default, EVM signatures also include the inode number and generation
which are inherently machine-specific.
A future ostree enhancement may instead also focus on supporting
signing commits with these "portable" EVM signatures in addition to IMA.
## Further references
- https://sourceforge.net/p/linux-ima/wiki/Home/
2022-05-06 21:43:58 +03:00
- https://en.opensuse.org/SDB:Ima_evm
2022-04-21 19:04:33 +03:00
- https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
- https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/enhancing-security-with-the-kernel-integrity-subsystem_managing-monitoring-and-updating-the-kernel