NFS file access audit logging
Updated by Matt Barden about 1 year ago
This project enhances the NFS server so that it can generate audit events, through the existing BSM audit infrastructure, based on any AUDIT- or ALARM-type ACEs present on any ZFS file/directory shared over the protocol. It builds on the work done in #11873.
Unlike SMB, NFSv4 does not have strong open mechanics (they're optional for the client to use, and it does not limit an open to accesses requested at the time the handle was opened). As such, AUE_SACL events generated by NFS represent the access used in performing an operation, as opposed to the access requested at time of open. This also means that records are generated on every single auditable operation; a million GETATTR requests will generate a million READ_ATTRIBUTE records.
The audit-class mask - as well as the 'audit-uid' included in the record - are set in the credential based on the user the client authenticates as to the server, and NOT as the user to which an export maps the client. The record still includes the 'real' and 'effective' UID/GIDs that represent the user to which the export maps the client. This implements the same behavior as existing login records: 'audit-uid' is the UID assigned to the user when the session is established, and ruid/euid represent the current state of the user.
Audit information is cached using the same mechanism as access/identity mapping is cached in NFS today. Both types of cache use exactly the same infrastructure, with the cached object being a union of the two types. See usr/src/uts/common/nfs/nfsauth_cache.h:98 for the relevant structures and a brief discussion of how they coexist.
1. Only NFSv4 is supported. Without RPCSEC_GSS, audit records don't reliably attribute events to a particular user (identity is falsifiable).
2. Because the NFS server does not track file names the way SMB does, we must calculate a pathname before performing the relevant operation. It is also possible to have a file whose vnode has no v_path, as NFS allows accessing files via a persistent handle, bypassing name-based lookup. If that happens, we can't proceed - without a path, the audit records are difficult-to-impossible to use. We thus return ESTALE in this case, but not all applications/clients handle this gracefully.
3. AUDIT/ALARM type ACEs are not viewable or settable over the illumos NFS server. Neither the client nor server support this (this is a pre-existing limitation), though it's part of the protocol. NFS servers have no means of knowing whether a client supports these, there is no privilege system in the NFS server, and modifying AUDIT/ALARM type ACEs require no privilege (unlike SMB, which requires SeSecurityPrivilege). Thus, the NFS server filters these ACEs out of any ACL returned to a client, and merges any existing ones into any ACL set by a client, in order to protect them from unprivileged modification or clients that don't support them.
4. The NFS server generates far many more records than SMB for the same workload, due to generating a record on every operation that matches the set SACL.