Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp117031ybh; Mon, 20 Jul 2020 11:47:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQftn0XOoDE0V7LSmoNufRksxXmRK5QcD5zxaFTUoI/MZaEbXrzAmuz4NprK2CsRvwsmF0 X-Received: by 2002:aa7:c442:: with SMTP id n2mr22236119edr.309.1595270832336; Mon, 20 Jul 2020 11:47:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595270832; cv=none; d=google.com; s=arc-20160816; b=FICus0FmEAEau+Nbjxkl4m6rhI/SEEVmHrIgPi68lFrGpCEj5eD1hAJEGXg872frDK KT5dFbkUWh7CM+YoWxR/MFSLEGJfm45cQmZr9+7aBJzi8ZoNnyeQBrC+CZ6jTE7LBdZY ddJbfeKH6fHyFH2Kbre2mgKTiJbP7H1GSxoO8nXNmA3hujS7sK6DRbGLfZZbsMScoeA9 ocLjw/4HhyUKTLOp/2wJa19QxlGsGsFLaYjOJruPxVOcevbIiFp82BvWJQmt5ptDzRn2 xyqpbylBA2nUZkc8lG3g//CRMcGORM9qoLae+vFLWlkvwgNHdwUznyRLAAs/pCSEAm/s 2VrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aCbgyprCpv5zpqintIcYum/YWgpLdnYdNsT160BVscU=; b=xqbemJ6l0AL6UFlwtfc3xuS4jir5ECx6bu8ia27WUCyzpmamjH5qSHZweM1865s90I zvMQuLwdDzZhkVW4TgBwqEzPGDKL66PhF8CFK4V9tM+UNThRv1Ez6zwpTDhFlQXDY7ZE gCxyu1ep+7bnIFMjDvNi5IhMbpzqathukHjQ3gxJgEs4OQ3bcFsxYhd5XPGG+mqv1vB2 yJPpkDsK2D/5QxJyO93yIGGoxhuz5h1y7uZKrIpi6RoDls52unysIjLvNp7CcBYr77bN 0iJaPyRZieQujnETUsFbgEAesXpa6rylwNP0L6NWafa4D/eFMNRvf9XlkrbFkARgR9J/ iO2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MqA1QBnc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dg17si11075275edb.606.2020.07.20.11.46.48; Mon, 20 Jul 2020 11:47:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MqA1QBnc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730203AbgGTSoU (ORCPT + 99 others); Mon, 20 Jul 2020 14:44:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728068AbgGTSoT (ORCPT ); Mon, 20 Jul 2020 14:44:19 -0400 Received: from mail-oo1-xc43.google.com (mail-oo1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47556C061794; Mon, 20 Jul 2020 11:44:19 -0700 (PDT) Received: by mail-oo1-xc43.google.com with SMTP id y9so3387479oot.9; Mon, 20 Jul 2020 11:44:19 -0700 (PDT) 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=aCbgyprCpv5zpqintIcYum/YWgpLdnYdNsT160BVscU=; b=MqA1QBncRXeHqrSw+D9BJYzKgHEiDmWtVKqX3bSjZgXmBmd6zpF4cQWCzZq10h0CA3 athEZ1vHT98oFgV1u5Xrq7SIUdYFFDJweUOqE/9dAedg5r1E+1wUR4GCgjrB96tcY/oW eRPMgsTx93B4fM1CBPPt+BYnUy+SKpvnDZb84tQzPwV8RrB/O6GPq9FpLKtvGOAsM390 C7MWF2OlPkVQwDk7XXBKHOaIfJP+cSPOMetp2zdeIqSqvIGGFuwHmUWypGeLDGvbZ5XA /LJYfKsKKQ3GagLFgzCqrfWNONB11jIfoxaDh7WFhi8q1GPz+bzP6N2POUhiM43D/SpJ PZCQ== 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=aCbgyprCpv5zpqintIcYum/YWgpLdnYdNsT160BVscU=; b=LIrWcHEJSXZNux0yE+Og8ay3acuYUIOVCil8DnQqRZOpdUCDlO+ObAcPJwujkNR5FD /BoZeS2otxmO2mEzizf5u/zM62Vpj1lCxIuAExWVIYfe4YE07HrY9uSIuonUTi4Mm3DP /IFzaukDUxjhz1wICCgqUftlitj6NEVrmv7oQNAnIwA0zcWmUFhgnDeVoUxhlWTP2WIR J6qBKaQGAKWfA04u+a2uyrog8gNxGKsBvdU4MjxW+FZNeBWcXngZW1L7XbRYQIic/ntn QeXdG8LqELd1onZ5+AdEqfTlAbQlHfDck7WyRveJvoXXrWCjAaXEYBzre7oUj0q48iOM sdtA== X-Gm-Message-State: AOAM530JHQ5TemDWKyvFoMH7pxny39GOsb4YY/0eiZWcZGykTMGt5OBp ZzP9epea+Sg0+R/NziaOguzcOCGxepR2n8khmBO6zQ== X-Received: by 2002:a4a:b006:: with SMTP id f6mr20757376oon.13.1595270658680; Mon, 20 Jul 2020 11:44:18 -0700 (PDT) MIME-Version: 1.0 References: <20200717222819.26198-1-nramas@linux.microsoft.com> <20200717222819.26198-5-nramas@linux.microsoft.com> In-Reply-To: From: Stephen Smalley Date: Mon, 20 Jul 2020 14:44:07 -0400 Message-ID: Subject: Re: [PATCH v3 4/5] LSM: Define SELinux function to measure security state To: Lakshmi Ramasubramanian Cc: Mimi Zohar , Casey Schaufler , James Morris , linux-integrity@vger.kernel.org, SElinux list , LSM List , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 20, 2020 at 2:27 PM Lakshmi Ramasubramanian wrote: > > On 7/20/20 10:49 AM, Stephen Smalley wrote: > > >>> > >>> Looks like the template used is ima-ng which doesn't include the > >>> measured buffer. Please set template to "ima-buf" in the policy. > >>> > >>> For example, > >>> measure func=LSM_STATE template=ima-buf > >> > >> It seems like one shouldn't need to manually specify it if it is the > >> only template that yields a useful result for the LSM_STATE function? > > > > Actually, if we used ima-ng template for selinux-policy-hash, then > > instead of needing to hash the policy > > first and passing the hash to IMA, we could just pass the policy as > > the buffer and IMA would take care of the hashing, right? > > That is correct. > > The IMA hook I've added to measure LSM structures is a generic one that > can be used by any security module (SM). I feel it would be better to > not have policy or state or any such SM specific logic in IMA, but leave > that to the individual SM to handle. > > What do you think? It is correct to remain security module agnostic. However, I think you can remain LSM-neutral while still avoiding the double hashing of the policy here. Can't you just pass in the policy itself as the buffer and let IMA hash it? Then you can let the policy author decide on the template to be used (ima-buf versus ima-ng). If you want to support the use of different templates for different "kinds" of LSM state (e.g. state versus policy) you could either provide two funcs (LSM_STATE, LSM_POLICY) or otherwise support selection based on some other attribute.