On Thu, Mar 02, 2023 at 02:05:33PM -0500, Paul Moore wrote:

On Tue, Jan 31, 2023 at 12:11???PM Steve Grubb [off-list ref] wrote:

quoted

Hello,

On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:

quoted

From: Deven Bowers <redacted>

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@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.

quoted

quoted

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