[snap] kerberos GSSAPI no longer works after deb->snap transition

Bug #1849346 reported by st0ve
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
New
Unknown
chromium-browser (Ubuntu)
Undecided
Unassigned
firefox (Ubuntu)
Undecided
Unassigned

Bug Description

I configure AuthServerWhitelist as documented:

https://www.chromium.org/developers/design-documents/http-authentication

and can see my whitelisted domains in chrome://policy/

but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...).

I can confirm that Chrome has the desired behavior.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
st0ve (st0ve)
description: updated
st0ve (st0ve)
summary: - kerberos GSSAPI no longer works after deb->snap transition
+ [snap] kerberos GSSAPI no longer works after deb->snap transition
Revision history for this message
Olivier Tilloy (osomon) wrote :

Thanks for the report.
Can you check for apparmor denials in the system journal when reproducing the problem? Run the following command in a terminal before launching chromium:

    journalctl -f | grep DEN

tags: added: snap
Revision history for this message
st0ve (st0ve) wrote :

The /etc/gss/mech.d/ and /etc/krb5.conf.d/ denials may be relevant. Both directories are empty in my case, but lack of access may be killing some logic that relies on checking them.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Thanks, that's useful.

I'm not familiar with SPNEGO/GSSAPI/kerberos, could you maybe come up with easy steps to reproduce the problem on a clean system? That would allow me to dig further into the problem.

Revision history for this message
Vitezslav Kotrla (vitezslav-kotrla) wrote :

The same problem here, after upgrading to 'snapped' chromium 79 we lost Single Sign-On, all our Kerberos security based intranet web servers started asking for username and password.

Kerberos ticket cache is file /tmp/krb5cc_<uid>:
<pre>
johndoe@computer:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: <email address hidden>

Valid starting Expires Service principal
3.2.2020 12:39:10 3.2.2020 22:39:10 <email address hidden>
 renew until 4.2.2020 12:39:10
3.2.2020 12:42:39 3.2.2020 22:39:10 <email address hidden>
</pre>
<pre>
johndoe@computer:~$ ls -la /tmp/krb5cc_1000
-rw------- 1 johndoe johndoe 3125 úno 3 12:42 /tmp/krb5cc_1000
</pre>

Revision history for this message
Stefan Priebe (s-priebe) wrote :

Sorry this sucks guys - when is it going to get fixed? Ubuntu 20.04 also stopped working for me since the transition to snap happend - all kerberos and gssapi authentications no longer work

Revision history for this message
Alexey Tsitsin (cicin) wrote :

This problem still persist and SPNEGO won't work even with new policies:

https://cloud.google.com/docs/chrome-enterprise/policies/?policy=AuthServerAllowlist
https://cloud.google.com/docs/chrome-enterprise/policies/?policy=AuthNegotiateDelegateAllowlist

The policies are loaded successfully but kerboros negotiation won't work

information type: Public → Public Security
Revision history for this message
Sebastien Bacher (seb128) wrote :

Why do you think it's a security issue?

Revision history for this message
Alexey Tsitsin (cicin) wrote :

Sorry, I changed the issue's type accidently.

information type: Public Security → Public
Revision history for this message
Olivier Tilloy (osomon) wrote :

The snap should have the required libraries to support kerberos authentication, but it's likely that confinement is getting in the way. Does kerberos allow verbose logging on the server end, to inspect where authentication is failing?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunderbird (Ubuntu):
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

Unsure why thunderbird is listed there, it's not mentioned in the description nor posts, could you give some details on what isn't working and how?

Changed in thunderbird (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
In , Marian+mozilla (marian+mozilla) wrote :

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.

Revision history for this message
Martin Petersen (martux69) wrote :

Same problem here, chromium is not able to use kerberos ticket. I think, it is time to get back chromium as a deb package until snap is really working.

Revision history for this message
Marian Rainer-Harbach (marianrh) wrote :

Maybe the information I collected here https://bugzilla.mozilla.org/show_bug.cgi?id=1734791 for the Firefox snap, which suffers from the same problem, is helpful in order to fix the problem for the Chromium snap as well.

Revision history for this message
In , Andrei-purice (andrei-purice) wrote :

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.

Revision history for this message
Daniel Calcoen (daniel-calcoen) wrote :

Today 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.
Some closed door seems to isolate the snap from the real world...

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

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

Revision history for this message
Daniel Calcoen (daniel-calcoen) wrote :

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.

Revision history for this message
In , Daniel Calcoen (daniel-calcoen) wrote :

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.

Revision history for this message
Daniel Calcoen (daniel-calcoen) wrote :

There is a similar bug follow up at https://bugzilla.mozilla.org/show_bug.cgi?id=1734791

Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
status: New → Confirmed
no longer affects: thunderbird (Ubuntu)
Changed in firefox:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.