Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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> <CAHC9VhRqMrTuvVtwzJoK2U=6O1QuaQ8ceA6+qm=6ib0TOUEeSw@mail.gmail.com>
In-Reply-To: <CAHC9VhRqMrTuvVtwzJoK2U=6O1QuaQ8ceA6+qm=6ib0TOUEeSw@mail.gmail.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Tue, 11 Apr 2023 19:21:52 -0400
Message-ID: <CAHC9VhSt1TzpkqGKGXy-4RDBqSQ5+1D9D2JwN1Rw-5G=b=uy3g@mail.gmail.com>
Subject: Re: [RFC PATCH v9 07/16] uapi|audit|ipe: add ipe auditing support
To:     Steve Grubb <sgrubb@redhat.com>, 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 <wufan@linux.microsoft.com>,
        dm-devel@redhat.com, linux-doc@vger.kernel.org,
        Deven Bowers <deven.desai@linux.microsoft.com>,
        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

On Thu, Mar 2, 2023 at 2:05=E2=80=AFPM Paul Moore <paul@paul-moore.com> wro=
te:
> On Tue, Jan 31, 2023 at 12:11=E2=80=AFPM Steve Grubb <sgrubb@redhat.com> =
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