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.
@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. -
@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.@jackemled @AMS @jgilbert @tom @dianea
Or instead of zfs-send you use rsync (over SSH if crypto is needed)? -
@jackemled @AMS @jgilbert @tom @dianea
Or instead of zfs-send you use rsync (over SSH if crypto is needed)?@vampirdaddy @AMS zfs-send & rsync are two different things with different uses, but do similar things. Both do unidirectional syncs, but rsync is for files only & optionally (SSH by default) uses encryption in transit. zfs-send is for copying a snapshot or the current state of the entire filesystem or specific datasets within it, & those datasets either have or do not have encryption on the disk. If the dataset is encrypted, then the generated snapshot file will contain only encrypted data; if not, then only plaintext data. If the snapshot is streamed to a remote OpenZFS filesystem through SSH, then there is additional encryption in transit equivalent to the default settings for most rsyncs, since both use SSH.
OpenZFS filesystem or dataset encryption is unstable right now & can cause data loss because of keys being dropped & stuff if some storage devices don't appear to the computer in the right order or never appear at all or something. We're talking about at rest encryption, not in transit encryption.
-
@vampirdaddy @AMS zfs-send & rsync are two different things with different uses, but do similar things. Both do unidirectional syncs, but rsync is for files only & optionally (SSH by default) uses encryption in transit. zfs-send is for copying a snapshot or the current state of the entire filesystem or specific datasets within it, & those datasets either have or do not have encryption on the disk. If the dataset is encrypted, then the generated snapshot file will contain only encrypted data; if not, then only plaintext data. If the snapshot is streamed to a remote OpenZFS filesystem through SSH, then there is additional encryption in transit equivalent to the default settings for most rsyncs, since both use SSH.
OpenZFS filesystem or dataset encryption is unstable right now & can cause data loss because of keys being dropped & stuff if some storage devices don't appear to the computer in the right order or never appear at all or something. We're talking about at rest encryption, not in transit encryption.
@vampirdaddy @AMS What AMS means is that you can wipe the keys from your device & still be able to send the state of your OpenZFS filesystem to a remote even though you don't have the keys anymore. So you can simply have your keys backed up somewhere else, then in an emergency wipe them from the local device (so your filesystem can't be read) & zfs-send to a remote incase you never get the local device back from police or a thief or whoever is taking it. That way you can secure your data without having to wait for the backup to complete first like with most filesystems, simply do the backup second.
This is really cool to me because delta syncing encrypted data is hard, but the way ZFS snapshots work means you're actually copying only new blocks, not actual changes, & those blocks can contain changes.
-
@vampirdaddy @AMS What AMS means is that you can wipe the keys from your device & still be able to send the state of your OpenZFS filesystem to a remote even though you don't have the keys anymore. So you can simply have your keys backed up somewhere else, then in an emergency wipe them from the local device (so your filesystem can't be read) & zfs-send to a remote incase you never get the local device back from police or a thief or whoever is taking it. That way you can secure your data without having to wait for the backup to complete first like with most filesystems, simply do the backup second.
This is really cool to me because delta syncing encrypted data is hard, but the way ZFS snapshots work means you're actually copying only new blocks, not actual changes, & those blocks can contain changes.
@vampirdaddy @AMS It also means less time until the filesystem is secured, but if you use SSH you still have to wait for the send to complete before you can delete your SSH keys. Maybe a solution would be to use TLS to an open & write only fileserver so SSH keys can be deleted earlier, maybe something like a pastebin.
-
@vampirdaddy @AMS It also means less time until the filesystem is secured, but if you use SSH you still have to wait for the send to complete before you can delete your SSH keys. Maybe a solution would be to use TLS to an open & write only fileserver so SSH keys can be deleted earlier, maybe something like a pastebin.
@jackemled @vampirdaddy In my case, backup service is a single use key limited only being able to send snapshots, no shell, no recv, not used for anything else. And the duress lock sends a burndown (wipe key from backup endpoint) and wipes that local key after the backup completes.
-
@vampirdaddy @AMS What AMS means is that you can wipe the keys from your device & still be able to send the state of your OpenZFS filesystem to a remote even though you don't have the keys anymore. So you can simply have your keys backed up somewhere else, then in an emergency wipe them from the local device (so your filesystem can't be read) & zfs-send to a remote incase you never get the local device back from police or a thief or whoever is taking it. That way you can secure your data without having to wait for the backup to complete first like with most filesystems, simply do the backup second.
This is really cool to me because delta syncing encrypted data is hard, but the way ZFS snapshots work means you're actually copying only new blocks, not actual changes, & those blocks can contain changes.
@jackemled @AMS
that’s a neat trick I hadn‘t have known yet.
Cool.With rsync the risk of critical file system compromise is lower - but you need to have both filesystem cryptographically open during sync.
Or maybe something like borg / restic might be the weapon of choice - but then that’s backup only, without performant, direct access to the files on the other side when the SHTF.
-
@jackemled @vampirdaddy In my case, backup service is a single use key limited only being able to send snapshots, no shell, no recv, not used for anything else. And the duress lock sends a burndown (wipe key from backup endpoint) and wipes that local key after the backup completes.
@AMS @vampirdaddy I hadn't even thought of that! sshd allows setting a special login shell per user, which doesn't have to be a shell at all!
-
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.
