Skip to content

F-5.13: NFSv4 Named Attributes (xattrs) Exposed on Export Root

Classification

  • Severity: Low (Information Disclosure)
  • CVSS Vector: Network / Low Complexity / Low Privileges Required
  • Affected Versions: NFSv4.0+
  • RFC Reference: RFC 7530 S5.3 (Named Attributes)
  • Prerequisite: NFSv4 access to the export root

Summary

NFSv4 named attributes (RFC 7530 S5.3) expose extended attributes (xattrs) through the OPENATTR + READDIR operation sequence. When issued against the export root, this enumerates all xattr names attached to the directory, which may include POSIX ACLs (system.posix_acl_access, system.posix_acl_default), SELinux labels (security.selinux), file capabilities (security.capability), trusted xattrs (trusted.*), and application-specific metadata. The presence and names of security-relevant xattrs reveal the MAC/DAC enforcement posture of the server without requiring the attacker to read the xattr values themselves.

Technical detail

OPENATTR + READDIR sequence

Named attributes in NFSv4 live in a hidden per-file attribute directory. Access follows a two-step protocol:

COMPOUND {
  PUTFH(export_root_fh),
  OPENATTR(createdir=false),   # opens the named-attribute directory
  READDIR(cookie=0, attrs=name) # lists all xattr names
}

If the file has named attributes, READDIR returns an entry for each one. The names are opaque strings, but by convention they follow the Linux xattr namespace scheme (system.*, security.*, user.*, trusted.*).

Security-relevant xattr namespaces

Namespace Example What It Reveals
system.posix_acl_access POSIX ACL Named USER/GROUP ACL entries grant access beyond mode bits
system.posix_acl_default Default POSIX ACL Inherited ACL for new files in the directory
system.nfs4_acl NFSv4 ACL Rich ACL with ALLOW/DENY ACEs
security.selinux SELinux label Indicates SELinux is enforcing; label reveals the security context
security.capability File capabilities Binary has elevated capabilities (cap_net_raw, cap_setuid, etc.)
security.ima IMA signature Integrity Measurement Architecture is active
trusted.* Root-only xattrs Metadata readable only by root -- presence signals admin tooling
user.* Application xattrs Application-specific metadata (backup tools, version control, etc.)

Intelligence value

The xattr names alone -- without reading their values -- provide:

  1. MAC enforcement posture: security.selinux present means SELinux is active. Its absence on a RHEL/Fedora server means SELinux is disabled or permissive.
  2. Capability-aware binaries: security.capability on any file indicates Linux file capabilities are in use, narrowing SUID/SGID attack surface analysis.
  3. ACL complexity: system.posix_acl_access signals that mode bits do not tell the full access story (see F-5.14).
  4. Integrity monitoring: security.ima indicates the server performs integrity checking, which may detect file modifications.

Severity escalation

The finding fires at Info severity when only user.* xattrs are present. When security-relevant namespaces (system.posix_acl*, security.*, trusted.*, system.nfs4_acl) are found, severity escalates to Low because the names leak the server's security architecture.

Impact

  • Security posture fingerprinting: xattr names reveal whether SELinux, IMA, POSIX ACLs, or file capabilities are in use
  • Attack surface narrowing: The presence or absence of security mechanisms guides which attacks to attempt and which to skip
  • Credential ladder input: POSIX ACL xattrs indicate that F-5.14 will yield named USER/GROUP entries for targeted escalation
  • No data exfiltration: This finding only leaks xattr names, not their values -- the actual ACL entries, SELinux labels, or capability sets require separate read operations

Detection (nfswolf)

The analyzer issues a COMPOUND containing PUTFH + OPENATTR + READDIR against each NFSv4 export root. If OPENATTR succeeds and READDIR returns entries, the finding fires. The severity depends on whether any security-relevant namespace prefixes are present in the returned names.

Remediation

  1. Review xattr exposure -- audit which named attributes are set on exported directories and whether their names leak useful information

  2. Restrict NFSv4 access -- use sec=krb5 to ensure only authenticated clients can issue OPENATTR

  3. Minimize security xattrs on export roots -- if POSIX ACLs or capabilities are not needed on the export root itself, remove them: 

    setfacl -b /export        # remove POSIX ACLs
getcap /export/bin/*       # audit file capabilities

  4. Consider subtree_check -- while it has performance costs, it restricts operations to the exported subtree

Finding Relationship
F-5.14: POSIX ACL Entries POSIX ACL xattr presence here predicts that F-5.14 will find named ACL entries
F-5.6: Metadata on Access Denial Metadata leaks complement xattr enumeration for full security posture mapping