Bug#1023393: policykit-1: Not prompted to authenticate with my own identity any more

[Sam Morris]

Package: polkitd
Version: 122-1
Severity: important
X-Debbugs-Cc: s...@robots.org.uk

Since updating to 122, polkit authentication prompts ask me to
authenticate as "Administrator" (root?) rather than my own user.

Here's my configuration:

# cat /etc/polkit-1/localauthority.conf.d/60-sam.conf
[Configuration]
AdminIdentities=unix-user:sam.m...@domain.example.com

# pkla-admin-identities
unix-user:sam.m...@domain.example.com

So it looks like polkitd-pkla still recognizes me as an administrator.

pkla-check-authorization however indicates that maybe my user is allowed
to connect/disconnect pre-existing network connections but is _not_
allowed to edit network connections. So maybe the problem is with
polkitd-pkla after all?

# pkla-check-authorization sam.m...@domain.example.com true true org.freedesktop.NetworkManager.network-control
yes

# pkla-check-authorization sam.m...@domain.example.com true true org.freedesktop.NetworkManager.settings.modify.system; echo $?
0

For the end to end test I'm running this command, which prompts me for
root's password rather than my own.

$ pkcheck -a org.freedesktop.NetworkManager.settings.modify.system -u -p $$
polkit\56dismissed=true
polkit\56retains_authorization_after_challenge=true
Authentication request was dismissed.

So based on that it's not clear to me whether the problem lies in
polkitd or polkitd-pkla...

Not sure whether the problem is with polkit itself or polkitd-pkla.
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages policykit-1 depends on:
ii pkexec 122-1
ii polkitd 122-1

Versions of packages policykit-1 recommends:
ii polkitd-pkla 122-1

policykit-1 suggests no packages.

Versions of packages polkitd depends on:
ii adduser 3.118
ii dbus [default-dbus-system-bus] 1.12.24-0+deb11u1
ii libc6 2.35-4
ii libduktape207 2.7.0-1+b1
ii libexpat1 2.2.10-2+deb11u5
ii libglib2.0-0 2.74.1-1
ii libpam-systemd [logind] 251.6-1
ii libpam0g 1.4.0-9+deb11u1
ii libpolkit-agent-1-0 122-1
ii libpolkit-gobject-1-0 122-1
ii libsystemd0 251.6-1
ii systemd [systemd-sysusers] 251.6-1
ii xml-core 0.18+nmu1

Versions of packages polkitd suggests:
ii polkitd-pkla 122-1

-- no debconf information

[Simon McVittie]

On Thu, 03 Nov 2022 at 11:51:52 +0000, Sam Morris wrote:
> Here's my configuration:
>
> # cat /etc/polkit-1/localauthority.conf.d/60-sam.conf
> [Configuration]
> AdminIdentities=unix-user:sam.m...@domain.example.com

Is that really your Unix/PAM login name, the one you'd get from `id -nu`
or `su - $user` or similar? Or is your login name something like sam.morris
or sam?

The usual setup with a modern polkit version is that the admin identities
are handled by /usr/share/polkit-1/rules.d/40-debian-sudo.rules,
which returns "unix-group:sudo", meaning "any member of the sudo group
is a local sysadmin".

It's usually unnecessary to configure this, either in the old PKLA
backend or in the newer JS backend, so the way this interoperates with
the legacy PKLA configuration is unlikely to be particularly well-tested.

I wonder whether the problem here might be that 40-debian-sudo.rules is
sequenced earlier than 49-polkit-pkla-compat.rules, which means only the
function defined in 40-debian-sudo.rules gets called, and the one in
49-polkit-pkla-compat.rules is ignored?

If you uncomment the polkit.log calls in
/usr/share/polkit-1/rules.d/49-polkit-pkla-compat.rules and then run

sudo /usr/lib/polkit-1/polkitd --replace

