Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#55125 - [systemd] 234.11-6: Seccomp has been disabled since 233.75-3

Attached to Project: Arch Linux
Opened by MushiMushy (MushiMushy) - Sunday, 13 August 2017, 11:02 GMT
Last edited by Christian Hesse (eworm) - Monday, 14 August 2017, 08:02 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

The last version of systemd that was build with support for seccomp was 233.75-2 and for about a month now systemd has been reporting -SECCOMP in the journal. Disabling seccomp seems to disable some security features such as MemoryDenyWriteExecute and SystemCallFilter which were all used in many of the units that come with systemd at least.

I was trying to use MemoryDenyWriteExecute as a replacement for a PAX_MPROTECT now that linux-grsec is no more which made me notice that the option is silently ignored.

I wonder if disabling seccomp was done on purpose as I find no mention of disabling it in release logs and PKGBUILD still depends on libseccomp. Maybe it should be enabled?
This task depends upon

Closed by  Christian Hesse (eworm)
Monday, 14 August 2017, 08:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd 234.11-8
Comment by loqs (loqs) - Sunday, 13 August 2017, 16:45 GMT
$ systemctl --version
systemd 234
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid
However /usr/lib/systemd/system/systemd-journald.service uses SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap
With systemd 234.11-6 I am not seeing any output from that service refering to -SECCOMP
So is the meson autodetection of libseccomp failing? https://github.com/systemd/systemd/blob/v234/meson.build#L649
Comment by loqs (loqs) - Sunday, 13 August 2017, 17:04 GMT
I think libseccomp is missing from the makedepends array.
Comment by MushiMushy (MushiMushy) - Sunday, 13 August 2017, 18:37 GMT
You can see the the options are ignored with:
$ systemctl show systemd-journald --property=SystemCallFilter --property=MemoryDenyWriteExecute
SystemCallFilter=~
MemoryDenyWriteExecute=no

If I rebuild systemd without any changes in PKGBUILD, libseccomp does get detected and the above command shows:
SystemCallFilter=~_sysctl add_key adjtimex afs_syscall bdflush break chroot cloc k_adjtime...
MemoryDenyWriteExecute=yes
Comment by loqs (loqs) - Sunday, 13 August 2017, 18:46 GMT
Are you rebuilding it in a clean chroot with only the base-devel group and not the base group installed implicitly?
Comment by loqs (loqs) - Sunday, 13 August 2017, 18:52 GMT
$ bsdtar -xf /var/cache/pacman/pkg/systemd-234.11-6-x86_64.pkg.tar.xz
$ grep libseccomp .BUILDINFO
So libseccomp was not present in the build environment.
Comment by MushiMushy (MushiMushy) - Sunday, 13 August 2017, 18:57 GMT
Ah, nope, not using any chroot.

I'm not sure about having to include libseccomp in makedepends though. I cannot run makepkg before I have installed all packages that are defined in the depends array.
Comment by MushiMushy (MushiMushy) - Sunday, 13 August 2017, 19:07 GMT
@loqs
Ok, I thought a build was not possible without libseccomp.
Comment by loqs (loqs) - Sunday, 13 August 2017, 19:28 GMT
makepkg will install all packages that are defined in the depends array but not the depends array from a split packages package_packagename function
See https://ptpb.pw/CyvI as a quick example I through together.
Comment by Eli Schwartz (eschwartz) - Sunday, 13 August 2017, 19:29 GMT
Hmm, diffing the build environment between 233.75-2 and 233.75-3 it appears the difference is that "systemd" was not installed in -3, and of course it is "systemd" that depends on libseccomp in the first place... thereby dragging in its own makedepends. Which is not something that should ever be relied upon. :(

FWIW the only reason systemd was ever in the build environment either is because device-mapper<=2.02.172-2 depended on it, though now it depends on libsystemd only. :)
Comment by MushiMushy (MushiMushy) - Sunday, 13 August 2017, 20:21 GMT
@loqs Right, thanks.

Nice to see this getting attention so soon.

Loading...