[Pkg-utopia-maintainers] Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Luca Boccassi]

On Tue, 8 Aug 2023 10:08:26 +0100 Simon McVittie <smcv at debian.org>
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=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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20230808/5bb70c93/attachment.sig>