Looking for dedicated users willing to test experimental new builds

[mcdope]

Are there any users out there that want to help testing new experimental builds?

I plan to do some huge refactoring for which it would be nice to have people that are familiar with pam_usb. Ideally you would use it in an "non-standard" scenario (like unusual display managers, exotic distributions etc etc) but any testing would be highly appreciated.

For this I would provide .deb packages, users of other distributions would need to do compile from source from a given branch.

[mcdope]

[mcdope]

First signed RPM: https://www.dropbox.com/s/nc9kcsxmcm94uof/pam_usb-0.8.2-1signed.x86_64.rpm?dl=0

[Fuseteam]

hi hi, i just saw your email! i'm willing to test, once i find me an stick i'll give it a whirl for sure~

[mcdope]

Nice, thanks for joining this discussion since I can now just tag when new stuff is there to test. I promise I won't overuse it ;-)

[Fuseteam]

haha sure looking forward to it xD

[mcdope]

"Beta" (Google Style, not really beta but not proper versioned yet 😆 ) version of 0.8.3 available at branch prepare-083

[mcdope]

I assume the silence means either that you had no time, or you found nothing. Anyway - this will be released tomorrow 😆

Edit: merged & released ^^

[Fuseteam]

Yeah sorry been a little too busy, thanks for keeping it up to date! Should i find something when i do have time i'll definitely keep posted

[mcdope]

No problem at all, totally understand.

In fact I don't have time myself for this currently xD

[steelsnake]

Downloaded and installed - seems good so far on Kubuntu 22.10. Will do some extensive testing and let you know how it goes.

[mcdope]

This thread is almost half a year old and that release is published for while now :D

I guess you wanted to reply to this one: #124 (comment)?

[steelsnake]

I can always test... I have two Kubuntu Jammy installs, one with backports enabled and one without. Plus a few servers that I can just run a KVM on with any version you'd like to test on.

[mcdope]

Thanks, you can bet I will come back to that since I hate to put out new releases without user feedback.

Soon (more or less) there will be test builds for multi-device-per-user-support in example.

[steelsnake]

Sure, can absolutely test that. Just let me know what system(s) you want this tested on. Since I'll test on KVM, no danger of destroying anything. :)

[mcdope]

New test build!

This replaces the hardcoded "local" whitelist with a config based one. So that weirdo login managers etc. don't require a patch but can just be added by the user.

Currently it contains the exact same whitelist as previously. So you should not notice any change at all.

In the future the default list will be empty and the user needs to enable the entries they need.

.deb, .rpm and .zst at: https://www.dropbox.com/sh/h5qxy3kyr12ymq3/AACKxDpJvIsUdYCXuj0EbYUKa?dl=0

[mcdope]

I would appreciate any testing and information on improving pam_usb, esp. if it's about security. And this very much is.

Ofc the best would be if we can detect if the current request is local, but knowing there is SOME remote connection to the session like with vnc/teamviewer is also already an improvement. I want to prevent any miss-authentication when deny_remote isn't disabled, even if it maybe means denying really local requests just cuz there is some VNC/TV conn. (And yes, maybe this is a bit too much love for detail - but hell, this is a PAM module after all)

But I don't want to ask too much for your time. If you're bored and have the time for it, sure - test some more and if you find something it will maybe be useful. ss -ntp i.e for sure will helpful and i'm almost certain that will end up in the code. But really: only if you can spare the time. My comfort / lazyness shouldn't be your reason ^^

Edit: what I will for sure test very soon: running via RDP. I have a local proxmox server which hosts cura in a debian xfce LXC via RDP,. Gonna re-use that to test "rdp-to-login".

Edit 2: Of course any help on improving pam_usb will be documented in the changelog - whatever that is worth

[steelsnake]

I'll see if I can figure out a reliable way to detect VNC short of just checking active connections. The other big question would be Wayland, I think.

No need to give any credit anywhere - I generally much prefer to just help because helping is the right thing to do :)

[mcdope]

xvnc might be due to the way I've invoked it:

nohup /usr/bin/x11vnc -auth guess -forever -display :0 -loop -noxdamage -repeat -rfbauth /etc/vnc/passwd -rfbport 5900 -shared 1>/dev/null 2>&1 &

How exactly do you run this, manually, via some service file, something else? Wanna replicate the setup for testing.

[steelsnake]

Manually, I have a vnc.sh bash script that I invoke whenever I need VNC service (with a handy "STOP" parameter to stop it later):

#!/bin/bash

if [[ $1 == STOP ]]; then
        killall x11vnc
else
        nohup /usr/bin/x11vnc -auth guess -forever -display :0 -loop -noxdamage -repeat -rfbauth /etc/vnc/passwd -rfbport 5900 -shared 1>/dev/null 2>&1 &
