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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 3BD15C4360F for ; Mon, 4 Mar 2019 19:52:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0885020835 for ; Mon, 4 Mar 2019 19:52:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rWznco1t" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726172AbfCDTwe (ORCPT ); Mon, 4 Mar 2019 14:52:34 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:37730 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726158AbfCDTwe (ORCPT ); Mon, 4 Mar 2019 14:52:34 -0500 Received: by mail-it1-f194.google.com with SMTP id z124so661617itc.2 for ; Mon, 04 Mar 2019 11:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uRTZuRxyUgNjF0HjeCnbizljMfwLDQZWApGcGjmXMJw=; b=rWznco1tJ6C//UtLtqinphJW9J11I4enzPlBxPdmgVaVfhvnmoHhDIsH3ooFtob57h 0urMlsNQh9w6rQz97HPtzUbQvoN7sqTlnk0k09+X7MdAfKvz85B5Rv8P0zq4vjXFfBU8 l5ZlLnm6N03cFYjHBEus6+Hh6afFCPhrR4wKJxIaWS+2lxUK0OOJFFka/cDDxlQwKJpn fmL1oaSjfYGcvDEuuqkLO7TLW7+WM1DgYUi9KtZ9mU8V8D5sCPEjI4Kp/zZWW2ZUOyNg qcfcZQ6wDElsVjFHstFeFM2DurTbXFNvsr+TYOIuVYwAP6uzSew1FAWbsYy5OrgD5wwL ffjw== 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=uRTZuRxyUgNjF0HjeCnbizljMfwLDQZWApGcGjmXMJw=; b=IWnNHuasWto79MaO+XoYlARYeTUn5jk4jLtJG/HGLlbuJPX8gmsOyIgn9EBrUR9lAr 7HYkHY8tRCtB7wr5Fmjwlk51eHsl6LC69KHFqXH1lneXc3CItnUgVPVdEPJl29jAFjdh oS8dDtCnjyZu4taD2JdzV3JQ2qoNjNVXCR75N9Nq7ShTya0r4MfvoFlIXM3n7S5xw0QD fto1YsMl77VYLPs/z9JFCgB+uI6zr6d2jwFIxxCXCNW0K9MzT8HzKb8LN0eFO6ETJPdU QeRUBGDgvrcJRUyYz/1v31vmRBOsnXotg44UhQ6JeIlZSEdySKxPE6rDefOWPYQ4mduh Pulg== X-Gm-Message-State: APjAAAUhJarWRX9UbqSTt2ZT8+vERu1z+X7sroTdhvcQkuWb08BoyqNt fNJfgMzHQbcewHbTU906mQVAEnMmgm17qVI0BOrh2w== X-Google-Smtp-Source: APXvYqx4Fr0NzmmKPOHAoJm2fOyfvDmI8uqdgjxOjcafzHA8ICOhyQf7HAsJXcHKofEQxluPKNy3cTGqZziMVWCB+T0= X-Received: by 2002:a02:23cd:: with SMTP id u196mr10499515jau.103.1551729152986; Mon, 04 Mar 2019 11:52:32 -0800 (PST) MIME-Version: 1.0 References: <20190226215034.68772-1-matthewgarrett@google.com> <20190226215034.68772-4-matthewgarrett@google.com> <1551369834.10911.195.camel@linux.ibm.com> <1551377110.10911.202.camel@linux.ibm.com> <1551391154.10911.210.camel@linux.ibm.com> In-Reply-To: From: Matthew Garrett Date: Mon, 4 Mar 2019 11:52:22 -0800 Message-ID: Subject: Re: [PATCH V2 3/4] IMA: Optionally make use of filesystem-provided hashes To: Mimi Zohar Cc: linux-integrity , Dmitry Kasatkin , linux-fsdevel@vger.kernel.org, miklos@szeredi.hu Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Feb 28, 2019 at 2:38 PM Matthew Garrett wrote: > > On Thu, Feb 28, 2019 at 1:59 PM Mimi Zohar wrote: > > On Thu, 2019-02-28 at 13:41 -0800, Matthew Garrett wrote: > > > If collect_type=get_hash and the filesystem doesn't support the > > > get_hash type, should the behaviour be to fall back to read? > > > > "get_hash" should be limited to a specific filesystem type and > > subtype. Based on the filesystem type and subtype, couldn't a warning > > be emitted at policy load time. > > The policy may be loaded before the filesystem is mounted, so even if > we added a capabilities mechanism we wouldn't be able to verify it. > There's also potentially cases where a filesystem could support hash > retrieval for some files but not others, and in that case we'd > probably want to fall back to reading the file. To be clear, I'm entirely happy to make this change - I'd just like to ensure that I do it the right way!