[Feature] Force second device for sudo

[mcdope]

Understood

Yes, this is not a bug report / support request

Text

When #31 is done, it would be possible to implement a way to force a second device for sudo usage.

Example usecase: Office, School etc having usb keys for each user. Each user sometimes need to use sudo, like for example installing software. Admin could then visit the users desk, plug the sudo stick in, user runs command(s), admin walks away with his stick again. Or a shared family computer etc.

[mcdope]

How to implement:

• <device> in <user> should have an attribute sudo, if present require this device for su(do) request

todo: check if this should be used for polkit or like that.

[mcdope]

Better idea: <option id="sudo_device">DeviceName</option> in <user> or global.

if global it would basically disallow sudo for users not having the sudo device configured though.

[mcdope]

Or put a <device> in <service id="sudo"> ?

Guess this is the best idea, because it doesn't restrict the feature to sudo

[mcdope]

todo:
[ ] Modifiy opts->device_list to have sudo attribute
[ ] Modifiy pusb_device_connected to only iterate devices having the attribute

[v-Nyo]

What about adding an option to use different config files specified in pam?

[mcdope]

What about adding an option to use different config files specified in pam?

Not sure what you mean and how that would affect this feature. Can you elaborate?

[v-Nyo]

I got the idea from google authenticator where you can have a pam config like this:
auth required pam_google_authenticator.so user=root secret=/path_folder/${USER}

So I though you could specify the config that pam_usb uses like this

[mcdope]

I still dont see the point, sorry :D What exactly would that enable/enhance? imho an option in the existing config like planned is enough and less work Message ID: ***@***.***>

…

[v-Nyo]

well instead of pam_usb handling which service requires another drive / second drive it would be handled by pam.

I though that this solution might be more secure and simpler. IDK

[mcdope]

True. But it would require modifying the pam config for each user you add to the system, instead of a single centralized config file. Also if you want to update the list of whitelisted services you would have to modify N files. Additionally global options would be useless then, meaning much dead code that needs to be removed. The single centralized config file also allows easier automatic deployment imho, i.e a school handing out USB keys to students and teachers. Thanks for the suggestion, I indeed wasn't aware of that approach. But I dislike it :) Sorry. Am Di., 14. Jan. 2025 um 21:57 Uhr schrieb v-Nyo ***@***.***>:

…

well instead of pam_usb handling which service requires another drive / second drive it would be handled by pam. I though that this solution might be more secure. IDK — Reply to this email directly, view it on GitHub <#223 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZI2U3GKAK3S4ML4OMAPHT2KV23JAVCNFSM6AAAAABLF4TLACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJRGA4DONZZG4> . You are receiving this because you were assigned.Message ID: ***@***.***>