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 E02F4C433E1 for ; Mon, 20 Jul 2020 17:49:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C834122B51 for ; Mon, 20 Jul 2020 17:49:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="N49dDLbt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729565AbgGTRtz (ORCPT ); Mon, 20 Jul 2020 13:49:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726437AbgGTRty (ORCPT ); Mon, 20 Jul 2020 13:49:54 -0400 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB883C061794; Mon, 20 Jul 2020 10:49:54 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id t4so15027610oij.9; Mon, 20 Jul 2020 10:49:54 -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=E/WF9LmUo71c0bgV0jc9EPEVEVSzt8bdBdlMxd+6u9o=; b=N49dDLbtcc8GbCc/rK6VzmC408aRyQNWvV2bsAzf2369GrbLTIqe/8AIHtgH8i6iaW h/LY7IMO/tCttISFJNT44Z/7d4MHx61mUdhl7VwwPWWqMa7MU4SX9WD9axAZXlQyrzoC kN4uyoHIBMFMYgKDZWHQFOJZ5bQvHz38NdxFbHVTQlijvrcuRDRDpXxVewmi8WAAd8cX A5VIQvWKJvdLBpNbj2tA13i1Dq+V0c71YItqmQR+p3kOTaJbFHiqfuJ+RzS4PiX7/7NZ WdNXkAuLJ9mudeJFNhLM5OsCtgF1Sjtk58ZvJJlZLVt9S8IjPNtMd7P0ghmaYvKCIW6K E8pQ== 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=E/WF9LmUo71c0bgV0jc9EPEVEVSzt8bdBdlMxd+6u9o=; b=COKKPd7ki6sFuMgWhtMAt5skMZoXs2N0z4k8cXCVZsvozpX2jHHJ5ctanYp+dXzAco loNEuzpjZLGfe9/kn4NtLArzZq6k1yymTefgF/eXuwISlmObRNyqQzNvp5pRnPqgdDYB zTMG4DrE3M/F6pSCXdm3eZHEHvMRURzH5jVyGKyS+rEXCa1iCfKeqlpjowexysAeTiPS IOKXwo7qPU25sV/bPXJtHsu+aDDh6nVdA3/Sw1lEKdFCzO4IHofDIWwmRLv6YeVEJw6Q Nctk5ONNlDjbicOWFV2Yg8VuDTDyRrPrgHQ0ncZBkfStIXJt2qcBb1xUYqyc9WKhcatr YHrg== X-Gm-Message-State: AOAM5320/3+d1YFo05t2kp/eCMSY5YdGlGJiDvWrpE4HUeSS4sqG/+FE PBEq++8rz1o4EnMOz6OTzbQt2GwTYJSq+Z43Y81MVA== X-Google-Smtp-Source: ABdhPJw1Ddg81VAJhNmhtE0Qulu8T/IcFBqzefZSxTWJ1RiLL7hGzoUJLJYUNL3KckdDR7CVcAzOxVuv71RyuDv3w+0= X-Received: by 2002:aca:2807:: with SMTP id 7mr374627oix.140.1595267394146; Mon, 20 Jul 2020 10:49:54 -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:49:43 -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: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On Mon, Jul 20, 2020 at 1:40 PM Stephen Smalley wrote: > > 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? 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? And we only need to use ima-buf for the selinux-state if we want the measurement list to include the string value that was hashed; if we just want to compare against a known-good, it would suffice to use ima-ng for it as well, right?