mirror of
https://github.com/ostreedev/ostree.git
synced 2025-01-05 13:18:17 +03:00
116 lines
4.4 KiB
Markdown
116 lines
4.4 KiB
Markdown
---
|
|
nav_order: 10
|
|
---
|
|
|
|
# Using Linux IMA with OSTree
|
|
{: .no_toc }
|
|
|
|
1. TOC
|
|
{:toc}
|
|
|
|
## 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
|
|
on the file. This is a signed digest of just the file content (and not
|
|
any metadata)
|
|
|
|
OSTree's checksums in contrast include not just the file content, but also
|
|
metadata such as uid, gid and mode and extended attributes;
|
|
|
|
Together, this means that adding an IMA signature to a file in the OSTree
|
|
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.
|
|
|
|
## 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`)
|
|
- A digest algorithm (usually `sha256`, but you may use e.g. `sha512` as well)
|
|
- 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.
|
|
|
|
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.
|
|
|
|
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/
|
|
- https://en.opensuse.org/SDB:Ima_evm
|
|
- 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
|
|
|
|
<!-- SPDX-License-Identifier: (CC-BY-SA-3.0 OR GFDL-1.3-or-later) -->
|
|
|