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: <20230316225340.GB22567@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date:   Thu, 16 Mar 2023 15:53:40 -0700
From:   Fan Wu <wufan@...ux.microsoft.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Steve Grubb <sgrubb@...hat.com>, 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,
        linux-audit@...hat.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 02, 2023 at 02:05:33PM -0500, Paul Moore wrote:
> On Tue, Jan 31, 2023 at 12:11???PM Steve Grubb <sgrubb@...hat.com> wrote:
> >
> > Hello,
> >
> > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:
> > > From: Deven Bowers <deven.desai@...ux.microsoft.com>
> > >
> > > Users of IPE require a way to identify when and why an operation fails,
> > > allowing them to both respond to violations of policy and be notified
> > > of potentially malicious actions on their systens with respect to IPE
> > > itself.
> > >
> > > The new 1420 audit, AUDIT_IPE_ACCESS indicates the result of a policy
> > > evaulation of a resource. The other two events, AUDIT_MAC_POLICY_LOAD,
> > > and AUDIT_MAC_CONFIG_CHANGE represent a new policy was loaded into the
> > > kernel and the currently active policy changed, respectively.
> >
> > Typically when you reuse an existing record type, it is expected to maintain
> > the same fields in the same order. Also, it is expect that fields that are
> > common across diferent records have the same meaning. To aid in this, we have
> > a field dictionary here:
> >
> > https://github.com/linux-audit/audit-documentation/blob/main/specs/fields/
> > field-dictionary.csv
> >
> > For example, dev is expected to be 2 hex numbers separated by a colon which
> > are the device major and minor numbers. But down a couple lines from here, we
> > find dev="tmpfs". But isn't that a filesystem type?
> 
> What Steve said.
> 
> I'll also add an administrative note, we just moved upstream Linux
> audit development to a new mailing list, audit@...r.kernel.org, please
> use that in future patch submissions.  As a positive, it's a fully
> open list so you won't run into moderation delays/notifications/etc.
> 
Thanks for the info, I will update the address.

> > > This patch also adds support for success auditing, allowing users to
> > > identify how a resource passed policy. It is recommended to use this
> > > option with caution, as it is quite noisy.
> > >
> > > This patch adds the following audit records:
> > >
> > >   audit: AUDIT1420 path="/tmp/tmpwxmam366/deny/bin/hello" dev="tmpfs"
> > >     ino=72 rule="DEFAULT op=EXECUTE action=DENY"
> >
> > Do we really need to log the whole rule?
> 
> Fan, would it be reasonable to list the properties which caused the
> access denial?  That seems like it might be more helpful than the
> specific rule, or am I missing something?
> 
Audit the whole rule can let the user find the reason of a policy decision.
We need the whole rule because an allow/block is not caused by a specific
property, but the combination of all property conditions in a rule.

We could also add a verbose switch such that we only audit
the whole rule when a user turned the verbose switch on. 

-Fan

> paul-moore.com