Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

Simon McVittie smcv at debian.org
Tue Aug 8 10:08:26 BST 2023


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=40000003 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



More information about the Pkg-systemd-maintainers mailing list