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=-4.1 required=3.0 tests=BAYES_00,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 09C27C433E3 for ; Mon, 20 Jul 2020 17:41:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E22AF20702 for ; Mon, 20 Jul 2020 17:41:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZK7xQhCM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732133AbgGTRlG (ORCPT ); Mon, 20 Jul 2020 13:41:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728876AbgGTRlF (ORCPT ); Mon, 20 Jul 2020 13:41:05 -0400 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A71F8C061794; Mon, 20 Jul 2020 10:41:05 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id n24so12847671otr.13; Mon, 20 Jul 2020 10:41:05 -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=mdh7aaQO3fTgP8bprJCk07MNirNdtGLOsGXoOk/ABZc=; b=ZK7xQhCMjjUAUEzYRVR/d2z4PdrUMiWkEwlhkLAYriZTx873OuHzgZXk11s1mNWxZK 5n16AMmLp3lSI5G/IumA9/wCX3AEiP74GVIGt2MLXWVzJrcFDhhtZCZYRCcHHFBU0Pvr hR4sHyHq2qJal5p/mk3Xm7GcY2bh5/QPWDkt42G4QXVdaljxIswo7tSQ1vShGJ1pMF6/ 8CYoHfivClk17aaPK8IOzBfO7qoktBKHI0kZdHsZD5AnCzulYRCiXzGHhwkU7M/itC1t ul6ohoB0Y3pcAyEW+3UMzibh7tFjPnrYRVt13+Xs+aUWO+S187fIiLVuY+Eo0KAEfdUY oDQw== 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=mdh7aaQO3fTgP8bprJCk07MNirNdtGLOsGXoOk/ABZc=; b=KTxZl91hMClanGcLi8WPM0wWOc77L02zI3ShY38Wz+N6/C99+ek0Ul25AY4D7Llnk+ hdEEzDPxBkqyc52k0nlJnXG6ks7nxKf2yJKug8Q3b2LAtGJECmOGkvnIHPnQtQ9n/6ps SZbteuEvwBHlFnig1o9tBiNC0+3IBLaHx66KGENWzO1Qf6rJVB10dcG3Fx3R0mRxATp9 tp04kUFrwLggLmfAjnaBNI76mo8Zg9VMN1kGXAu25Tcbj8fq/zaHdmT6AxzKMqWVn0sR NKsyGx/RoGob2G7BT2IqTDu2aoJa9W7Gc+s3e4auH8cuLQaPVscXprqDoY3zUHZR/y86 gSyg== X-Gm-Message-State: AOAM530EsrZ8XzRZsd9H3O8C2zcV8E2dHLW2Lt0P+YsF2VmWF9lnj+II QYtFMBYQn8p3QD4ii7guWk7yBLF4v4h/jA9PlOqlAQ== X-Google-Smtp-Source: ABdhPJyNSsutBkqiXagUluHJ47Cw4MCx5LYPC9K6Vlp38BJaUiFviCgYEgVwcaMK8SD1/+1m0D7kyZXyoTFBvruGE6g= X-Received: by 2002:a05:6830:1db5:: with SMTP id z21mr21309304oti.162.1595266865020; Mon, 20 Jul 2020 10:41:05 -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 13:40:54 -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 1:34 PM Lakshmi Ramasubramanian wrote: > > On 7/20/20 10:06 AM, Stephen Smalley wrote: > > >> The above will ensure the following sequence will be measured: > >> #1 State A - Measured > >> #2 Change from State A to State B - Measured > >> #3 Change from State B back to State A - Since the measured data is > >> same as in #1, the change will be measured only if the event name is > >> different between #1 and #3 > > > > Perhaps the timestamp / sequence number should be part of the hashed > > data instead of the event name? > > If the timestamp/seqno is part of the hashed data, on every call to > measure IMA will add a new entry in the IMA log. This would fill up the > IMA log - even when there is no change in the measured data. > > To avoid that I keep the last measurement in SELinux and measure only > when there is a change with the timestamp in the event name. > > > I can see the appraiser wanting to know two things: > > 1) The current state of the system (e.g. is it enforcing, is the > > currently loaded policy the expected one?). > > 2) Has the system ever been in an unexpected state (e.g. was it > > temporarily switched to permissive or had an unexpected policy > > loaded?) > > Yes - you are right. > The appraiser will have to look at the entire IMA log (and the > corresponding TPM PCR data) to know the above. > > Time t0 => State of the system measured > Time tn => State changed and the new state measured > Time tm => State changed again and the new state measured. > > Say, the measurement at "Time tn" was an illegal change, the appraiser > would know. > > > > > I applied the patch series on top of the next-integrity branch, added > > measure func=LSM_STATE to ima-policy, and booted that kernel. I get > > the following entries in ascii_runtime_measurements, but seemingly > > missing the final field: > > > > 10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng > > sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24 > > selinux-state > > 10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng > > sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318 > > selinux-policy-hash > > > > Thus, I cannot verify. What am I missing? > > > > 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?