Syscall fchmodat2 allows to create suid binaries

[Ma27]

Describe the bug

To quote from NixOS/nixpkgs#300635 (comment):

With kernel ≥6.6 and glibc 2.39, lxc's install phase uses fchmodat2, which slips through

nix/src/libstore/build/local-derivation-goal.cc

Lines 1650 to 1663 in 9b88e52

	/* Prevent builders from creating setuid/setgid binaries. */
	for (int perm : { S_ISUID, S_ISGID }) {
	if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(chmod), 1,
	SCMP_A1(SCMP_CMP_MASKED_EQ, (scmp_datum_t) perm, (scmp_datum_t) perm)) != 0)
	throw SysError("unable to add seccomp rule");
	if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(fchmod), 1,
	SCMP_A1(SCMP_CMP_MASKED_EQ, (scmp_datum_t) perm, (scmp_datum_t) perm)) != 0)
	throw SysError("unable to add seccomp rule");
	if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(fchmodat), 1,
	SCMP_A2(SCMP_CMP_MASKED_EQ, (scmp_datum_t) perm, (scmp_datum_t) perm)) != 0)
	throw SysError("unable to add seccomp rule");
	}

. The fixupPhase then uses fchmodat, which fails.
With older kernel or glibc, setting the suid bit fails in the install phase, which is not treated as fatal, and then the fixup phase does not try to set it again.

As @lf- points out, the use of the seccomp sandbox against creating suid binaries is questionable (NixOS/nixpkgs#300635 (comment)) since the restriction can be bypassed easily by using the open(2) syscall for the exact same purpose and the permissions will be wiped later on.

What I'd like to achieve is that we get a fix for that scenario to make sure people aren't running into the problem when upgrading to 24.05. The builds from nixpkgs appear fixed (or actually, worked around), but a lot of people will also build custom stuff.

If you agree on removing the chmod restriction, that's one way forward.
If that requires further discussion, I'll file a patch to add fchmodat2 to

nix/src/libstore/build/local-derivation-goal.cc

Lines 1650 to 1663 in 8b16cce

	/* Prevent builders from creating setuid/setgid binaries. */
	for (int perm : { S_ISUID, S_ISGID }) {
	if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(chmod), 1,
	SCMP_A1(SCMP_CMP_MASKED_EQ, (scmp_datum_t) perm, (scmp_datum_t) perm)) != 0)
	throw SysError("unable to add seccomp rule");
	if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(fchmod), 1,
	SCMP_A1(SCMP_CMP_MASKED_EQ, (scmp_datum_t) perm, (scmp_datum_t) perm)) != 0)
	throw SysError("unable to add seccomp rule");
	if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(fchmodat), 1,
	SCMP_A2(SCMP_CMP_MASKED_EQ, (scmp_datum_t) perm, (scmp_datum_t) perm)) != 0)
	throw SysError("unable to add seccomp rule");
	}

to have a short-term resolution.

cc @NixOS/nix-team
cc @vcunat
cc @lf-

Priorities

Add 👍 to issues you find important.

[lf-]

fyi i think there is possibly an ongoing private security issue related to this, in case you are wondering about lack of response.

[thufschmitt]

If you agree on removing the chmod restriction, that's one way forward.

The chmod restriction is quite fragile, and I'd like to see it removed, but I don't think it would be wise to do it right now. If anything, it's useful for the “try to remove accidental impurities” part of the sandbox

If that requires further discussion, I'll file a patch to add fchmodat2 to

That would be much appreciated, yes :)

[thufschmitt]

Regarding

the restriction can be bypassed easily by using the open(2) syscall for the exact same purpose

In case other people than me try to use this: It seems that it can't (at least not easily) be used for that because it can only create empty setuid files (rather useless), and writing anything to them drops the setuid bit