from a terminal, then you'll be able to see whether the
backwards-compat admin rule function is getting called. Similarly,
if you edit /usr/share/polkit-1/rules.d/40-debian-sudo.rules and
/usr/share/polkit-1/rules.d/50-default.rules to look like this:

polkit.addAdminRule(function(action, subject) {
polkit.log('Using sudo group');
return ["unix-group:sudo"];
});

polkit.addAdminRule(function(action, subject) {
polkit.log('Using default');
return ["unix-user:0"];
});

then they'll log when called.

polkit keeps calling admin rule functions until one returns a non-empty
result, so only the first one that returns a result (in lexicographic
order by filename) is practically useful.

smcv

[Sam Morris]

On 03/11/2022 13:39, Simon McVittie wrote:
> On Thu, 03 Nov 2022 at 11:51:52 +0000, Sam Morris wrote:
>> Here's my configuration:
>>
>> # cat /etc/polkit-1/localauthority.conf.d/60-sam.conf
>> [Configuration]
>> AdminIdentities=unix-user:sam.m...@domain.example.com
>
> Is that really your Unix/PAM login name, the one you'd get from `id -nu`
> or `su - $user` or similar? Or is your login name something like sam.morris
> or sam?

Yes - the user account lives in an Active Directory domain which is
projected into the POSIX world by FreeIPA. The user name is the SAM
Account Name of the user @ The AD domain's DNS FQDN.

> The usual setup with a modern polkit version is that the admin identities
> are handled by /usr/share/polkit-1/rules.d/40-debian-sudo.rules,
> which returns "unix-group:sudo", meaning "any member of the sudo group
> is a local sysadmin".

Having my username in the pklocalauthority like that is sort of a
workaround for a number of unfortunate things about how polkit
enumerates groups & because FreeIPA isn't able to put AD users into
netgroups.

You're right, adding my user to the (local) sudo group will probably do
the job.

> It's usually unnecessary to configure this, either in the old PKLA
> backend or in the newer JS backend, so the way this interoperates with
> the legacy PKLA configuration is unlikely to be particularly well-tested.
>
> I wonder whether the problem here might be that 40-debian-sudo.rules is
> sequenced earlier than 49-polkit-pkla-compat.rules, which means only the
> function defined in 40-debian-sudo.rules gets called, and the one in
> 49-polkit-pkla-compat.rules is ignored?

You're right. I actually just commented out the contents of
40-debian-sudo.rules entirely. polkit immediately reloads the rules and
my pkcheck command is once again prompting me for my own credentials.

> polkit keeps calling admin rule functions until one returns a non-empty
> result, so only the first one that returns a result (in lexicographic
> order by filename) is practically useful.

Argh, that's a really annoying. I wonder why they don't call all the
admin rules and collect all of the results...

Anyway, that's all I need to get our systems working sensibly again.

But I suppose this should become a bug against polkitd-pkla since in
practice its 49-polkit-pkla-compat.rules will never be called since
40-debian-sudo.rules is called first.

Perhaps one solution would be to renumber to << 40, and ship a
pklocalauthority config file with 'unix-group:sudo'. This will ensure
that systems where polkitd-pkla is installed will match the default
behaviour of systems where it isn't installed.

> smcv

Thanks for your help! :)

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

[Sam Morris]

On 03/11/2022 15:17, Sam Morris wrote:
> But I suppose this should become a bug against polkitd-pkla since in
> practice its 49-polkit-pkla-compat.rules will never be called since
> 40-debian-sudo.rules is called first.
>
> Perhaps one solution would be to renumber to << 40, and ship a
> pklocalauthority config file with 'unix-group:sudo'. This will ensure
> that systems where polkitd-pkla is installed will match the default
> behaviour of systems where it isn't installed.

FYI, Fedora ship their default admin rules with these numbers:

# ls /etc/polkit-1/rules.d/
49-polkit-pkla-compat.rules 50-default.rules

50-default.rules is equivalent to Debian's 40-debian-sudo.rules file
(although Fedora use the wheel group rather than sudo).