From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DD2CC352A4 for ; Mon, 10 Feb 2020 08:04:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F124C20733 for ; Mon, 10 Feb 2020 08:04:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pawlTy63" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727434AbgBJIE4 (ORCPT ); Mon, 10 Feb 2020 03:04:56 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:45502 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725468AbgBJIE4 (ORCPT ); Mon, 10 Feb 2020 03:04:56 -0500 Received: by mail-lj1-f194.google.com with SMTP id f25so5982211ljg.12; Mon, 10 Feb 2020 00:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4A3TMLKRGhyPkPgiJ1U8mlnA1xT8oI0F78huS9wa9CU=; b=pawlTy63fbpdEBYkv0CmRGyPqkZ8dqJQl4Aj79L8VP9AENrF7OfLO41WMjN4HCw2ZT TjfUpxO5q6ucBK5/rvHkSecgrx48lkta+ZP5YVv2BgL1I0km8Vr4h2O/ux1+XdnCykPE BkZOWVMl9ab+KUsALRf7dVvUNdFinjcWQYXEofq7aa1SONM6z9fPODpNcPQ2LqwJPtn8 2CToKALcN1IzvFMIa5BQOE/masPDovHJpejgEqFcQQ7N7yaDptXG+2KFqneOki5tHW10 nNU8lzz6W/nBpiuoP1Fvzs7H8RY5zEkVW4955Fa82jlC8pRfSp/9yZ9jbk1CspU9n6eu qc9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4A3TMLKRGhyPkPgiJ1U8mlnA1xT8oI0F78huS9wa9CU=; b=mRvbxQObNN6ONCYpn8mx4kgkuX+Zj/SGb4WhyBtnss8o8JueXRgBdyUTEJEo5nVwR2 giyQzpLN5zu3yUPnuHGso0XOrn7492UMSot9ZdRJFuZRkd7kSq+xiY6ToP5X0cNIJdjP biB3u2KHCf7tbvQ2lXZPzRO+pNLIQPKULRyTnyOz1KesNVWAuUkuJuoZOUE6d84tasmr nppZ1wbldKa573SBP4OaQkdkzwRFqAUHLRdZAM6llNTL1pyPf5MRxDz0yeD9sMr5d95n jXGWEIYJND893RgOoadMxiZaKrneGuihnEymJTnT8pybh/T/gdZp0lZ4Dn5OceXhQp1a KwqA== X-Gm-Message-State: APjAAAV++e87Xkr3gKWb3gHSBou+knExFK/nLuEqg7JmNlSS+wUytPd8 zGChhTHjdXVnE5CojoCunmoJIgntB1AXkG9Yv/M= X-Google-Smtp-Source: APXvYqxKYRfBdy1b8G3zgeigkBLLmIXOGUi3cZulxhpZITWH3+AT9urS6u3fQ+t/PjZxEM0Yoqhsm61H4Nnu/Wtc4ZE= X-Received: by 2002:a2e:8e95:: with SMTP id z21mr93361ljk.119.1581321893578; Mon, 10 Feb 2020 00:04:53 -0800 (PST) MIME-Version: 1.0 References: <20200108111743.23393-1-janne.karhunen@gmail.com> <1580998432.5585.411.camel@linux.ibm.com> In-Reply-To: <1580998432.5585.411.camel@linux.ibm.com> From: Janne Karhunen Date: Mon, 10 Feb 2020 10:04:42 +0200 Message-ID: Subject: Re: [PATCH v2] ima: export the measurement list when needed To: Mimi Zohar Cc: linux-integrity@vger.kernel.org, linux-security-module , Ken Goldman , david.safford@gmail.com, "Wiseman, Monty (GE Global Research, US)" , Amir Goldstein , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, Feb 6, 2020 at 4:14 PM Mimi Zohar wrote: > 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. > > 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. > > 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. This is a good point. I will adapt the patch to this. > 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? Are we looking at protecting this file from a root exploit and the potential DOS it might cause? In the original patch the file was root writable only. As far as further limitations go, the easiest would probably be to use the file immutable bit. If the kernel opens the file and sets the immutable bit, it is the only entity that can ever write to it - not even another root task could directly write to it. The kernel could, as long as it keeps the file open. > 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. > > I've Cc'ed fsdevel for additional comments/suggestions. I didn't quickly see what the actual problem is that the vfs_tmpfile solves in this context, will check. -- Janne