LSM Hook Matrix

This is the definitive reference mapping file operations to LSM hooks and required access rights. Each entry specifies: enforcement mode (snapshot = granted mask check, live = AccessCheck against SD), the hook that fires, and the right(s) checked.

§14.1.1 File open and create #

For legacy namespace creation (open(O_CREAT), mkdir, mknod, and symlink), the create hook authorizes the parent-directory mutation and security_inode_init_security MUST stamp the new object with an inherited file SD. Legacy Linux creation APIs carry no caller-supplied KACS SD, so the creator-SD input is absent and the inheritance algorithm uses the current effective token plus the parent directory SD. On a FACS-managed mount, failure to compute or install the new SD fails the creation closed. On unmanaged mounts, FACS does not stamp an SD.

The security_inode_mknod hook is in scope only for explicit special node types: character device nodes, block device nodes, FIFOs, and pathname socket nodes. These new objects use file SD inheritance, not directory inheritance. Regular-file mknod is treated as ordinary file creation by the Linux VFS and reaches security_inode_create; directory creation reaches security_inode_mkdir; unsupported or unknown mknod mode types fail closed on FACS-managed mounts.

§14.1.2 Data operations (snapshot) #

§14.1.3 Truncate and allocate (snapshot) #

§14.1.4 Memory mapping (snapshot) #

§14.1.5 Metadata fd-based (snapshot, kernel patches) #

§14.1.6 Metadata path-based (live) #

SD-xattr internal-read exception. The (SD xattr: deny) rule above applies to caller-originated getxattr / fgetxattr syscalls: userspace must read SDs via kacs_get_sd, not via raw xattr reads. KACS itself reads the canonical SD xattr internally to populate its in-memory SD cache; it normally bypasses security_inode_getxattr by calling __vfs_getxattr directly. A stacking filesystem (overlayfs in particular) can re-enter the hook on the real lower/upper inode from inside its own xattr handler, where the bypass no longer applies. KACS marks itself as inside an internal SD read via a per-task counter (internal_sd_read_depth) around its __vfs_getxattr calls; the hook checks this counter and allows the canonical SD xattr read when it is non-zero. Userspace callers always see counter == 0, so the spec's deny remains in force for them.

§14.1.7 Link operations (live) #

§14.1.7.1 Link operation semantics #

DELETE / FILE_DELETE_CHILD duality. For unlink(), rmdir(), and the source side of rename(), the required right can be satisfied two ways: DELETE on the target's own SD, or FILE_DELETE_CHILD on the parent directory's SD. These are alternative gates checked against different SDs. The implementation checks the target file's SD for DELETE first; if denied, it checks the parent directory's SD for FILE_DELETE_CHILD. If neither grants the right, the operation is denied.

SD preservation on rename. A renamed file retains its existing SD. The inheritance algorithm does not re-execute when a file moves to a new directory. This matches Windows: moving a file does not change its DACL unless an administrator explicitly re-propagates inheritance.

Whiteout creation on rename. RENAME_WHITEOUT is supported natively on FACS-managed mounts: KACS does not refuse the flag and does not force callers onto the non-atomic vfs_mknod fallback. The mechanism splits security_inode_mknod's responsibilities across two existing hooks. The pre-rename patch authorizes FILE_ADD_FILE on the source parent (the whiteout occupies the source name once the renamed entry moves away) and emits the creation audit record; this fails closed, so a caller lacking FILE_ADD_FILE on the source parent gets the rename denied before any inode is touched. The whiteout inode itself is allocated through each filesystem's ordinary new-inode path, which runs security_inode_init_security; KACS stamps the whiteout's inherited file SD there, identically to any other freshly created node. The result is an atomic rename-plus-whiteout where both the parent mutation and the new sentinel are authorized, audited, and SD-stamped. The whiteout's fixed chrdev(0,0) mode addresses no device driver, so it carries no device-creation risk and requires no privilege beyond FILE_ADD_FILE — consistent with the parent-only authorization the mknod hook already applies to special nodes.

Sticky bit. The Linux sticky bit (restricted deletion flag) is a DAC concept. Under KACS, DAC is neutralized. FILE_DELETE_CHILD on the parent directory's SD is the sole gate for child deletion. The sticky bit has no effect under FACS.

link() FILE_WRITE_ATTRIBUTES. Creating a hardlink modifies the source inode's metadata (link count increments, ctime updates). FILE_WRITE_ATTRIBUTES on the source file's SD authorizes this mutation. This also prevents unauthorized hardlink creation to files the caller cannot modify -- a defense against hardlink-based attacks where an attacker creates a link to a privileged file in a directory they control.

Cross-mount rename. Linux returns -EXDEV for rename across mount boundaries. The VFS rejects the operation before the LSM hook fires. Not a KACS concern.

§14.1.8 Execution #

§14.1.9 Directory traversal #

§14.1.10 Locking (snapshot) #

§14.1.11 Unix sockets (live) #

Pathname sockets are protected via the socket file's inode SD (handled by FACS through the normal file open path). Abstract sockets store their SD on the socket's LSM security blob, stamped at bind() time from the binding thread's effective token.

The datagram hook authorizes sends to abstract sockets only; it does not capture a persistent KACS peer token. Datagram sockets, socketpair-created sockets, and ancillary credential messages (SCM_CREDENTIALS / SCM_SECURITY) are not KACS peer-token authorities in v0.20. kacs_open_peer_token and kacs_impersonate_peer fail closed unless the socket already carries a KACS peer token from the stream/seqpacket connect path.

socketpair() creates unnamed connected sockets. Access to those sockets is fd possession, and no socket SD or KACS peer token is installed by socketpair() in v0.20.

§14.1.12 IPC (live) #

SCM_CREDENTIALS and SCM_SECURITY remain Linux compatibility metadata in v0.20; they do not carry a KACS token handle, do not install a socket peer_token, and do not authorize impersonation.

§14.1.13 Miscellaneous #

§14.1.14 Process mitigation enforcement #

Mitigation setting is also an enforcement point. kacs_set_psb MUST perform the activation-backed transaction defined by §5.2 before committing newly requested mitigation bits.

§14.1.15 Credential management #

§14.1.16 Process lifecycle #

§14.1.17 Socket lifecycle #