1734791 - Kerberos/SPNEGO authentication not working in snap package

Status: UNCONFIRMED

(Firefox Build System :: Third Party Packaging, defect, P2)

Description

[Marian Rainer-Harbach]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.99 Safari/537.36

Steps to reproduce:

This issue concerns the Firefox snap package. I have configured Firefox to use SPNEGO authentication against my authentication server using the policy Authentication/SPNEGO (as documented at https://github.com/mozilla/policy-templates/blob/master/README.md#authentication). Firefox shows the policy in about:policies and the corresponding setting network.negotiate-auth.trusted-uris in about:config, so the policy is found and applied correctly.

Actual results:

Even though the policy is active, Firefox does not attempt Kerberos authentication against my authentication server. The exact same policy DOES work with the regular deb-based version of Firefox, so the issue has to be in the snap package.

I guess that the snap version does not have access to the required files and/or environment variables. I logged which files and directories the deb-based Firefox accesses that seem to have to do with Kerberos/SPNEGO using strace -f -t -e trace=file firefox on my system running Ubuntu 21.10 beta:

/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/lib/x86_64-linux-gnu/libkrb5.so.3
/lib/x86_64-linux-gnu/libk5crypto.so.3
/lib/x86_64-linux-gnu/libkrb5support.so.0
/etc/gss/mech
/etc/gss/mech.d
/etc/krb5.conf
/etc/krb5/user/10017/client.keytab
/usr/share/locale/*/LC_MESSAGES/mit-krb5.mo
/usr/share/locale-langpack/*/LC_MESSAGES/mit-krb5.mo
/tmp/krb5cc_10017_QfHqc3

10017 is the user ID of the user running firefox. The last file /tmp/krb5cc_10017_QfHqc3 is the user's Kerberos ticket cache, which is given by the environment variable KRB5CCNAME.

So the first step would be to allow the snap to access the listed files and directories, as well as to the environment variable KRB5CCNAME. Of course, the list is just generated by looking at the deb-based Firefox on my system and might not be complete.

In any case, I'd be happy to test an updated snap.

Expected results:

Kerberos/SPNEGO authentication should work the same as in the deb-based Firefox.

Comment 1

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 2

[Olivier Tilloy]

Triagers, please update the component to "Release Automation: Snap" and add a blocks reference to bug 1665641. Thanks!

Comment 3

[Daniel Calcoen]

There are several references across the internet about similar problems.

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346

Firefox with Kerberos/SPENGO works fine in the non snap version and Firefox snap version don't.
Seems some door is closed in the snap.

Comment 4

[Daniel Calcoen]

In my brand new Ubuntu 21.10 Impish has forced the change of Firefox as Snap, so I'm suffering Kerberos not working from inside the Firefox snap.
Kerberos works fine at Linux level.KInit, KList, etc... shows that the tickets are assigned and handle correctly when requested.

Which is different in our case that for normal people is that the use of Kerberos requires to set in firefox the preference "network.negotiate-auth.trusted-uris" which by default is not set.
In my case it is set as network.negotiate-auth.trusted-uris=cern.ch

I have everything setup correctly, linux and firefox snap, and the problem present so if somebody could guide me a bit I can output any log file/debug you wish to spot where the magic disappears.

Comment 5

[georges]

Being on Ubuntu 22.04, the .deb package has been removed and one is forced to use the snap version.

kerberos does not work with the latest version and this is quite a blocker for me as there is no alternative (other than switching browsers).

Comment 6

[Mantas Mikulėnas (grawity)]

The magic disappears in Firefox's AppArmor profile, which doesn't allow it to access /tmp/krb5cc_*. As an easy workaround until the Snap configuration is fixed, edit /etc/krb5.conf to relocate your Kerberos ticket cache somewhere Firefox can access it:

[libdefaults]
	default_ccache_name = FILE:/home/%{username}/krb5cc

(Don't forget to re-kinit.)

---

In addition to the AppArmor problems, the snap is also missing the krb5/plugins/tls/k5tls.so module that's required to access KDCs via MS-KKDCP (aka KdcProxy). Now most realms should work fine without the k5tls plugin, but in some cases it might be necessary to manually specify non-proxied KDC hostnames in krb5.conf [realms]. (If you're using Azure AD Kerberos, you're out of luck.)

The magic environment variables to reveal such problems are KRB5_TRACE=/dev/stderr NSPR_LOG_MODULES=negotiateauth:5.

Comment 7

[Mantas Mikulėnas (grawity)]

(In reply to Mantas M. (grawity) from comment #6)

The magic disappears in Firefox's AppArmor profile, which doesn't allow it to access /tmp/krb5cc_*. As an easy workaround until the Snap configuration is fixed, edit /etc/krb5.conf to relocate your Kerberos ticket cache somewhere Firefox can access it:

[libdefaults]
	default_ccache_name = FILE:/home/%{username}/krb5cc

I just realized this won't work if you're also using Kerberos for NFS or AFS. :(

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Stefan Berggren]

My workplace was hit with this earlier this week (Upgrading from Ubuntu 20.04 -> 22.04.1). Just like to point out that KRB5CCNAME can refer to several different cache storage alternatives, for example I use KEYRING:persistent:uidnumber so an updated apparmor profile granting it access to /tmp/krb5cc_* would not solve it for me.

Comment 10

[:gerard-majax]

Olivier, is there any progress on that matter?

Comment 11

[Olivier Tilloy]

No, this isn't being worked on.

Comment 12

[vegardalsli]

I can confirm this is still a huge issue i have hundreds of users with this problem in my environment.
This is both a big security and productivity issue for my users.

How can we get this fixed?

Comment 13

[Paul Ferrell]

I'll second that. We've got a lot of users with this issue in our environment as well.

Comment 14

[Daniel Calcoen]

I'll second that too.

Comment 15

[:gerard-majax]

(In reply to vegardalsli from comment #12)

I can confirm this is still a huge issue i have hundreds of users with this problem in my environment.
This is both a big security and productivity issue for my users.

How can we get this fixed?

Unfortunately, this is an upstream issue, and I have no time to help there.

Comment 16

[vegardalsli]

Im not sure what this beeing an upstream issue means. Is there a bug or a point of contact upstream that we can get in contact with?
Thank you for increasing the priority of this case btw.

Comment 17

[:gerard-majax]

(In reply to vegardalsli from comment #16)

Im not sure what this beeing an upstream issue means. Is there a bug or a point of contact upstream that we can get in contact with?
Thank you for increasing the priority of this case btw.

It means that the issue is not in our codebase but it's a ubuntu-level issue. Please look at See also for https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346

Comment 18

[:gerard-majax]

Amin, is this on any roadmap?

Comment 19

[Amin Bandali [:bandali]]

I think we're hoping to tackle this for the next (Ubuntu) cycle.