pam: Set PAM_AUTHTOK on successful authentication

[adombeck]

By setting PAM_AUTHTOK the GNOME keyring is unlocked.

UDENG-8799

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.64%. Comparing base (01cd78c) to head (22bc3d5).
⚠️ Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1190      +/-   ##
==========================================
+ Coverage   87.53%   87.64%   +0.11%     
==========================================
  Files          91       91              
  Lines        6231     6231              
  Branches      111      111              
==========================================
+ Hits         5454     5461       +7     
+ Misses        717      714       -3     
+ Partials       60       56       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[3v1n0]

This would be fine per the current broker, but we have the problem that we don't handle the change password phase well (as per #944 (comment)).

And so, without it we may just end up having the token just set once and then be broken by a password change.

Then, the problem, daemon side, is that we do not have the information to know whether the broker supports secrets or not to be sure if we should set this all the times.

So the token that we are setting may be:

• Unset (if we login without local password, in potential brokers without it)
• Change depending on the authentication method that has been chosen (imagine a broker supporting a PIN or a Password)

Thus again, this is something that IMHO we should not do without the broker providing us the AuthTok to set.

My idea to have something more generic was:

• The broker defines an unique token that is invisible to the user
• The token is sent to PAM on auth and we use it as the keyring password.

PRO: Independent from authentication mode being used
CONS: If the user logout from a keyring inside the session, currently we have no way to unlock it (we could do it through PAM, but it needs some UI work)

For the current situation, we could workaround the problem by keeping a similar structure, but sending back the very same secret that has been used by the user to authenticate.

In this way we still leave the control to the broker, but also we should be able to use the information only if it's possible.

However, in general I'd personally prefer to handle it all together (I mean, also once the passwd case is fixed), rather than having half-baked solutions, since this is the reason why we did not do this in the beginning.

[adombeck]

This would be fine per the current broker, but we have the problem that we don't handle the change password phase well (as per #944 (comment)).

I read that comment before opening the PR but I don't understand the issue. We only support changing the password after a successful device authentication, in which case the same code path is taken and we set PAM_AUTHTOK. I tested that after changing the password by doing device authentication again the keyring is still successfully unlocked.

[3v1n0]

We only support changing the password after a successful device authentication, in which case the same code path is taken and we set PAM_AUTHTOK. I tested that after changing the password by doing device authentication again the keyring is still successfully unlocked.

I need to check again the keyring pam code, but that was expected I think when using passwd.

[adombeck]

I need to check again the keyring pam code, but that was expected I think when using passwd.

I also tried passwd already, also works fine.

[3v1n0]

Also if the one authenticating to use passwd is not the same user we change the password for?

[adombeck]

Also if the one authenticating to use passwd is not the same user we change the password for?

I'll try that.

[adombeck]

Also if the one authenticating to use passwd is not the same user we change the password for?

It's always asking for the password of the user actually: #851

[adombeck]

Also if the one authenticating to use passwd is not the same user we change the password for?

Yes, the keyring is also unlocked when I change the password via sudo passwd in another user's session (which still requires the user's local password) and afterwards log in via GDM with the new password.

[adombeck]

With #1234 we will have the case that there is no local password. I think authd could instead generate a secret the first time the user authenticates and set PAM_AUTHTOK to that when the user authenticates successfully. We could use systemd credentials to encrypt the secret with the TPM.

That is similar to your suggestion @3v1n0, but I think it makes more sense to let authd generate that secret than the broker, because there's nothing broker-specific about that secret. WDYT?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.56%. Comparing base (c86d7e2) to head (2dac51d).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1190      +/-   ##
==========================================
+ Coverage   80.57%   87.56%   +6.99%     
==========================================
  Files          20       91      +71     
  Lines         978     6232    +5254     
  Branches        0      111     +111     
==========================================
+ Hits          788     5457    +4669     
- Misses        190      719     +529     
- Partials        0       56      +56     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[adombeck]

@3v1n0 discussed this today.

A reason to let the broker decide which secret to use is that it allows using the local password if there is one, which allows the user to unlock the keyring themself with that password in case that the keyring is locked during a session. That won't be possible without UI changes if we use an authd-generated secret instead. However, locking and unlocking the screen could be a workaround to also unlock the keyring in that case.

An issue if we do use the local password as the keyring secret is that it won't be updated if the disable_local_password setting is activated after a user already set a local password. That case would be fixed if we would always use an authd-generated secret instead.

[adombeck]

braindumping an idea:

1. local password enabled -> broker returns that with the auth result and PAM module sets PAM_AUTHTOK to it
2. local password is disabled -> broker sees that local password was disabled but that there is one already stored in the data dir (the hashed password file), so it knows that we need the local password to change the keyring password
   2.1. broker only offers local password but sets next auth mode to device auth
   2.2 auth result contains local password, authd generates a random secret and stores it in its data directory as a systemd credential
   2.3 PAM module changes the keyring password from the local password to the generated secret
   2.4 user continues with device authentication
   2.5 broker deletes hashed password file