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

[Fan Wu]

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 at redhat.com> wrote:
> >
> > Hello,
> >
> > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:
> > > From: Deven Bowers <deven.desai at linux.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 at vger.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