fi

You'd need to generate/store the password with x11vnc -storepasswd MyPasswd /etc/vnc/passwd

[mcdope]

Forgot: With TeamViewer you could just check whether ss -ntp returns a line containing TeamViewer_Desk as mentioned above. If you like I can see if there's other ways to do this. Netstat should also work, not sure if ss or netstat is more commonly installed these days.

Does this also work for x11vnc? Could you try? I currently cant setup VMs - out of storage :D

[mcdope]

There is a new release upcoming (finally). Even if it's just a minor version it's a kinda important update since it includes fixes for stuff with crash (like in segfault :D) or at least "wont work" potential.

If you want a preview: build from this branch / PR -> #218

Prebuilt packages available at -> https://www.dropbox.com/scl/fo/kmll4q7tz3z0agbk4q30x/h?rlkey=da59dbbovgv3ip1qch3hy6lz4&dl=0 (still uploading right now)

[mcdope]

@Fuseteam you are the one with tmux if I remember correctly? Your feedback would be esp. nice since the memory fixes affect tmux handling. For me it still works like expected, but you know tmux better than me.

[steelsnake]

Hey there! Sorry for the late reply, I was a bit busy. I just installed the package on both of my Ubuntu boxes (one on 23.04 the other on 22.04 LTS). So far, looks good. I'll report back Sat or Sun to let you know if anything blows up.

