On Thu, 2020-02-06 at 09:13 -0500, Mimi Zohar wrote: > Hi Janne, > > On Fri, 2020-01-10 at 10:48 +0200, Janne Karhunen wrote: > > On Wed, Jan 8, 2020 at 1:18 PM Janne Karhunen <janne.karhunen@xxxxxxxxx> wrote: > > > Some systems can end up carrying lots of entries in the ima > > > measurement list. Since every entry is using a bit of kernel > > > memory, allow the sysadmin to export the measurement list to > > > the filesystem to free up some memory. > > > > Hopefully this addressed comments from everyone. The flush event can > > now be triggered by the admin anytime and unique file names can be > > used for each flush (log.1, log.2, ...) etc, so getting to the correct > > item should be easy. > > > > While it can now be argued that since this is an admin-driven event, > > kernel does not need to write the file. However, the intention is to > > bring out a second patch a bit later that adds a variable to define > > the max number of entries to be kept in the kernel memory and > > workqueue based automatic flushing. In those cases the kernel has to > > be able to write the file without any help from the admin.. > > The implications of exporting and removing records from the IMA- > measurement list needs to be considered carefully. Verifying a TPM > quote will become dependent on knowing where the measurements are > stored. The existing measurement list is stored in kernel memory and, > barring a kernel memory attack, is protected from modification. > Before upstreaming this or a similar patch, there needs to be a > discussion as to how the measurement list will be protected once is it > exported to userspace. "Protected" here can mean two different aspects: cryptographically protected from tampering, which is covered with the TPM_QUOTE, and availability protected from even accidental deletion, which is what I suspect you are concerned about. Certainly my original TLV patches were too flippant about this, as userspace had to be trusted not to drop any records. In this patch, the kernel writes the data in an atomic fashion. Either all records are successfully written, or none are, and an error is returned. > This patch now attempts to address two very different scenarios. The > first scenario is where userspace is requesting exporting and removing > of the measurement list records. The other scenario is the kernel > exporting and removing of the measurement list records. Conflating > these two different use cases might not be the right solution, as we > originally thought. Actually there are at least four significant use cases: userspace requested, and kernel initiated, both for running out of memory or for saving the list prior to a kexec. Exporting everything to a file prior to kexec can really simplify all the vaious use cases of template vs TLV formatted lists across kexec. (Consider a modern TLV firmware kernel wanting to boot an older kernel that only understands template formats. How simple it would be for the first kernel to export its list to a file, and the second kernel keeps its list in template.) I have been testing this patch on all of these scenarios, and it provides a simple, powerful approach for all of them. > The kernel already exports the IMA measurement list to userspace via a > securityfs file. From a userspace perspective, missing is the ability > of removing N number of records. In this scenario, userspace would be > responsible for safely storing the measurements (e.g. blockchain). > The kernel would only be responsible for limiting permission, perhaps > based on a capability, before removing records from the measurement > list. I don't think we want to export 'N' records, as this would be really hard to understand and coordinate with userspace. Exporting all or none seems simpler. > In the kernel usecase, somehow the kernel would need to safely export > the measurement list, or some portion of the measurement list, to a > file and then delete that portion. What protects the exported records > stored in a file from modification? Tampering is prevented with the TPM_QUOTE. Accidental deletion is protected with CAP_SYS_ADMIN. If CAP_SYS_ADMIN is untrusted, you have bigger problems, and even then it will be detected. > Instead of exporting the measurement records, one option as suggested > by Amir Goldstein, would be to use a vfs_tmpfile() to get an anonymous > file for backing store. The existing securityfs measurement lists > would then read from this private copy of the anonymous file. This doesn't help in use cases where we really do want to export to a persistent file, without userspace help. > I've Cc'ed fsdevel for additional comments/suggestions. > > thanks, > > Mimi >
