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

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?

> 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?

> The above audit record shows IPE blocked a file > /tmp/tmpwxmam366/deny/bin/hello in the temp file system. > > audit: AUDIT1420 path="/tmp/tmpxkvb3d9x/deny/bin/hello" dev="tmpfs" > ino=157 rule="DEFAULT action=DENY" > > The above audit record shows IPE blocked a file > /tmp/tmpxkvb3d9x/deny/bin/hello in the temp file system via another > rule. > > 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.

> The above audit record shows IPE loaded a new policy named > "dmverity_roothash" with the sha256 hash of the policy. > > audit: MAC_CONFIG_CHANGE old_active_pol_name="Allow_All" > old_active_pol_version=0.0.0 > old_sha256=DA39A3EE5E6B4B0D3255BFEF95601890AFD80709 > new_active_pol_name="dmverity_roothash" new_active_pol_version=0.0.0 > new_sha256=DC67AC19E05894EFB3170A8E55DE529794E248C2 > auid=4294967295 ses=4294967295 lsm=ipe res=1 > > The above audit record shows IPE's active policy switched from > "Allow_All" to "dmverity_roothash". Shouldn't this just be another MAC_POLICY_LOAD? That would match other LSM's. The MAC_CONFIG_CHANGE is to denote that a changeable option was modified from one value to another. But it is still operating under the same policy.