add key retention and requesting service syscalls to the default seccomp

[afbase]

Historical Context

In Late December 2015, it was decided to exclude the add_key, keyctl, and request_key syscalls in the new default seccomp profile in the moby project. The rationale was that these syscalls for the Kernel Key Retention and Kernel Key Requesting were not user namespaced.

In January 2016, @jessfraz wrote about the newly released default seccomp profile. Jess also contributed to incorporating seccomp profiles into kubernetes later that year.

In 2019, @dhowells and @thejh worked on these syscalls to respect user namespace boundaries.

Why These Syscalls Are Now Safe

The original 2015 security concerns have been addressed through specific kernel code changes that ensure proper user namespace isolation. Here are some examples:

1. Namespace-Aware Keyring Access

The add_key syscall now operates within the caller's user namespace context through lookup_user_key():

/* find the target keyring (which must be writable) */
keyring_ref = lookup_user_key(ringid, KEY_LOOKUP_CREATE, KEY_NEED_WRITE);

This function ensures containers can only access keyrings that exist within their namespace boundary, preventing cross-namespace key access.

2. Namespace Validation for Key Operations

Key ownership changes are validated within the caller's namespace via keyctl_chown_key:

uid = make_kuid(current_user_ns(), user);
gid = make_kgid(current_user_ns(), group);
ret = -EINVAL;
if ((user != (uid_t) -1) && !uid_valid(uid))
    goto error;

3. Namespace-Aware Request Key Operations

The request_key syscall properly handles namespace translation during userspace callouts in request_key.c:

/* record the UID and GID */
sprintf(uid_str, "%d", from_kuid(&init_user_ns, cred->fsuid));
sprintf(gid_str, "%d", from_kgid(&init_user_ns, cred->fsgid));

[afbase]

same issue as describe in containers/common#2487 (comment). going to close this 😭