I do use tmux all the time btw, started with a simple systemd service (attached, added .txt so git doesn't freak out)
tmux.service.txt
...and then attaching when needed via tmux attach -t default

Thanks for the update.

[steelsnake]

Alright, a bit later than expected thanks to pesky RL and my flash drive died. LOL

I didn't notice anything out of the ordinary, seems to work as intended. No crashes, nothing.

[mcdope]

Dont worry about however long it takes, I'm very thankful for any feedback :D

History has proven that "works on my machine" isnt the best indicator :D So: thanks for testings! I also haven't noticed any issues. Even tried sudo bash in tmux with tmux on top with sudo.... etc pp ^^

Edit: these test builds are btw now published as 0.8.4

[Fuseteam]

hey i now see this, i'll test when i have time soon™ too

[mcdope]

@Fuseteam @steelsnake and everyone interested: experimental new test builds at https://www.dropbox.com/scl/fo/y5tha7yhx18uo35gal1rv/AFIjBlTnmd4RfkrjHCwv6rA?rlkey=boqwcnbrgfjk34dbtlrpcafk9&dl=0, source is in branch fix-some-mem-stuff / #229 .

These are master plus changes proposed by a new coding AI, mainly related to memory and string handling. I expect this to crush some exotic bugs.

What I need you to test is just "did it break anything?" 😁 I couldn't notice any issues but I want to be sure before merging.

[steelsnake]

Works fine on my home system. I can test it on my "work" PC on Monday.

Thanks for all your work, much appreciated!

[mcdope]

I also couldn't find any issues so far, tried on desktop and laptop.

Will continue to use it for some days before merging though.

[steelsnake]

Okay, seems to work on my other PC as well. No issues so far, but only tested for a little bit.

• Local: Login works. sudo works
• Remote:
  • SSH properly denies
  • sudo properly denies
  • VNC+TeamViewer allows (makes sense as it's not recognized as remote)

Both VNC and TeamViewer I think are simply beyond the scope of pam_usb, so not really worried about that. There's just too many different remote access solutions out there.

[mcdope]

For TV there is actually a way, but I first need to find a way to test for VNC too. Esp. since I guess VNC is more common on *nix then TV.

[mcdope]

For the brave ones: there is now a first preview build offering support for multiple devices per user (#31). You can find the code in PR #177.

However, well possible there are still some bugs left. It's only VM-tested for short time now. Also it's still full of debugging output that will vanish before it will be released.

You can find signed .deb and .rpm packages in this Dropbox folder: https://www.dropbox.com/scl/fo/piormhnmfnqquubspwu4o/AM_yFraRt9H6qUt3umqDY8E?rlkey=o8idyui7cf1klmteqh5m35ov2&dl=0

Be aware: If you install this build AND configure multiple devices, your config wont be backwards compatible anymore afterwards. To downgrade to another version you will have to manually remove all but one device from your user section in the config.

[steelsnake]

Seems to work fine I just installed it on a second PC. I did however NOT use a multiple device setup. I'll try that sometime this weekend.

[mcdope]

There is now a new build in that dropbox folder, having improved agent support for multiple devices. This is now pretty much complete, except the still left debug outputs.

I couldn't find any issues so far in either the "normal" stuff or the new "multidevice" stuff.

[mcdope]

And another new build in the folder. If nobody notices/reports any bugs with it this is the final version of that feature.

To me it seems fine, tested it on VM, Desktop and Laptop and couldn't notice any issues.

[mcdope]

This feature is now merged and available in master, next nightly build will contain it too.

Release will be as 0.8.5 some when in the future.

[steelsnake]

As near as I can tell the latest version does seem to work fine. I've installed it 2 days ago and don't see any issues so far. If I can test anything specific, do let me know please.

[mcdope]

You could try adding a second device for your user. But I don't expect any issues (as long as you don't try adding more then ten devices per user :D) Am Sa., 20. Juli 2024 um 17:57 Uhr schrieb steelsnake < ***@***.***>:

…

As near as I can tell the latest version does seem to work fine. I've installed it 2 days ago and don't see any issues so far. If I can test anything specific, do let me know please. — Reply to this email directly, view it on GitHub <#124 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZI2U6SDZWORHO6IK2AJ6LZNKCF5AVCNFSM5WLZSUJKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBRGAZTAOBV> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[steelsnake]

Just tried it, I kinda didn't think about trying THAT. LOL... braindead. Anyway, as you said, locking by unplugging does properly lock the system, with password prompt. As expected, it also unlocks properly when plugging the USB stick back in.

[mcdope]

Thanks for trying. Than it is for sure an "inverted variant" of the lightdm issue.

[Fuseteam]

lovely, fun enough gnome doesn't appear to have this; it even seems to briefly pop up the password prompt while the key is plugged in

[mcdope]

Just took a look at the src of pam_poldi for use with GPG smartcards. They just block the chain until $event (Card inserted, PIN entered) happens or a timeout triggers. So basically the same like my suggested lightdm workaround (#221).

I never used SmartCards on a PC, but I assume you have to enter the PIN on each usage - so this wouldn't affect the KDE-Lockscreen in the same way like pam_usb.

This research result is also an argument to stop doing workarounds kinda imho.

[Fuseteam]

This research result is also an argument to stop doing workarounds kinda imho.

yeah especially if there is a general way

[mcdope]

Lovely, thanks for the detailed instructions - much appreciated Am Mo., 22. Juli 2024 um 20:57 Uhr schrieb steelsnake < ***@***.***>:

…

Absolutely sure :) Kubuntu 24.04 System Info: Operating System: Kubuntu 24.04 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Kernel Version: 6.8.0-38-generic (64-bit) Graphics Platform: Wayland Not tested on Qt 6 Test: - Connected device: Bus 001 Device 008: ID 154b:00f3 PNY USB 3.0 FD - Lock screen (don't log off, just lock), wait until "lock" screen with "unlock" button appears - Unplug device, wait a few secs just in case - Can unlock screen just by pressing the "Unlock" button image.png (view on web) <https://github.com/user-attachments/assets/885f966c-32b7-413b-8190-b5b51e85d235> Comparison, locking without USB device: - Unplug device before locking - Lock screen - As expected, asks for password image.png (view on web) <https://github.com/user-attachments/assets/7a14c242-699a-48d0-a2a2-a80337541098> — Reply to this email directly, view it on GitHub <#124 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZI2U2CSXZLQIQDOQGTH4DZNVIXZAVCNFSM5WLZSUJKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBRGE4DCNJY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mcdope]

Hmmm when I see those screens, and re-read #221, I smell the same behaviour. Or in other words: your diagnose of " KDE seems to simply check the credentials on lock rather than unlock" is most likely absolutely on point. I bet the lockscreen starts the PAM chain directly, at which point pam_usb will (still) see the device and allow the PAM request. But unlike for `lightdm`, #221 wouldn't fix your issue. For that we need something like an "ignore the first request" option (which obviously should be set on `<service>` level instead of globally. Which would also kinda solve #221, even if a bit more annoying for the user... I guess if you wouldn't lock manually but let the agent do it when the device is unplugged this wouldn't occur. Am Mo., 22. Juli 2024 um 21:01 Uhr schrieb Tobias Bäumer < ***@***.***>:

…

Lovely, thanks for the detailed instructions - much appreciated Am Mo., 22. Juli 2024 um 20:57 Uhr schrieb steelsnake < ***@***.***>: > Absolutely sure :) > > Kubuntu 24.04 > > System Info: > Operating System: Kubuntu 24.04 > KDE Plasma Version: 5.27.11 > KDE Frameworks Version: 5.115.0 > Qt Version: 5.15.13 > Kernel Version: 6.8.0-38-generic (64-bit) > Graphics Platform: Wayland > > Not tested on Qt 6 > > Test: > > - Connected device: Bus 001 Device 008: ID 154b:00f3 PNY USB 3.0 FD > - Lock screen (don't log off, just lock), wait until "lock" screen > with "unlock" button appears > - Unplug device, wait a few secs just in case > - Can unlock screen just by pressing the "Unlock" button > image.png (view on web) > <https://github.com/user-attachments/assets/885f966c-32b7-413b-8190-b5b51e85d235> > > Comparison, locking without USB device: > > - Unplug device before locking > - Lock screen > - As expected, asks for password > image.png (view on web) > <https://github.com/user-attachments/assets/7a14c242-699a-48d0-a2a2-a80337541098> > > — > Reply to this email directly, view it on GitHub > <#124 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAZI2U2CSXZLQIQDOQGTH4DZNVIXZAVCNFSM5WLZSUJKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBRGE4DCNJY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[Fuseteam]

i think for the kde one, we should get touch with the kde maintainer to see if we can solve it upstream first, for lightdm i'm not sure who the current maintainer is tho 🤔

[mcdope]

I doubt that KDE or lightdm would adjust something for us. Also I wonder how both react to a) fingerprint readers b) to smartcards, or better said: how do these modules handle it.

But I don't have hardware to test either.

Edit: my guess would be that stuff using biometry or physical stuff like smartcards usually just blocks the chain till they have a result. But for one that would break password-login in case of failure but also: this is just not how PAM Is supposed to work except I understood it incorrectly (which is totally an option :D)

Edit 2: Biometry stuff only applies to login, smartcard also to lock/unlock I guess.

[Fuseteam]

i'd say 'asking is free' worse case we learn more about how their inner working work :D

[mcdope]

Considering the participation so far it's kinda unlikely we will get any more votes on this topic still today... So I call it a day, the vote is over.

There will be NO (further) workarounds for "broken" / "wierd" PAM clients like lightdm or kscreenlocker added.

[Fuseteam]

sounds good

[mcdope]

It's "that time of the year again" - I need dedicated tested for a new build. Please try as much as you can and just see if everything still works for you.

This is a security related update, so I won't give details about changes till the final update is released. Same applies for sourcecode of this update, will be released after/with the update for security purposes.

You can find the testing builds at https://www.dropbox.com/scl/fo/dc8blo5sv3eetneagi6bs/AL_SwIdDBd4eg8vZHST2MVU?rlkey=h9cbgh5a1gelxqk6erk1qobk9&st=hlzet1ms&dl=0

[mcdope]

That's actually intended, it doesn't include the recent fix to get polkit working again but is based on plain 0.8.6 instead.

[mcdope]

This update is released as 0.8.7. Please update every machine you use pam_usb on immediately!

[Fuseteam]

sorry for being slow this time around 😂

[steelsnake]

Tested and working so far:

* Local sudo works

* SDDM login works

* TMUX locally: sudo bash tosses this error: `Could not get properties: Unknown object '/org/freedesktop/login1/user/self`.`

* TMUX remotely correctly identifies the session as remote and denies the request

* SCREEN locally: Access denied (no further error presented, just access denied)

* SCREEN remotely: Correctly identifies session as remote and denies the request

This is on Kubuntu 25.10, Wayland

Very interesting, usually the bugs are in deny_remote and not in the local part :D Will debug that tomorrow.

Sorry for the late reply, I got distracted by work. tmux is just called as user for me, and then just sudo bash:
See store for details.

$ sudo bash

• Authentication request for user "jenni" (sudo)
  Could not get properties: Unknown object '/org/freedesktop/login1/user/self'.
  Could not get properties: Unknown object '/org/freedesktop/login1/user/self'.
• Access denied.
  [sudo: authenticate] Password:

It's not a big deal either, I rarely use sudo within tmux :) I haven't tried it with 0.8.7 yet, will try tomorrow, also will try on Kubuntu 24.04 - I don't have 26.04 yet for testing.

Thanks for all the work and the continued development. MUCH appreciated.

[mcdope]

@steelsnake Seems to be a problem of your installation. Just installed a fresh Kubuntu 25.10 install, updated it, installed pam_usb and tested both. Both are working for me. See #293 (comment)

Would be nice if you could add <option name="debug">true</option> to your config and try again, that would maybe point into the right direction. But let's continue the discussion about that in the linked ticket.

[mcdope]

New release, 0.9.2, arrived. Again many security fixes.

Please try a) if it broke something and b) if you can break it :D

[steelsnake]

Will do when I can. I'm still in the hospital, but hopefully out on Tuesday or Wednesday.

Thanks for all your work, sorry I was out of commission for a while.

[mcdope]

Get well soon :)