Feature #11874


NFS file access audit logging

Added by Gordon Ross almost 4 years ago. Updated 7 months ago.

In Progress
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


Support auditing of file access using System Access Control Lists (SACLs)
similar to how the SMB server implements this.

See also: #11037 #11873

Related issues

Related to illumos gate - Feature #11037: SMB File access audit logging (reserve IDs)ClosedGordon Ross2019-05-15

Related to illumos gate - Bug #11873: SMB file access audit loggingIn ProgressMatt Barden

Blocked by illumos gate - Bug #14646: vnode_valid_pn() always fails for symlinksClosedMatt Barden

Blocked by illumos gate - Feature #11875: ZFS changes for file access auditingNewMatt Barden

Actions #1

Updated by Rich Lowe almost 4 years ago

  • Project changed from site to illumos gate
Actions #2

Updated by Joshua M. Clulow over 1 year ago

  • Blocked by Bug #14646: vnode_valid_pn() always fails for symlinks added
Actions #3

Updated by Joshua M. Clulow over 1 year ago

  • Related to Feature #11037: SMB File access audit logging (reserve IDs) added
  • Related to Bug #11873: SMB file access audit logging added
Actions #4

Updated by Gordon Ross over 1 year ago

  • Status changed from New to In Progress
  • Assignee changed from Gordon Ross to Matt Barden
Actions #5

Updated by Electric Monk about 1 year ago

  • Gerrit CR set to 2367
Actions #6

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.

Actions #7

Updated by Gordon Ross 7 months ago

  • Tags set to fs_auditing
Actions #8

Updated by Gordon Ross 7 months ago

  • Blocked by Feature #11875: ZFS changes for file access auditing added

Also available in: Atom PDF