desktop
desktop copied to clipboard
mattermost
PIV / CAC / smart card authentication not working on GNU/Linux
I confirm (by marking "x" in the [ ] below: [x]):
- [x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
- [x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
- [x] I have read contributing guidelines.
Summary I am not prompted for PIV / CAC / smart card unlock PIN or certificate selection when using the latest Mattermost desktop app on Linux.
Environment
- Operating System: Debian GNU/Linux
- Mattermost Desktop App version: 4.5.3
- Mattermost Server version: 5.25.1
Steps to reproduce
-
rm -rf $HOME/.config/Mattermostclear Mattermost droppings, as neither "Log Out" nor "Remove"ing a server clears prior logins` -
.../mattermost-desktoprun Mattermost - add Mattermost server and close settings window
- insert PIV / CAC / smart card
- proceed with server authentication; "click login button, await PIN / unlock prompt, choose certificate, proceed"
Expected behavior After clocking login button on server authentication page, the PIV / CAC / smart card should be used for authentication; prompting for PIN unlock if not already, then certificate selection if not already chosen, then confirmation/successful authentication. These pages are site specific of course, but this is the general procedure.
Observed behavior I am never prompted for PIV / CAC / smart card unlocking or certificate selection. I am able to authenticate with username / password + MFA as the server allows. It's as though PIV / CAC / smart card features are silently not working or simply unimplemented on GNU/Linux.
Possible fixes I have not inspected the source for a possible fix, but other sources (co-workers) and pull requests indicate this functionality exists and works on other platforms. https://github.com/mattermost/desktop/pull/1148#issuecomment-575390778
After adding OpenSC PKCS #11 modules to the libnss database/system for my user, I am able to use PIV / CAC / smart card authentication with Mattermost web clients in Chromium. As well, adding OpenSC PKCS #11 module for Firefox works excellently.
Are you able to use PIV card with the browser? If it works, can you test with the previous version?
Are you able to use PIV card with the browser?
I am able to use PIV card with the web client, in both Chromium and Firefox, yes; see my last statement in my original post:
After adding OpenSC PKCS #11 modules to the libnss database/system for my user, I am able to use PIV / CAC / smart card authentication with Mattermost web clients in Chromium. As well, adding OpenSC PKCS #11 module for Firefox works excellently.
If it works, can you test with the previous version?
I tested with v4.5.3, v4.5.2, v4.5.1, v4.5.0, and v4.4.2; PIV card does not appear to work with any of these versions on my system.
Is it possible to run Mattermost with more diagnostic output? It seems as though the login process takes 1 second or so longer before presenting me the login form when my PIV card is inserted with versions 4.5.x vs when it is not. In the browser, this is the stage at which the login form would be bypassed and the PIV card would be auto-detected and used for authentication instead.
If it matters: I am running Wayland, via Sway window manager, with XWayland enabled. Possibly Mattermost is having trouble displaying the PIV card dialogs in this scenario? This is a complete guess, though.
the dialogs are displayed by either the OS or chromium. Once we detect we have at least one valid cert for the login we try to use it and send it to electron, which then asks for the pin.
I don't think I have setup the piv card in ubuntu, but will try and see if it works or it gives me any info
I just started using Mattermost, had the same problem. So I hit the web, found this conversation from last year. I'm disappointed there has been no activity since.
Anyway, I did a tiny bit of debugging. I'll share it, in case anyone is looking and cares.
It occurred to me to wonder if Mattermost was even loading the PKCS library. So I thought I'd check:
- get the PID of every mattermost process
- for each, cat it's map file, which tells what files are mmap(2)ed (which include shared libraries, among other things).
- Look for the pkcs library
I did all of the above immediately after starting mattermost, and again after clicking the sign-in button.
I found that the pkcs library was indeed loaded at the start, and was loaded even more after clicking the sign in button. (Perhaps merely because the process that already had it loaded forked -- I didn't really look.)
$ # Start mattermost-desktop from another window. Then:
$ cat $(ps -ef | grep -i '[m]attermost' | awk '{print $2}' | sed 's/\(.*\)/\/proc\/\1\/maps/') | grep -i pkcs
7f800e426000-7f800e452000 r-xp 00000000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e452000-7f800e651000 ---p 0002c000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e651000-7f800e652000 r--p 0002b000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e652000-7f800e657000 rw-p 0002c000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
$ # Click the signing button, then:
$ cat $(ps -ef | grep -i '[m]attermost' | awk '{print $2}' | sed 's/\(.*\)/\/proc\/\1\/maps/') | grep -i pkcs
7fb02e722000-7fb02e74e000 r-xp 00000000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7fb02e74e000-7fb02e94d000 ---p 0002c000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7fb02e94d000-7fb02e94e000 r--p 0002b000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7fb02e94e000-7fb02e953000 rw-p 0002c000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e426000-7f800e452000 r-xp 00000000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e452000-7f800e651000 ---p 0002c000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e651000-7f800e652000 r--p 0002b000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
7f800e652000-7f800e657000 rw-p 0002c000 08:01 13642755 /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
$
So it seems to be trying to use the smart card, at least. Don't know why it's failing, though.
One other note. Sometimes when I have trouble with my smart card, I do a pcsc_scan(1), and that fixes things. I tried that. Quit mattermost. Checked ps(1) output to make sure they were really all gone. Did the pcsc_scan. Started mattermost. Clicked the sign in button. Still no smart card use.
And yes, like nmschulte, the smart card works fine when I sign into the same mattermost site via Chrome or Firefox.
thanks for the detailed info. I've created a ticket, testing PIV carsd is always a bit complicated, sorry about it.
I've created a ticket
We don't have a test setup for this and PIV card support for Windows was the primary feature. Ubuntu support was never a priority.
What's required for a test setup? It's great to know that Mattermost prioritizes Windows over Linux. Are we to interpret this immediate "Won't Fix" resolution as par for the course going forward re: GNU/Linux, @Willyfrog, @jwilander?
The GNU/Linux world is much larger than Ubuntu. @philipdumont which distribution are you using?
I, too, am using Ubuntu. Specifically, 18.04.5 LTS (Bionic Beaver). Have also tried on Ubuntu 16.04.7 LTS (Xenial Xerus), with similar results.
In both cases, the PKCS library I'm using is opensc-pkcs11.so, from the opensc-pkcs11 package.
And -- I don't think it matters, but full disclosure: for the Ubuntu 18.04.5 distro, it's actually running on Windows Subsystem for Linux, and getting at the card reader via USBIP. But since everything else in WSL (web browsers, command-line ssh) can use the card reader just fine, it would appear that USBIP is doing its job well.
The 16.04.7 system I'm using is on bare metal.
I rather agree this is not high priority. I'd like the extra features of the MatterMost gui, if they were easy to get to. But the web interface is serving me well enough for now. Don't knock yourself out on this for my sake.
phil
p.s. You might be tempted to say: "Well, since you are running WSL, you must be running that on Windows. So... why not install the Windows version of the MatterMost GUI on your Windows system and use that?" I would. But while the card reader is being made available to WSL vis USBIP, it is no longer usable by Windows. And I pretty much live in WSL. (I'm a *nix weenie from way back, and refuse to convert completely to MS without a fight.)
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Mon, Aug 2, 2021 at 5:50 PM Nathan Schulte @.***> wrote:
I've created a ticket https://mattermost.atlassian.net/browse/MM-37410
We don't have a test setup for this and PIV card support for Windows was the primary feature. Ubuntu support was never a priority.
What's required for a test setup?
The GNU/Linux world is much larger than Ubuntu. @philipdumont https://github.com/philipdumont which distribution are you using?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mattermost/desktop/issues/1371#issuecomment-891357651, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4R7MQETDWM3ZCBZXDOKGLT24HLTANCNFSM4RCYKEQA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
it's actually running on Windows Subsystem for Linux
That sounds like an excellent test setup; but of course I don't know the present hurdle(s).
For the record, I am no longer using MM. I'll be avoiding it going forward given the attitude presented here, though I do appreciate the hard work of those involved.
Is this still considered as a "Won't fix" issue from the Mattermost team?
I would be happy to help in some way if it could be of assistance.
Is this still considered as a "Won't fix" issue from the Mattermost team?
I would be happy to help in some way if it could be of assistance.
@thorseye Thanks for your offer! We don't have a way of testing fixes ourselves, so if you could assist us in that way that would be excellent :)
@thorseye Thanks for your offer! We don't have a way of testing fixes ourselves, so if you could assist us in that way that would be excellent :)
Sure @devinbinnie! Do you want me to join a Mattermost channel somewhere to discuss further? I'm using Red Hat Enterprise Linux 8.4, with smart card login enabled (which works in browser and on Windows desktop app).
@thorseye Thanks for your offer! We don't have a way of testing fixes ourselves, so if you could assist us in that way that would be excellent :)
Sure @devinbinnie! Do you want me to join a Mattermost channel somewhere to discuss further? I'm using Red Hat Enterprise Linux 8.4, with smart card login enabled (which works in browser and on Windows desktop app).
That would be great :). You can join the Developers: Desktop App channel on Contributors or shoot me a DM @devin.binnie.
Any update on this issue? wondering if theres any progress before i attempt to fix it myself
Now that you mention it...
I have seen MM notification popups on my Linux desktop now and then.
...but...
They are rather short-lived. If I happen to be sitting at my desk and looking at my screen during the small number of seconds it's visible, great, mission accomplished. If my attention is elsewhere, it doesn't really matter that the notification went by.
As an example...
We use GSuite extensively, especially for email and calendar.
GMail's new-message notifications are like MM's -- short-lived. But for that, it's okay, because 1) emails are so frequent that if their notifications stayed on the desktop until dismissed, the desktop would frequently be overwhelmed; and 2) I pretty much "live" in my email tab most of the time, so even if I miss a notification, it won't be long before I see the email anyway.
Google Calendar's meeting reminder notification popups stay on the desktop until you dismiss them. And, for that app, that is the preference. Because meetings don't happen often enough to overwhelm the desktop (most days). And because meetings are more time sensitive then (most) emails, so it's good to minimize the chance that you miss the notification.
Since folks tend to consider MM messages more time sensitive than email, it might be preferable if MM notifications remained on the desktop until dismissed.
FWIW, I did have a quick look at both MM notification settings and Chrome notification settings to see if that was a preference I could set myself. Didn't see anything.
phil
p.s., one could argue that since, by my own assertions, people tend to prefer MM over email for time sensitive messages, then maybe I should change my habits so that I "live" more in my MM tab than my GMail tab. That's a fair point. And I'm working on that. Nevertheless, I still think it would be appropriate if the MM notification were (or could be made to be) persistent-until-dismissed.
p.p.s., I have only seen MM notifications on my desktop very rarely. Noticed it the first time maybe 3 or 4 weeks ago, but have only seen 2 or 3 ever. Despite being messaged, directly, a few times a day. I suppose it's possible that every such message to me has generated a desktop notification, the majority of which I have just missed. But I strongly suspect that notifications just don't always happen. I wish I had something more definitive to give you...
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Mon, Mar 14, 2022 at 2:06 AM RealAstolfo @.***> wrote:
Any update on this issue? wondering if theres any progress before i attempt to fix it myself
— Reply to this email directly, view it on GitHub https://github.com/mattermost/desktop/issues/1371#issuecomment-1066413518, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4R7MU2HKJPZ324CEQ7MRTU73QQDANCNFSM4RCYKEQA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Any update on this issue? wondering if theres any progress before i attempt to fix it myself
Me and @devinbinnie tried to debug this in november, but could not get past the fact that the event for selecting client certificate does not seem to fire for me. If you do have time to try to fix this @RealAstolfo , that would be really appreciated since this is still an issue.
ill see what i can find this weekend. been quite a bit busy as you could imagine
Thanks for the ping. You prompted me to go get the latest version (5.1.1) to see if it was working any better. Alas, no.
My understanding is that, if I click on the "MFA Log In" button when a CAC is accessible, it should just do a CAC login, right? It's not happening. It just says "Invalid username or password". (Which is true, since I left them blank.)
It might be worth pointing out that when MM is starting, the card reader's light blinks a lot. And then it blinks some more when I click the "GitLab" button on the initial page. So it certainly seems to be trying to use the CAC. But, when I click on the "MFA Log In" button, it doesn't blink at all, and the "Invalid username or password." message is essentially immediate.
Hmm. It just now occurs to me to wonder if my problem is that MM can't get at a copy of the CA cert(s) that signed my CAC certificate. I'm able to use my CAC from the Chrome browser running on my Linux system, but that's because I installed the CAs into Chromes cert store. I haven't a clue where MM would look for CAs.
phil
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Wed, Aug 31, 2022 at 10:32 AM Clayton Kehoe @.***> wrote:
Any updates on this issue?
— Reply to this email directly, view it on GitHub https://github.com/mattermost/desktop/issues/1371#issuecomment-1233019543, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4R7MSD5L5JMRMN5EPKBM3V35UJDANCNFSM4RCYKEQA . You are receiving this because you were mentioned.Message ID: @.***>
Hey folks, its mid 2023, any way to make progress here on the linux desktop client?
In our installation (v5.0.4) we're using Okta as a SAML provider with a PIV backend. Badge logins work great with Mattermost via browser.
When I fire up the desktop client, however...
- I see the card reader blinking when I initially launch the client.
- I see the card reader blinking again when I select the "log in with gitlab" option
- I see the card reader blinking again when I select Okta on the "Connecting to Gitlab" UI
- I see the card reader blink briefly when I select the PIV logon option
- I get a "No certificate selected" error and the Certificate selection UI never pops.
Whats the help needed to move forward at this point?
My current best guess is that maybe the desktop client isn't working because it doesn't have access to the CAs that signed my CAC cert. But... I don't know how to fix that.
In Windows, there are central certificate stores -- computer and user -- and you stick your CAs in there, and everything that needs them can get to them. And InstallRoot will stick the DoD CAs in there for you, and you are good to go.
But on Linux... Well, for any given browser, all I know to do is get into that browser's "Settings", find my way to where the certs are managed, import the CA(s) I need. In the case of CAC CAs, that means finding out which root/intermediate CA signed each of my CAC's certs, getting in the Windows Cert Manager of a machine where I ran DoD Safe, exporting the half-dozen CAs needed for my current CAC, importing them into my Linux browser. And, AFAIK, every Linux browser I've used stores those CAs somewhere in the current browser profile -- of which there may be many -- so you may need to repeat the exercise for every profile in which you want to use your CAC.
So that get's my Linux browsers able to use my CAC.
But I strongly suspect that the MM Desktop Client is not going to be reaching into any of my browser profiles for CAs. And I don't really know how to tell the MM Desktop Client where to get the needed CAs. I've looked around the GUI, but not found it yet. Is it something I do from the GUI? Or is there some "central" place that MMDesktop is already looking for CAs, and I'm supposed to stick the CAs there, and MMDesktop just finds them there? Maybe somewhere in /etc/ssl/certs? If so, where exactly, and does the filename matter, and what format (PEM?)?
Thanks.
phil
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Wed, Jun 7, 2023 at 11:30 AM cbellers @.***> wrote:
Hey folks, its mid 2023, any way to make progress here on the linux desktop client?
In our installation (v5.0.4) we're using Okta as a SAML provider with a PIV backend. Badge logins work great with Mattermost via browser.
When I fire up the desktop client, however...
- I see the card reader blinking when I initially launch the client.
- I see the card reader blinking again when I select the "log in with gitlab" option
- I see the card reader blinking again when I select Okta on the "Connecting to Gitlab" UI
- I see the card reader blink briefly when I select the PIV logon option
- I get a "No certificate selected" error and the Certificate selection UI never pops.
Whats the help needed to move forward at this point?
— Reply to this email directly, view it on GitHub https://github.com/mattermost/desktop/issues/1371#issuecomment-1581065570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4R7MQYEM462EKRTM374QDXKCNBHANCNFSM4RCYKEQA . You are receiving this because you were mentioned.Message ID: @.***>
@philipdumont for our installations, we always stage our internal CAs in /etc/pki/ca-trust/source/anchors and that seems to work well enough for most everything else.
I'm not sure what's going awry here but it sure is frustrating.
Hmm. You sure that's where my version of mattermost-desktop would look for CAs? Because I tried this trick:
strace -f -o /tmp/mattermost-desktop-strace.txt mattermost-desktop
And from the being-straced MatterMost GUI, I attempted to connect to the server. And when, after my card reader flashed a lot but it didn't work, I exited the GUI.
And then I grepped the strace output file for "/etc/pki". No hits.
I also looked at what else in /etc it tried to access. Just stuff like fonts, hosts, selinux (which is currently not enforcing, so it's not that getting in the way), yada yada. Nothing that looks like "pki" or "cert" or "ssl"...
But then I grepped for just "pki". And that got a lot of hits. And every one was for '/home/phil/.pki/', which does not exist, so of course all the system calls that tried to access it failed.
So is that where I should put my CAs? And if so, again, how to lay them out (paths, formats)?
Thanks.
phil
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Wed, Jun 7, 2023 at 3:03 PM cbellers @.***> wrote:
@philipdumont https://github.com/philipdumont for our installations, we always stage our internal CAs in /etc/pki/ca-trust/source/anchors and that seems to work well enough for most everything else.
I'm not sure what's going awry here but it sure is frustrating.
— Reply to this email directly, view it on GitHub https://github.com/mattermost/desktop/issues/1371#issuecomment-1581358611, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4R7MVNHNESARDRHGVWKU3XKDF75ANCNFSM4RCYKEQA . You are receiving this because you were mentioned.Message ID: @.***>
My bad. ~/.pki does exist:
phil-pc> find ~/.pki /home/phil/.pki /home/phil/.pki/nssdb /home/phil/.pki/nssdb/cert9.db /home/phil/.pki/nssdb/key4.db /home/phil/.pki/nssdb/pkcs11.txt
And it looks like there were attempts to access cert9.db and pkcs11.txt were successful. There were no attempts to access key4.db. There were also attempts at key4.db.
There were also attempts to access cert9.db-journal, cert9.db-wal, key4.db-journal, and key4.db-wal, all of which failed with ENOENT. That's most of what I was seeing when I erroneously thought ~/.pki didn't exist.
So I guess I need to refresh my memory on how to use the cert tools that muck with .db files. I know I've used them, once upon a long time ago...
phil
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Wed, Jun 7, 2023 at 3:25 PM Phil Dumont @.***> wrote:
Hmm. You sure that's where my version of mattermost-desktop would look for CAs? Because I tried this trick:
strace -f -o /tmp/mattermost-desktop-strace.txt mattermost-desktop
And from the being-straced MatterMost GUI, I attempted to connect to the server. And when, after my card reader flashed a lot but it didn't work, I exited the GUI.
And then I grepped the strace output file for "/etc/pki". No hits.
I also looked at what else in /etc it tried to access. Just stuff like fonts, hosts, selinux (which is currently not enforcing, so it's not that getting in the way), yada yada. Nothing that looks like "pki" or "cert" or "ssl"...
But then I grepped for just "pki". And that got a lot of hits. And every one was for '/home/phil/.pki/', which does not exist, so of course all the system calls that tried to access it failed.
So is that where I should put my CAs? And if so, again, how to lay them out (paths, formats)?
Thanks.
phil
-- Phil Dumont Solid State Scientific Corporation Ph: 603-598-1194 x127 Fx: 603-598-1197
On Wed, Jun 7, 2023 at 3:03 PM cbellers @.***> wrote:
@philipdumont https://github.com/philipdumont for our installations, we always stage our internal CAs in /etc/pki/ca-trust/source/anchors and that seems to work well enough for most everything else.
I'm not sure what's going awry here but it sure is frustrating.
— Reply to this email directly, view it on GitHub https://github.com/mattermost/desktop/issues/1371#issuecomment-1581358611, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4R7MVNHNESARDRHGVWKU3XKDF75ANCNFSM4RCYKEQA . You are receiving this because you were mentioned.Message ID: @.***>
Hey all,
I want to apologize for the lack of communication on these tickets regarding authentication. But I come with some good news: we've been working on separating the external login flow from the Desktop App, deferring to the browser like many other applications do. This should overall improve security and stability around the login process, as the current implementation requires a few hacks to make it work correctly.
As of today, we released Mattermost v9.1 which has this feature implemented, and should work with all existing Desktop App versions going back to at least v5.3.0. Going forward we will be supporting this login flow for all external providers using the Desktop App, and this should fix any issues around login flow. Your server will need to be upgraded to take advantage of this feature.
I'll be closing these tickets for now as fixed, but feel free to comment and ask questions if you have any. Thanks for your patience :)