The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea Oh wow... I wish this wasn't a little advanced for me. I really truly love the idea of it.
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea hm... just gave me an idea - I was thinking it'd be cool to have your sensitive stuff mounted on a separate filesystem from your regular home. But even with encryption it'd be easy to spot.
How about a filesystem that's interleaved with an existing filesystem? E.g. both in one partition, but using alternating blocks, or alternating extents.
I suppose once you create something like that, people will know to look for it.
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea As much as I love the idea, users contemplating it should be aware that a real forensic expert would have little trouble finding evidence of this, and it might result in additional obstruction charges.
-
@dianea hm... just gave me an idea - I was thinking it'd be cool to have your sensitive stuff mounted on a separate filesystem from your regular home. But even with encryption it'd be easy to spot.
How about a filesystem that's interleaved with an existing filesystem? E.g. both in one partition, but using alternating blocks, or alternating extents.
I suppose once you create something like that, people will know to look for it.
-
-
@dianea As much as I love the idea, users contemplating it should be aware that a real forensic expert would have little trouble finding evidence of this, and it might result in additional obstruction charges.
-
Destruction of evidence, etc.
Nope, that's not what you want to do._Regular_ shutdown mechanics (regular closing of network connections, unmounting filesystems, clearing of open cryptosystems) or plain shutdown should be argumentable, though, as that is fully reversible (if someone +cough+ would be willing to).
One problem, though: the module won't help if one's asked to unlock the lock screen.
-
@dianea hm... just gave me an idea - I was thinking it'd be cool to have your sensitive stuff mounted on a separate filesystem from your regular home. But even with encryption it'd be easy to spot.
How about a filesystem that's interleaved with an existing filesystem? E.g. both in one partition, but using alternating blocks, or alternating extents.
I suppose once you create something like that, people will know to look for it.
-
@dianea hm... just gave me an idea - I was thinking it'd be cool to have your sensitive stuff mounted on a separate filesystem from your regular home. But even with encryption it'd be easy to spot.
How about a filesystem that's interleaved with an existing filesystem? E.g. both in one partition, but using alternating blocks, or alternating extents.
I suppose once you create something like that, people will know to look for it.
-
Destruction of evidence, etc.
Nope, that's not what you want to do._Regular_ shutdown mechanics (regular closing of network connections, unmounting filesystems, clearing of open cryptosystems) or plain shutdown should be argumentable, though, as that is fully reversible (if someone +cough+ would be willing to).
One problem, though: the module won't help if one's asked to unlock the lock screen.
@vampirdaddy GrapheneOS has a duress unlock option. I believe it works on screen unlock.
-
-
@dianea As much as I love the idea, users contemplating it should be aware that a real forensic expert would have little trouble finding evidence of this, and it might result in additional obstruction charges.
Yes, a standard login screen was designed for a civilized society, tested by countless thousands of security researchers. It is obvious there's a login screen. They are almost useless against metal chairs and a rubber hose wielded by angry detectdives...
Even better solution, but customized for a COVERT one user login:
In these uncertain times, a workaround can be covertly implemented. Just before the login screen starts, echo the text artwork of a normal boot and what looks like a kernel panic to the screen. Make it look convincing. Redirect all further text input/output to null. When the correct password is entered, the normal kernel/init will bring the system up.
Sure, entering a password will spike the power consumption up while it crunches numbers and an astute detective may notice that. So run a loop of instructions to keep a core busy. Maybe bang on the address bus a bit to make it look like a runaway oops.
The detective will ask what's up with this, so make him feel important by asking if he can fix it. Make the detective feel important. Put any NPD personality the detective has in a positive mood. Social engineering 101.
-
@vampirdaddy GrapheneOS has a duress unlock option. I believe it works on screen unlock.
@EdBruce @vampirdaddy @jgilbert @tom
Yes, and the GraphineOS duress password method works well. But only in civilized times. Not against detectives with metal chairs and a rubber hose.
You'll need to hide the login screen with the artwork of a kernel panic. Make it look convincing. Make the detective feel important, ask him if he can fix it. Butter that NPD personality up he surely has. You might not get your phone or computer back, but you'll live another day.
-
-
Destruction of evidence, etc.
Nope, that's not what you want to do._Regular_ shutdown mechanics (regular closing of network connections, unmounting filesystems, clearing of open cryptosystems) or plain shutdown should be argumentable, though, as that is fully reversible (if someone +cough+ would be willing to).
One problem, though: the module won't help if one's asked to unlock the lock screen.
@vampirdaddy @jgilbert @tom @dianea pam does the check for screen unlock too so it'll work there. The duress password is what you put on the post-it. And you make it cry for help (send network notif), wipe keys, snapshot and backup, and shutdown.
Zfs can send incrementals of encrypted volumes without having the key. The data is not destroyed, just locked by a key that is no longer on the device.
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea One useful addition to this would be a password that does an immediate wipe.
There are situations where that is indeed what you want, while that is extremely conspicuous, if the wipe is irreversible, there isn't much that your captors can do about it afterwards, and it's an option that should be available to users.
For systems that store their disk encryption key in a TPM, you could do this by just destroying the key (though I'm not sure whether PAM would even run in an encrypted disk scenario, I know far too little about how this works on Linux specifically).
-
R ActivityRelay shared this topic on
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea I would like to see devices with fingerprint ID provide for a duress finger. And for devices with FaceID to support a duress face. Perhaps sticking out your tongue could wipe the device and trigger a factory reset.
-
-
@vampirdaddy @jgilbert @tom @dianea pam does the check for screen unlock too so it'll work there. The duress password is what you put on the post-it. And you make it cry for help (send network notif), wipe keys, snapshot and backup, and shutdown.
Zfs can send incrementals of encrypted volumes without having the key. The data is not destroyed, just locked by a key that is no longer on the device.
@AMS @vampirdaddy @jgilbert @tom @dianea If only OpenZFS encryption was stable
That's really cool & something I would really like to have once OpenZFS no longer has issues with losing encrypted datasets.
