On Sun, 2018-01-28 at 19:38 -0500, Theodore Ts'o wrote: > On Sun, Jan 28, 2018 at 06:04:52PM -0500, Mimi Zohar wrote: > > > > Sigh, there seems to be some confusion. Initially, when the Integrity > > Measurement Architecture (IMA) was first upstreamed, it only extended > > the trusted boot concept of measuring files before use up to the OS, > > but that was a long time ago. Since then, IMA-appraisal was > > upstreamed, which extends the secure boot concept of verifying > > signatures up to the running OS. > > Part of the problem is the documentation doesn't make any of this at > all clear. Agreed the documentation is dated and needs to be updated, especially the wiki. > Indeed, I'll note that Documentation/ABI/testing/ima_policy > still talks about using file system magic numbers to determine whether > or not files should be measured, and I've been given to understand you're using > a per-filesystem flag now. Defining policies based on magic file system numbers has been there for a really long time. Removing it would cause existing policies to fail to load. So I can't just remove it. > The documentation seems to strongly imply that in order to be secure, > you can't use IMA by itself, you have to use EVM as well. Exactly > which components can be used independently is not clear, and > apparently I made the wrong guesses when trying to read through the > Linux-IMA wiki pages as well as the Gentoo pages on IMA and EVM. > Maybe it's just the documentation is badly written, but it leaves the > impression of *extreme* complexity. The basic difference between EVM and IMA is that EVM protects the file meta-data, while IMA protects the file data. If all you want to verify is the file data signature, then just use IMA-appraisal. > > I did try to play with it, but ima-evm-utils aren't packaged for > Debian, and when I tried building from source, they apparently don't > even build on Debian Testing. (Sorry, I don't use RHEL for my > development systems.) I'm about to release version 1.1. Please try the next branch of git://git.code.sf.net/p/linux-ima/ima-evm-utils. > And I'll note the Gentoo pages warn, "don't use > on production systems". All of which do not make for a good first > look for IMA. We need to differentiate between IMA-measurement and IMA-appraisal here. Measurement isn't a problem. The problem is signature verification. Until distros include file signatures in software packages, it is difficult. This is the main reason that IMA/EVM is being used in the embedded environment, and not on desktops. We've extended RPM to include file signatures. There have been multiple attempts to add support for including file signatures in deb packages. Matthew would be able to tell you if his version, the last attempt, was upstreamed. Stefan Berger and Mehmet Kayaalp set up distro mirrors, which include the file signatures in the software packages, as a proof of concept. The file signatures are then installed with the file data. > > > Enabling IMA doesn't automatically require SELinux or any other LSM > > labels. The rule granularity is up to you. > > Yes, but if I only want to have a dozen or so files to be data > integrity protect, it appears that it's not simple to do, *without* > using SELinux. And anytime SELinux and "simple" go in the same > sentence, I weep a little. Every few years I try configuring SELinux > on Debian development laptop. And I conclude that I'm too stupid for > to configure SELinux. A lot of people have requested being able to identify files based on pathnames. I don't need to tell you this isn't safe from a security perspective. So how would you identify these few files? I doubt you are planning on hard coding them. If you have a generic solution, I would really be interested in hearing it. There are a few files which can be identified based on the LSM hook. For example, the kernel_read_file_from_path/fd calls the pre and post security_kernel_read_file() LSM hooks, which can be used to verify the kexec kernel image, kexec initramfs, kernel modules and firmware. Mimi
