Please enable CONFIG_IMA in the ubuntu kernel

[Alec Warner]

I would be doubly happy if this also went into the raring backport kernel.

I chatted with apw and kees on #ubuntu-kernel earlier in the week. From a security engineer on our team:

so I was mistaken. if CONFIG_IMA=y, the default policy is NULL unless you boot with ima_tcb=on. without ima_tcb=y, nothing is measured, nothing is audited, no performance/memory hit is incurred.

Same is true for CONFIG_IMA_APPRAISE, except with the ima_appraise_tcb=on commandline parameter. ima appraise gives us the ability to sign binaries at installation time and check the signature at runtime.

So we are asking that you enable CONFIG_IMA, but to not enable it via the kernel command line options. IMA would boot with an empty policy and should incur no overhead. Enterprising folks who want to run IMA can enable it in grub at their option.

CONFIG_IMA=y

and possibly:

CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_AUDIT=y
CONFIG_IMA_LSM_RULES=y

-A

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Kees Cook (kees)]

Moving to main linux package. Waiting for memory benchmark comparison of:
- without CONFIG_IMA
- with CONFIG_IMA
- with CONFIG_IMG + policy

[Andy Whitcroft (apw)]

Investigations and benchmarking are ongoing to confirm/deny that turning this on without enabling is cheap enough to enable in the default configurations.

[Colin Ian King (colin-king)]

So enabling this consumes an extra sizeof(atomic_t) bytes per inode. Instrumenting the kernel with it enabled we see:

* To boot a system:

0.113 MB allocated + 23 x 4K slabs in iint_cache, total: 0.203 MB
consumed for ~1288 cached file entries.

* Install kernel + headers:

0.401 MB allocated + 37 x 4K slabs in iint_cache, total: 0.547 MB
consumed for ~2072 cached file entries

* Build a kernel (as root, stress test):

12.945MB allocated + 1023 x 4K slabs in iint_cache, total: 16.941 MB
consumed for ~57344 cached file entries.

So, typically we are seeing ~310 bytes per cached IMA file entry
consumed in the iint_cache slab and misc IMA file metadata.

Looking at the file system benchmarks, IMA built in but not enabled does
impact ext2, ext3 performance, but other file systems seem to run w/o
any impact. I may re-test the ext2/ext3 and also look at why we are
seeing the impact on ext2, ext3 if we enabled IMA.

File system performance impact on IOZONE tests with IMA appraise enabled:

http://kernel.ubuntu.com/~cking/ima/ima-appraise/html_out_ima_ext2
http://kernel.ubuntu.com/~cking/ima/ima-appraise/html_out_ima_ext3
http://kernel.ubuntu.com/~cking/ima/ima-appraise/html_out_ima_ext4
http://kernel.ubuntu.com/~cking/ima/ima-appraise/html_out_ima_xfs
http://kernel.ubuntu.com/~cking/ima/ima-appraise/html_out_ima_btrfs

[Kees Cook (kees)]

For making sure IMA isn't enabled at boot by default, here's some details From http://sourceforge.net/p/linux-ima/wiki/Home/

Enabling IMA
IMA was first included in the 2.6.30 kernel. For distros that enable IMA by default in their kernels, collecting IMA measurements simply requires rebooting the kernel with the boot command line parameter 'ima_tcb'. (Fedora/RHEL may also require the boot command line parameter 'ima=on'.)

To determine if your distro enables IMA by default, mount securityfs (mount -t securityfs security /sys/kernel/security), if it isn't already mounted, and then check if '/integrity/ima' exists. If it exists, IMA is indeed enabled. On systems without IMA enabled, recompile the kernel with the config option 'CONFIG_IMA' enabled.

[Tim Gardner (timg-tpi)]

Fixed in 3.13.0-1.16

[Philipp Kern (pkern)]

Could this be enabled in the saucy LTS backport kernel in precise as well, please? It will take a while until the trusty kernel becomes available there and this blocks our switch to the saucy kernel. Thanks!

[Dave Chiluk (chiluk)]

As cking noted in #4 this would cause a performance impact for ext2/3. That alone prevents it from moving into the stable saucy kernel.

Additionally this is a significant enough change that it would not satisfy the SRU requirements for pushing into the saucy kernel.
Please see
https://wiki.ubuntu.com/StableReleaseUpdates#Why

[Sven Mueller (smu-u)]

Would there be a chance to create a -ima flavor of the kernel instead of enabling it in the stock kernel flavor? This should allow for it to go into Trusty and into Saucy as a SRU, if I understand correctly, since it provides a new binary package instead of modifying an existing one (no regression for existing installs, conscious decision of the user required to install it).

[Philipp Kern (pkern)]

Also I want to make the point, even if it can possibly be discarded quickly, that the saucy stack is, to my knowledge, not supported yet on precise. So changes in there could be held to a different standard than in saucy proper. But I sort of understand if you avoid divergence between saucy's kernel and its backported version.

[Dave Chiluk (chiluk)]

@pkern-l
linux-generic-lts-saucy is available and supported in precise.

The source base between linux-generic-lts-saucy and kernels in saucy are built from the same sources.

As for creating a new flavor, creating additional flavors is avoided at all cost. Each additional flavor requires additional testing and other maintenance.

[Philipp Kern (pkern)]

Oh ok. I was under the impression that it was only supported from 12.04.4, to be released in a week or two.

[Mark Russell (marrusl)]

Hi Philipp,
12.04.4 is just the first appearance of the saucy kernel in the install media. As soon as a package is in main, it is supported.

[Dave Chiluk (chiluk)]

@pkern-k
@pkern
@smu-u
@antarus
It just occurred to me that you might not be aware that the 3.13 *(that now has the CONFIG_IMA) kernel available in 14.04 will be available in the update archives for precise shortly after 14.04 release. That's less than 3 months away.