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(a)redhat.com&gt; wrote: > > > > Hello, > > > > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote: > > > From: Deven Bowers <deven.desai(a)linux.microsoft.com&gt; > > > > > > 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(a)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.