linux-kernel - Re: [RFC PATCH v9 07/16] uapi|audit|ipe: add ipe auditing support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhSt1TzpkqGKGXy-4RDBqSQ5+1D9D2JwN1Rw-5G=b=uy3g@mail.gmail.com>
Date:   Tue, 11 Apr 2023 19:21:52 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Steve Grubb <sgrubb@...hat.com>, linux-audit@...hat.com
Cc:     corbet@....net, zohar@...ux.ibm.com, jmorris@...ei.org,
        serge@...lyn.com, tytso@....edu, ebiggers@...nel.org,
        axboe@...nel.dk, agk@...hat.com, snitzer@...nel.org,
        eparis@...hat.com, Fan Wu <wufan@...ux.microsoft.com>,
        dm-devel@...hat.com, linux-doc@...r.kernel.org,
        Deven Bowers <deven.desai@...ux.microsoft.com>,
        roberto.sassu@...wei.com, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        linux-fscrypt@...r.kernel.org, linux-integrity@...r.kernel.org
Subject: Re: [RFC PATCH v9 07/16] uapi|audit|ipe: add ipe auditing support

On Thu, Mar 2, 2023 at 2:05 PM Paul Moore <paul@...l-moore.com> wrote:
> On Tue, Jan 31, 2023 at 12:11 PM Steve Grubb <sgrubb@...hat.com> wrote:
> > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:

...

> > >   audit: MAC_POLICY_LOAD policy_name="dmverity_roothash"
> > >     policy_version=0.0.0 sha256=DC67AC19E05894EFB3170A8E55DE529794E248C2
> > >     auid=4294967295 ses=4294967295 lsm=ipe res=1
> >
> > The MAC_POLICY_LOAD record type simply states the lsm that had it's policy
> > 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 they
> > 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=sha256:XXXXX

... however that is something that would need some discussion from the
other folks on the To/CC line.

-- 
paul-moore.com