+++ This bug was initially created as a clone of Bug #1960708 +++

5.9 introduced a new capability in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/capability.h?h=v5.9&id=124ea650d3072b005457faed69909221c2905a1f

Please backport this commit so that util-linux can pick it up (specifically for setpriv). This is something we need for the CentOS Hyperscale SIG (https://pagure.io/centos-sig-hyperscale/sig/issue/43) but it would also be generally useful. For reference, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=74858abbb1032222f922487fd1a24513bbed80f9 is the full merge commit with all related changes. Thanks!

--- Additional comment from Davide Cavalca on 2021-05-14 18:20:20 CEST ---

Not sure why this bug got marked as private, could you please make it public?

--- Additional comment from Davide Cavalca on 2021-05-14 19:24:54 CEST ---

fyi, https://git.centos.org/rpms/util-linux/c/128f2ce4adb3b8002efcea69f070e450bccd7378?branch=c8s-sig-hyperscale is the horrible hack I'm using to workaround this at the moment

--- Additional comment from Stanislav Kozina on 2021-06-09 15:40:35 CEST ---

@cye, can you help us to find QE owner for this please? Thank you!

--- Additional comment from Adrian Reber on 2021-06-09 17:36:12 CEST ---

There is currently nothing which needs CAP_CHECKPOINT_RESTORE in RHEL 8. I will still try to see if this can be easily backported.

--- Additional comment from Adrian Reber on 2021-06-11 10:50:23 CEST ---

@omosnace I see comments around SELinux for the backport concerning CAP_BPF and CAP_PERFMON. Do you see any problems if I backport CAP_CHECKPOINT_RESTORE? Does that also have SELinux implications.

--- Additional comment from Ondrej Mosnacek on 2021-06-11 12:07:35 CEST ---

Yes, although in this case it should be very straightforward - the capability would just need to be added to the policy (one-line change). We did this in Fedora 34 and so far didn't get any related denials reported, so I wouldn't expect any breakage in RHEL-8 either.

(Technically, the only thing that would break if policy wasn't updated would be that a warning would appear in dmesg at policy load and the capability would be always denied with selinux-policy-mls, falling back to CAP_SYS_ADMIN, but we should still do the right thing.)

Regarding the policy change, you'll have to coordinate with Zdenek, who maintains the selinux-policy package.

--- Additional comment from Adrian Reber on 2021-06-14 09:11:59 CEST ---

(In reply to Ondrej Mosnacek from comment #6)
> Yes, although in this case it should be very straightforward - the
> capability would just need to be added to the policy (one-line change). We
> did this in Fedora 34 and so far didn't get any related denials reported, so
> I wouldn't expect any breakage in RHEL-8 either.
> 
> (Technically, the only thing that would break if policy wasn't updated would
> be that a warning would appear in dmesg at policy load and the capability
> would be always denied with selinux-policy-mls, falling back to
> CAP_SYS_ADMIN, but we should still do the right thing.)
> 
> Regarding the policy change, you'll have to coordinate with Zdenek, who
> maintains the selinux-policy package.

@zpytela do you think the necessary policy changes for CAP_CHECKPOINT_RESTORE can be part of 8.5?

--- Additional comment from Zdenek Pytela on 2021-06-14 11:27:42 CEST ---

(In reply to Adrian Reber from comment #7)
> (In reply to Ondrej Mosnacek from comment #6)
> > Yes, although in this case it should be very straightforward - the
> > capability would just need to be added to the policy (one-line change). We
> > did this in Fedora 34 and so far didn't get any related denials reported, so
> > I wouldn't expect any breakage in RHEL-8 either.
> > 
> > (Technically, the only thing that would break if policy wasn't updated would
> > be that a warning would appear in dmesg at policy load and the capability
> > would be always denied with selinux-policy-mls, falling back to
> > CAP_SYS_ADMIN, but we should still do the right thing.)
> > 
> > Regarding the policy change, you'll have to coordinate with Zdenek, who
> > maintains the selinux-policy package.
> 
> @zpytela do you think the necessary policy changes for
> CAP_CHECKPOINT_RESTORE can be part of 8.5?
Adrian,

I conditionally agree, it's true we haven't seen any report in Fedora and we seem to have exactly 0 rules using it, but we need to look for possible regressions in RHEL before adding there. Do you have any tests or real usage examples?

Also note the selinux capability will be present in RHEL 9, together with other similar changes.

--- Additional comment from Adrian Reber on 2021-06-14 16:30:03 CEST ---

Possible test case to verify CAP_CHECKPOINT_RESTORE:

#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
	int fd, pid;
	char buf[32];

	if (argc != 2)
		return 1;

	printf("Opening ns_last_pid...\n");
	fd = open("/proc/sys/kernel/ns_last_pid", O_RDWR);
	if (fd < 0) {
		perror("Can't open ns_last_pid");
		return 1;
	}
	printf("Done\n");

	pid = atoi(argv[1]);
	snprintf(buf, sizeof(buf), "%d", pid - 1);

	printf("Writing pid-1 to ns_last_pid...\n");
	if (write(fd, buf, strlen(buf)) != strlen(buf)) {
		printf("Can't write to buf\n");
		return 1;
	}
	printf("Done\n");

	printf("Forking...\n");
	int new_pid;

	new_pid = fork();
	if (new_pid == 0) {
		printf("I'm child!\n");
		exit(0);
	} else if (new_pid == pid) {
		printf("I'm parent. My child got right pid!\n");
	} else {
		printf("pid does not match expected one\n");
	}
	printf("Done\n");

	close(fd);

	printf("Done\n");

	return 0;
}

With a 'setcap cap_checkpoint_restore+eip ns_last_pid' this can run as non-root.

--- Additional comment from Zdenek Pytela on 2021-06-14 20:16:27 CEST ---

Thank you for the code example, we can use it for testing, it also made me realize the permission actually is allowed in SELinux for init_t and unconfined domains.

For a confined user staff_t, on the other hand, the permission is not set and AVC denial is triggered (plus one follow-up for setroubleshootd):

----
type=PROCTITLE msg=audit(06/14/21 19:46:19.800:3455) : proctitle=/usr/local/sbin/bz1960708 43333 
type=PATH msg=audit(06/14/21 19:46:19.800:3455) : item=0 name=/proc/sys/kernel/ns_last_pid inode=170159 dev=00:16 mode=file,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysctl_kernel_ns_last_pid_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(06/14/21 19:46:19.800:3455) : cwd=/home/staff
type=SYSCALL msg=audit(06/14/21 19:46:19.800:3455) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x402027 a2=O_RDWR a3=0x0 items=1 ppid=43192 pid=43240 auid=staff uid=staff gid=staff euid=staff suid=staff fsuid=staff egid=staff sgid=staff fsgid=staff tty=pts1 ses=6 comm=bz1960708 exe=/usr/local/sbin/bz1960708 subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(06/14/21 19:46:19.800:3455) : avc:  denied  { write } for  pid=43240 comm=bz1960708 name=ns_last_pid dev="proc" ino=170159 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_kernel_ns_last_pid_t:s0 tclass=file permissive=0
----
type=PROCTITLE msg=audit(06/14/21 19:46:19.822:3456) : proctitle=/usr/bin/python3 -Es /usr/sbin/setroubleshootd -f
type=PATH msg=audit(06/14/21 19:46:19.822:3456) : item=0 name=/proc/sys/kernel/ns_last_pid inode=170159 dev=00:16 mode=file,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysctl_kernel_ns_last_pid_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(06/14/21 19:46:19.822:3456) : cwd=/
type=SYSCALL msg=audit(06/14/21 19:46:19.822:3456) : arch=x86_64 syscall=newfstatat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7f21671c7510 a2=0x7f2167120f60 a3=0x0 items=1 ppid=1 pid=43225 auid=unset uid=setroubleshoot gid=setroubleshoot euid=setroubleshoot suid=setroubleshoot fsuid=setroubleshoot egid=setroubleshoot sgid=setroubleshoot fsgid=setroubleshoot tty=(none) ses=unset comm=setroubleshootd exe=/usr/bin/python3.9 subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
type=AVC msg=audit(06/14/21 19:46:19.822:3456) : avc:  denied  { getattr } for  pid=43225 comm=setroubleshootd path=/proc/sys/kernel/ns_last_pid dev="proc" ino=170159 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:sysctl_kernel_ns_last_pid_t:s0 tclass=file permissive=0

--- Additional comment from Adrian Reber on 2021-06-16 17:38:33 CEST ---

@cye can you qa_ack?

--- Additional comment from kernel-workflow-bot on 2021-06-17 09:07:10 CEST ---

The following Merge Request has pipeline job artifacts available:

Title: capabilities: Introduce CAP_CHECKPOINT_RESTORE
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/merge_requests/813
Pipeline: https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/pipelines/322188614

This Repo URL is *not* accessible from a web browser! It only functions as a dnf or yum baseurl.
Repo URL: https://s3.upshift.redhat.com/DH-PROD-CKI/internal/322188928/$basearch/4.18.0-314.el8.mr813_210616_1708.$basearch


4.18.0-314.el8.mr813_210616_1708.s390x:
Gitlab browser: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770364/artifacts/browse/artifacts/repo/4.18.0-314.el8.mr813_210616_1708.s390x/
Job: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770452
Current automated test status: success

4.18.0-314.el8.mr813_210616_1708.ppc64le:
Gitlab browser: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770355/artifacts/browse/artifacts/repo/4.18.0-314.el8.mr813_210616_1708.ppc64le/
Job: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770447
Current automated test status: success

4.18.0-314.el8.mr813_210616_1708.aarch64:
Gitlab browser: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770348/artifacts/browse/artifacts/repo/4.18.0-314.el8.mr813_210616_1708.aarch64/
Job: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770428
Current automated test status: success

4.18.0-314.el8.mr813_210616_1708.x86_64:
Gitlab browser: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770339/artifacts/browse/artifacts/repo/4.18.0-314.el8.mr813_210616_1708.x86_64/
Job: https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-internal-contributors/-/jobs/1352770421
Current automated test status: success