-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce risk of oauth token compromise by storing tokens in $XDG_RUNTIME_DIR #1595
Comments
Hello @nickweeds2, thanks for opening this issue with all these details.
Git Credential Manager's own storage system on Linux comes un-configured out of the box, and you must select a storage option using However, you are correct when referring to the MSAL (Microsoft Authentication Library) token cache, which on Linux only uses either the Secret Service store or a plaintext fallback. I can see that you've created some issues in the MSAL repos about this, and got a reply in the MSAL Python repo that it's the application's choice where to store the cache. It is correct that the applications set the location for this fallback cache file, however GCM's locations are being kept in step with other Microsoft developer tools (such as Azure PowerShell) that use MSAL and the token cache. We implemented this on the advice of the MSAL team at the time. @rayluo + @bgavrilMS would be able to update on what the latest advice for the token cache on Linux? |
Hi @mjcheetham - @rayluo and myself focus only on confidential client scenarios nowadays. For public client scenarios, including token caching for CLI / desktop apps on Linux, @iulico-1 @ashok672 can help. |
Hi Bogdan! Thanks for the reply and redirect to the correct people. I was aware you had moved to other focuses but didn't know who else to reach out to on GitHub. |
@mjcheetham |
Further observation:
|
Feature description
On Desktop Linux Git Credential Manager stores Azure DevOps oauth tokens encrypted in Gnome Keyring, but on headless Linux it stores them unencrypted and outputs a warning.
It is understandable that GCM stores oauth tokens unencrypted on headless Linux because headless Linux does not provide a standardized credential store. However, headless Linux is used much than desktop Linux, and storing oauth tokens unencrypted on disk remains a security concern.
What can be done ?
One simple improvement would be to store oauth tokens under directory $XDG_RUNTIME_DIR when this exists.
Many Linux distributions use systemd and create a user session when the user logs in or starts an SSH session. When the user session is first started the system creates a tmpfs runtime filesystem and sets $XDG_RUNTIME_DIR to point to it. When the user's last session ends the system deletes the user's runtime filesystem. This is observed on both Ubuntu and Mariner (with systemd).
Storing oauth tokens under $XDG_RUNTIME_DIR would have two immediate benefits:
These two benefits protect the oauth tokens almost as well as Gnome Keyring. Gnome Keyring does not protect against people who have access to the user session (see Gnome Keyring Security Philosophy), so the main difference is probably not encryption but Gnome Keyring having better protection against memory being swapped to disk. (I don't think Windows DPAPI protects encrypted data from people who have access to the user session either, so Windows might not be much better.)
Side effects of the proposed change:
Since GCM is intended for interactive use these side effects are probably acceptable, but if not we could allow users to override this behavior and store oauth tokens under $HOME rather than $XDG_RUNTIME_DIR (at the cost of persistent oauth tokens on disk).
Proposed Solution
When storing unencrypted oauth tokens on Linux, check whether $XDG_RUNTIME_DIR is set and refers to a valid directory, and if so store oauth tokens under $XDG_RUNTIME_DIR rather than $HOME.
The text was updated successfully, but these errors were encountered: