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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F21E2C77B72 for ; Tue, 11 Apr 2023 23:22:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbjDKXWK (ORCPT ); Tue, 11 Apr 2023 19:22:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjDKXWF (ORCPT ); Tue, 11 Apr 2023 19:22:05 -0400 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 605FB30EB for ; Tue, 11 Apr 2023 16:22:04 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id a13so10016770ybl.11 for ; Tue, 11 Apr 2023 16:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1681255323; x=1683847323; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mjieG96zBNQQG2PDV49OxJZ6+3G2K7bw1ZbVf6U1lzk=; b=JBJa4Zkia5CL2Y2OupdXMM4PasK18pInJvMWdC+fcjeXMUtF7Az9LU/h0gwzthGF+x QFe+EM5gj0HfuwGanmiaXQwO3fOP8a4btCGAetQJYVHjOzucbpsePzuKkG8TR93btov3 ejiAzOSugxLP10TJ9faOUK77CIu/bvXaG3edhovV1FmhkPF7ahaMosgu3K9FFeA+6IjP qeh/0RVlrXKpAWpHVnAzwGCVyfYKB4mFnhjuGQJsrwBkOB5Jy3rtKOUgPR1BJr7DIua1 Fk/CkDcSU3fo0g3DUTmWuoTiaScyOwO7RNznY6OmT+Asa5k3Dvwtdp4bTuSz6pIhq7XJ tChQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681255323; x=1683847323; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mjieG96zBNQQG2PDV49OxJZ6+3G2K7bw1ZbVf6U1lzk=; b=Xqq66Oi1NPvPgba5zAtvLJ16GCz0VHVszS0x7L4pP0IceXNooHArjfigIYAlMVdoDX L30Hk/nDjYHB2cxQgn/UI/bolPpSKUTGCvnMOlSEsMgRfCyZv32tFYAwWxfYX3uDKuCg lyGqxVBGbEgeXnF+pPXLSFBVclo7k8iq5P0SeEeBY/vmj3gYT10ucXuql+1StTXLoK2b UO2/d/USYK5JOmQgigdveJdjjBTRKj8sU4y+u4D0jeNoOl/UBwfXcV6uHq/G7Zt917ZR mW8cIRuLl0dngIHx111NvYL+ipHnrSliK3yHyUJllzHntltzoMCXp1zuqi6gXGNwSSjt M33g== X-Gm-Message-State: AAQBX9d3CWSwFOI7L1utKNvw4iUibAefC7H9WI1pVHEV70PJOXK40ONg jjh7jkaCZ1X5pH0yLpQraMziB1YjijA8zsdANTQB X-Google-Smtp-Source: AKy350Y8Rhd9rHz1qCSxaAF3gL9UQq1FI0yq/mFrHh6N2pKJ6DGoHbpLYYEOHTWZcax61zY11aqLEAa5SLJ9oKG9DsM= X-Received: by 2002:a25:cace:0:b0:b8f:2f68:93b0 with SMTP id a197-20020a25cace000000b00b8f2f6893b0mr1197248ybg.3.1681255323520; Tue, 11 Apr 2023 16:22:03 -0700 (PDT) MIME-Version: 1.0 References: <1675119451-23180-1-git-send-email-wufan@linux.microsoft.com> <1675119451-23180-8-git-send-email-wufan@linux.microsoft.com> <3723852.kQq0lBPeGt@x2> In-Reply-To: From: Paul Moore Date: Tue, 11 Apr 2023 19:21:52 -0400 Message-ID: Subject: Re: [RFC PATCH v9 07/16] uapi|audit|ipe: add ipe auditing support To: Steve Grubb , linux-audit@redhat.com Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com, tytso@mit.edu, ebiggers@kernel.org, axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org, eparis@redhat.com, Fan Wu , dm-devel@redhat.com, linux-doc@vger.kernel.org, Deven Bowers , roberto.sassu@huawei.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-integrity@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: On Thu, Mar 2, 2023 at 2:05=E2=80=AFPM Paul Moore wro= te: > On Tue, Jan 31, 2023 at 12:11=E2=80=AFPM Steve Grubb = wrote: > > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote: ... > > > audit: MAC_POLICY_LOAD policy_name=3D"dmverity_roothash" > > > policy_version=3D0.0.0 sha256=3DDC67AC19E05894EFB3170A8E55DE52979= 4E248C2 > > > auid=3D4294967295 ses=3D4294967295 lsm=3Dipe res=3D1 > > > > The MAC_POLICY_LOAD record type simply states the lsm that had it's pol= icy > > loaded. There isn't name, version, and hash information. I'd prefer to = see > > all users of this record type decide if it should be extended because t= hey > > also have that information available to record. > > Not all LSMs which load policy have that information; as an example, > SELinux doesn't have the concept of a policy name or version. The > SELinux policy version you might see in the kernel sources refers to > the policy format version and has no bearing on the actual policy > content beyond that dictated by the format. > > If additional information is required by IPE, perhaps an auxiliary IPE > policy load record could be created with those additional fields. The issue of policy load audit records came up in an offline discussion with Fan today and I think it's worth talking about this a bit more to reach some consensus. Currently only SELinux generates MAC_POLICY_LOAD records, and it contains all of the information that is present in the IPE example above with the exception of the 'policy_name', 'policy_version', and the policy digest. I personally don't have a problem extending the MAC_POLICY_LOAD record with these fields, and leaving them unused/"?" in the SELinux generated records. It's possible we may even want to use the policy digest field at some point, as it would be nice to be able to have some policy "key" within SELinux that could be used to help identify the loaded policy. The only catch is that we may want to find a better field name than just 'sha256', in the context of the MAC_POLICY_LOAD record it seems easily understood, but in the larger context of a full audit stream it might be too ambiguous. We would also need to decide if we wanted to encode the digest algorithm in the field name, the field value, or have it as a separate field. I might lean towards encoding it in the field value like this: policy_digest=3Dsha256:XXXXX ... however that is something that would need some discussion from the other folks on the To/CC line. --=20 paul-moore.com