Skip to content
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

Block fprint unlock on gdm #163

Closed
boredsquirrel opened this issue Jan 21, 2024 · 4 comments
Closed

Block fprint unlock on gdm #163

boredsquirrel opened this issue Jan 21, 2024 · 4 comments

Comments

@boredsquirrel
Copy link

SDDM doesnt, but GDM supports login with fingerprint.

SDDM may support this soon too, it was planned for Plasma 6.

A better option would be something like GrapheneOS, which afaik locks the fingerprint after 3 failed attempts.

On my hardware this is nearly always the case though, because that sensor sucks. It will be more secure though.

Also, fprint-enroll is broken somehow on Silverblue-main-hardened, but I havent tried regular silverblue-main. It works perfectly fine in the TUI, which smells like an upstream bug.

@RoyalOughtness
Copy link
Collaborator

I'm confused by this cause it seems like multiple issues in one 😄

On the one hand, you're asking for fprint unlock to be blocked for some reason (why?).

On the other hand, you're reporting a bug. Can you please clarify the core goal for this issue?

@boredsquirrel
Copy link
Author

boredsquirrel commented Jan 22, 2024

so, I was

  1. requesting a security hardening of fprintd to lock after less tries (if not already done)
  2. relativizing that request by the fact that the sensor doesnt work well anyways, so not even I can unlock my laptop like that.

I think the default timeout is 2 failed tries at least in the terminal for sudo. This may be different on gdm (and in the future sddm) and also different in plasma and gnome screenlocker.

@RoyalOughtness
Copy link
Collaborator

for 1, I'm confused. if it already locks after a few failures, that seems like desired behavior. potentially #127 is related

for 2, please check upstream silverblue-main like you mentioned and if you can't repro there, reopen this issue. Otherwise this is likely an issue with the package itself and you can report it to the maintainers.

@RoyalOughtness RoyalOughtness closed this as not planned Won't fix, can't repro, duplicate, stale Jan 22, 2024
@34N0
Copy link
Collaborator

34N0 commented Jan 22, 2024

Yes this is a PAM issue. The relevant PAM service stacks are unchanged from Fedora. This hsould be tested on a normal Silverblue VM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants