Comment 12 for bug 1853852

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

We know it fails at shmat, so we most likely can focus on that one.

i386 2.4.2
/* test_memory_deny_write_execute_shmat */
arch x86: SCMP_SYS(mmap) = 90
arch x86: SCMP_SYS(mmap2) = 192
arch x86: SCMP_SYS(shmget) = 395
arch x86: SCMP_SYS(shmat) = 397
arch x86: SCMP_SYS(shmdt) = 398
Operating on architecture: x86
Failed to add shmat() rule for architecture x86, skipping: Invalid argument
shmat(SHM_EXEC): Success
shmat(0): Success
memoryseccomp-shmat succeeded.

/* test_memory_deny_write_execute_shmat */
arch x86: SCMP_SYS(mmap) = 90
arch x86: SCMP_SYS(mmap2) = 192
arch x86: SCMP_SYS(shmget) = 395
arch x86: SCMP_SYS(shmat) = 397
arch x86: SCMP_SYS(shmdt) = 398
Operating on architecture: x86
shmat(SHM_EXEC): Success
shmat(0): Success

So the IDs detected did not change, but the behavior did.

libseccomp saw the bump to kernel 5.4 to include
- { "shmat", __PNR_shmat },
+ { "shmat", 397 },
But as we saw the effective ID didn't change.

[1]: https://github.com/systemd/systemd/blob/master/src/shared/seccomp-util.c#L1584
[2]: https://github.com/systemd/systemd/blob/master/src/test/test-seccomp.c#L560