Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
On Tue, 12 Mar 2024 at 22:30:01 +0100, Michael Biebl wrote: > On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer wrote: > > My speculation is that this happened while satisfying dependencies for > > a third party i386 application. That meant installing required 32 bit > > libraries, and one of them must have come with a polkitd dependency, > > and the i386 version was selected because I was installing an i386 > > package. ... > Is there a valid use case where we need/want a foreign systemd/policykit-1? The valid use-case for polkitd being Multi-Arch: foreign is the scenario Bertram described: you install third-party, potentially binary-only i386 software onto an amd64 system, and it depends on polkitd. We want polkitd:amd64 to be able to satisfy that dependency. That's also why we want systemd(-sysv) to be Multi-Arch: foreign: for example the i386-only quake4-server needs systemd (in that case it's actually a only Recommends, because you don't *need* to use the systemd units, but it could in principle have been a Depends) and we want systemd(-sysv):amd64 to satisfy that dependency. I don't know of any valid use-case for polkitd and systemd(-sysv) being of an architecture that is not the same as the system's primary architecture, except for perhaps briefly during crossgrading, but that isn't what Multi-Arch: foreign means anyway. "The primary architecture" really just means "the same architecture as dpkg", and I don't think there is any metadata that could be set on polkitd or systemd to say that they must be of that same architecture. smcv
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
Michael Biebl wrote: > I've contemplated dropping the Multi-Arch: foreign notation in systemd and > maybe also for policykit-1. > > Is there a valid use case where we need/want a foreign systemd/policykit-1? Wouldn't that go in the wrong direction? I'd think that we want the native systemd or policykit daemon to satisfy a foreign dependency, and that's what `Multi-Arch: foreign` allows. In fact https://wiki.ubuntu.com/MultiarchSpec#line-1-3 suggests that the scenario I ended up in *should* not have happened; the installer should've preferred the native (amd64 for me) version of the package. So that's an argument in favor of leaving things as they are. Bertram
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer wrote: Luca Boccassi wrote: [...] > I don't think this is something we should facilitate by default or > spend any energy on. > > You can correct me if I'm wrong, but I don't see any good reason why > anybody would need to run a polkitd:i386 on an otherwise amd64 system. > It's not what happens by default if you have i386 enabled and you type > 'apt install polkitd' or so. I agree that there isn't a good reason, and I'm not sure how I ended up in that situation in the first place (the log files don't go back far enough). One thing I do know is that polkitd:i386 was marked as automatically installed, so I almost certainly did not make that decision deliberately. My speculation is that this happened while satisfying dependencies for a third party i386 application. That meant installing required 32 bit libraries, and one of them must have come with a polkitd dependency, and the i386 version was selected because I was installing an i386 package. Anyway, I reported this because I assumed that pinning packages to the native architecture was easy, so it would be justified even for this (hopefully!) rare scenario... apparently that's not the case. As mentioned, unfortunately there is no way to express this dependency in a strait forward way. I've contemplated dropping the Multi-Arch: foreign notation in systemd and maybe also for policykit-1. Is there a valid use case where we need/want a foreign systemd/policykit-1? Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
Luca Boccassi wrote: [...] > I don't think this is something we should facilitate by default or > spend any energy on. > > You can correct me if I'm wrong, but I don't see any good reason why > anybody would need to run a polkitd:i386 on an otherwise amd64 system. > It's not what happens by default if you have i386 enabled and you type > 'apt install polkitd' or so. I agree that there isn't a good reason, and I'm not sure how I ended up in that situation in the first place (the log files don't go back far enough). One thing I do know is that polkitd:i386 was marked as automatically installed, so I almost certainly did not make that decision deliberately. My speculation is that this happened while satisfying dependencies for a third party i386 application. That meant installing required 32 bit libraries, and one of them must have come with a polkitd dependency, and the i386 version was selected because I was installing an i386 package. Anyway, I reported this because I assumed that pinning packages to the native architecture was easy, so it would be justified even for this (hopefully!) rare scenario... apparently that's not the case. Cheers, Bertram
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
On Tue, 8 Aug 2023 10:08:26 +0100 Simon McVittie wrote: > On Thu, 03 Aug 2023 at 18:34:14 +0200, Bertram Felgenhauer wrote: > > for reasons lost in time I had polkitd:i386 installed on an x86_64 host. > > > > After the update to 123-1, polkitd stopped working with errors like > > > > [ 2080.436059] audit: type=1326 audit(1691077090.861:74): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=4252 comm="polkitd" exe="/usr/lib/polkit-1/polkitd" sig=31 arch=4003 syscall=45 compat=1 ip=0xf7f51887 code=0x0 > > > > This is due to the addition of system call filtering in the polkit > > systemd unit: > > > > SystemCallArchitectures=native # (which is not i386) > > SystemCallFilter=@system-service > > > > The solution is to install polkitd in its native version. > > > > Can this be fixed by strengthening dependencies? > > (Say, tie the architecture to that of systemd...) > > I don't see a straightforward way to achieve that, because polkitd > doesn't depend on systemd (and shouldn't depend on systemd, because it > can work without) - and even if it did, systemd is Multi-Arch: foreign, > so a dependency on systemd by an i386 package would be satisfied by > systemd:amd64. > > The only way I can see to make this work would be for systemd to provide > an empty metapackage, systemd-native-architecture or something, which > would *not* be Multi-Arch: foreign; and then both polkitd and systemd > could depend on that metapackage, to force them to be installed for the > same architecture (whatever that architecture might be). > > Can the systemd maintainers see any routes to solve this that are less > intrusive than that? > > This was reported as a polkitd bug, but would affect any service with > SystemCallArchitectures=native equally. > > The purpose of SystemCallArchitectures=native is as security hardening > to prevent a compromised service from accessing non-default kernel > ABIs, like i386 or x32 on an amd64 system (which are often less > well-hardened than the native ABI). A secondary purpose is that > for historical reasons i386 cannot filter socket-related syscalls > as effectively as amd64 can, so services that filter sockets > (like polkitd's use of RestrictAddressFamilies=AF_UNIX) want to use > SystemCallArchitectures=native to prevent an amd64 service from bypassing > that filter by making i386 syscalls. I don't think this is something we should facilitate by default or spend any energy on. You can correct me if I'm wrong, but I don't see any good reason why anybody would need to run a polkitd:i386 on an otherwise amd64 system. It's not what happens by default if you have i386 enabled and you type 'apt install polkitd' or so. If someone wants for any reason to have such a non-default setup, then they can just add a drop-in that disables SystemCallArchitectures= and whatnot in /etc - user/admin drop-ins are fully supported exactly to allow local modifications. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
On Thu, 03 Aug 2023 at 18:34:14 +0200, Bertram Felgenhauer wrote: > for reasons lost in time I had polkitd:i386 installed on an x86_64 host. > > After the update to 123-1, polkitd stopped working with errors like > > [ 2080.436059] audit: type=1326 audit(1691077090.861:74): auid=4294967295 > uid=0 gid=0 ses=4294967295 subj=unconfined pid=4252 comm="polkitd" > exe="/usr/lib/polkit-1/polkitd" sig=31 arch=4003 syscall=45 compat=1 > ip=0xf7f51887 code=0x0 > > This is due to the addition of system call filtering in the polkit > systemd unit: > > SystemCallArchitectures=native # (which is not i386) > SystemCallFilter=@system-service > > The solution is to install polkitd in its native version. > > Can this be fixed by strengthening dependencies? > (Say, tie the architecture to that of systemd...) I don't see a straightforward way to achieve that, because polkitd doesn't depend on systemd (and shouldn't depend on systemd, because it can work without) - and even if it did, systemd is Multi-Arch: foreign, so a dependency on systemd by an i386 package would be satisfied by systemd:amd64. The only way I can see to make this work would be for systemd to provide an empty metapackage, systemd-native-architecture or something, which would *not* be Multi-Arch: foreign; and then both polkitd and systemd could depend on that metapackage, to force them to be installed for the same architecture (whatever that architecture might be). Can the systemd maintainers see any routes to solve this that are less intrusive than that? This was reported as a polkitd bug, but would affect any service with SystemCallArchitectures=native equally. The purpose of SystemCallArchitectures=native is as security hardening to prevent a compromised service from accessing non-default kernel ABIs, like i386 or x32 on an amd64 system (which are often less well-hardened than the native ABI). A secondary purpose is that for historical reasons i386 cannot filter socket-related syscalls as effectively as amd64 can, so services that filter sockets (like polkitd's use of RestrictAddressFamilies=AF_UNIX) want to use SystemCallArchitectures=native to prevent an amd64 service from bypassing that filter by making i386 syscalls. smcv
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
Package: polkitd Version: 123-1 Severity: normal File: /usr/lib/polkit-1/polkitd Dear Maintainer, for reasons lost in time I had polkitd:i386 installed on an x86_64 host. After the update to 123-1, polkitd stopped working with errors like [ 2080.436059] audit: type=1326 audit(1691077090.861:74): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=4252 comm="polkitd" exe="/usr/lib/polkit-1/polkitd" sig=31 arch=4003 syscall=45 compat=1 ip=0xf7f51887 code=0x0 This is due to the addition of system call filtering in the polkit systemd unit: SystemCallArchitectures=native # (which is not i386) SystemCallFilter=@system-service The solution is to install polkitd in its native version. Can this be fixed by strengthening dependencies? (Say, tie the architecture to that of systemd...) Cheers, Bertram -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages polkitd depends on: ii adduser 3.137 ii dbus [default-dbus-system-bus] 1.14.8-1 ii libc6 2.36-9 ii libduktape207 2.7.0-2 ii libexpat1 2.5.0-2 ii libglib2.0-02.76.4-4 ii libpam-systemd [logind] 254-1 ii libpam0g1.5.2-6 ii libpolkit-agent-1-0 123-1 ii libpolkit-gobject-1-0 123-1 ii libsystemd0 254-1 ii systemd [systemd-sysusers] 254-1 ii xml-core0.18+nmu1 polkitd recommends no packages. Versions of packages polkitd suggests: pn polkitd-pkla Versions of packages polkitd is related to: pn elogind pn libpam-elogind ii libpam-systemd 254-1 ii systemd 254-1 -- no debconf information
