illumos gate

Today, ZFS supports setting 'AUDIT' and 'ALARM' type entries in a file's ACL. This project gives these ACE types a mechanical behavior: when performing access checks, additional 'success' and 'failure' masks are calculated by combining the bits set in any AUDIT or ALARM-type ACE that matches the user. An AUDIT/ALARM ACE can have a SUCCESSFUL_ACCESS ('S') control bit, a FAILED_ACCESS ('F') control bit, or both, which determines whether it contributes to the 'success' or 'failure' audit mask (or both). The masks are only calculated if the user's credential has preselected the 'AUE_SACL' event.

This mask is passed up to the caller through an extension to the existing per-thread audit control structure. The caller initializes this structure; ZFS manipulates this structure based on the system state and any AUDIT/ALARM ACEs processed during access checks; the caller then reads the structure to get the calculated audit masks. It can then compare these masks against the accesses involved in the operation to decide whether a record needs to be generated. Notably, ZFS does not actually generate any records - its only job is to calculate the masks. See the comment above 'typedef struct t_audit_sacl' in uts/common/c2/audit_kernel.h for the exact mechanics. This strategy was chosen to avoid any changes to VOP_ACCESS or adding any new VOP interfaces. (One day, it would be nice to have a 'VOP_ACCESS_EX' or similar that could directly acquire the audit mask - as well as provide granular access grants)

Additionally, several changes were made to how ZFS handles AUDIT- and ALARM-type ACEs, which are necessary due to ZFS (and the various ACL interfaces) combining what Windows refers to as the DACL and the SACL into a single ACL (I'd like for the SACL/DACL to be split one day, but that's work for another time):
1. A new z_hints/pflags flag 'ZFS_ACL_NO_AUDIT_ACE' was added, which is set when the ACL on an object has no AUDIT/ALARM type ACEs. This is used various places to speed up ACL processing; if we know there are no AUDIT ACEs, we can end processing once any other work has been completed.
2. AUDIT/ALARM ACEs no longer prevent an ACL from being marked 'TRIVIAL' (they no longer prevent a file from being chmod'd in restricted mode).
3. Inheritable AUDIT/ALARM ACEs are no longer discarded in discard mode. Discard mode is meant to prevent permissions from automatically propagating to new objects; any new access to these objects should still be audited.
4. AUDIT/ALARM types are treated separately from ALLOW/DENY types in all cases.
5. A new flag VSA_ACE_SYS was added to vsa_mask. This indicates that the caller has included a System ACL (SACL) in the ACL. During 'create file with specified ACL', if this isn't set, ZFS performs inheritance for AUDIT/ALARM types and adds them to the specified ACL. Currently, this is only set by SMB, and the 'create with ACL' interface isn't exposed to userspace.
6. A new flag VSA_ACE_NOSACL was added to vsa_mask. This indicates that the caller does not understand AUDIT/ALARM type ACEs. It instructs ZFS to filter out AUDIT/ALARM types from any ACL returned to the caller, and to merge any existing AUDIT/ALARM entries into any ACL the caller attempts to set. This is used by the NFS server; neither the client nor the server support AUDIT/ALARM types (though the protocol does), and ZFS can handle the split/merge more efficiently than NFS.

Limitations:
1. There are several reasons why a given call to VOP_ACCESS(), or another interface that performs access checks, might not actually process the ACL (see ATTR_NOACLCHECK). In these cases, the per-thread struct is left unchanged. The caller can detect this and perform an 'alternate' access check that will hopefully cause the ACL to be processed, but if this fails, the caller must assume the request needs to be audited. This could be fixed with a dedicated VOP interface, which would eliminate any ambiguity.
2. A bunch of this work is necessary because neither ZFS nor the VSA interface separate the DACL (allow/deny) from the SACL (audit/alarm).
3. There are no privilege checks for modifying AUDIT/ALARM types, unlike in SMB; having WRITE_ACL access is sufficient. (The SMB server requires a client to have 'SeSecurityPrivilege', which it grants to members of the local Administrators group - smbadm show -m administrators).

I'll be looking these changes over starting maybe a week from now but one point lept out at me when reading the summary.

There are no privilege checks for modifying AUDIT/ALARM types, unlike in SMB; having WRITE_ACL access is sufficient. (The SMB server requires a client to have 'SeSecurityPrivilege', which it grants to members of the local Administrators group - smbadm show -m administrators).

This seems like a significant limitation as unwanted alarms are a serious irritant to people on call and unwanted audit records are a denial of service. Is it infeasible to add these checks to ZFS itself? Either of sys_audit or proc_audit (aka PRIV_SYS_AUDIT and PRIV_PROC_AUDIT) would at first glance be the ones to check for.

(Yes, I suspect it would be nasty to check in ZFS that an audit or alarm acl isn't being deleted when an acl is updated..)