This is not a bug-report, but a suggestion. Though I myself found this project searching for pam_duress, this implementation is more general -- you allow the same account to login with different passwords depending on what the user wishes to happen upon login. This can indeed be used in a duress situation, but has other applications.

I would propose, you rebrand it as something like pam_multipassword. This may increase the module's general appeal (among the "but I have nothing to hide!" crowd) and make the very presence of the module on one's computer less suspicious to the "Big Brother".

I would also propose, you relicense it under a BSD or similar license -- to further help wide-spread adoption. For example, I intend to port your module to FreeBSD for individuals to add to their hosts, but -- as long as it remains GPL-licensed -- there is no chance of it making it into the base system.

After trying the adduser once, I found the following changes on the filesystem:

1. New file -- presumably, containing the encrypted command to execute:
   /usr/share/duress/actions/ff3361c77df7a79ccfea11ce7562f54b1010aa9a50cb7f25441df980672f3ca2
2. New (updated) file /usr/share/duress/hashes with the line:
   6qaedptqoJCi4Uoo:ff3361c77df7a79ccfea11ce7562f54b1010aa9a50cb7f25441df980672f3ca2

The flat hashes-file is a nuisance because transactional integrity is difficult to maintain -- changes to the file aren't atomic and a sudden crash may leave the file corrupted and/or "orphaned" records in the actions/ subdirectory. A similar corruption may ensue from two instances of adduser running in parallel.

A multi-user system with each user having multiple actions tied to different passwords may also begin to slow down due to linear searching of the database...

First, I discuss, whether a separate salt-storage is even necessary -- if not, you can get rid of the hashes-database altogether and simply go through the contents of the actions/-directory upon a user's login...

Is additional salt even needed?

The name of the encrypted action-file is currently a cryptographic function of:

1. Username
2. Action-specific password
3. Salt

What additional protection does the salt give in this case? Suppose, an attacker -- suspicious of the user attempting a duress-action -- confiscates the computer, gets in as root and examines the actions/ directory. Does it really help him much, that instead of a randomly-generated salt, the username itself was used to salt the filenames?

This guy argues, that usernames should not be used as salt, because they are predictable, but he also argues, the salt should be at least as big as the output of the hash-function, whereas your current code only uses 12-bytes for salt :-)

But, if we add the numeric uid to the mix -- which is much harder for an attacker to predict -- it will complicates his attempts to use a pre-built lookup-table to the point of defeating a dictionary attack, will it not?

This method will eliminate the linear search through available action-files -- the would be filename can be obtained once (from username + uid + password) and then a single stat(2) call will tell, whether it has an action tied to it or not...

Ok, ok, extra salt is needed -- can we use timestamp?

If simply salting with the username+uid is not good enough, we can add the timestamp to the mix -- the adduser program will open the future actions-file with mkstemp(3), populate it, then read the ctime off of the file descriptor and use the username + uid + ctime combination as salt.

An even stronger -- if somewhat confusing -- variation of the above would be to obtain a fake ctime from a random source and record it with futimes(2).

This method would still require a linear search through the filenames, but no separate database for salts...

A directory is a database

If you don't think, any of the above two approaches are good enough, and remain convinced, that a purely random salt must be recorded separately for each action, how about we recall, that a directory on a filesystem is already a key->value database. Straight away, the hashes file can be replaced with hashes/ subdirectory with symbolic links like this:

ff3361c77df7a79ccfea11ce7562f54b1010aa9a50cb7f25441df980672f3ca2 -> 6qaedptqoJCi4Uoo

Each such link can be added/deleted atomically while the whole collection remains easy to browse/verify/maintain without special tools.

The code would still need to perform a linear search for each login, however, but the transactional integrity will be much easier to ensure. Checking for orphaned actions will be quick too.

My master's thesis topic is as same as your title. That's why I tried to run many times in windows but it failed to get so many errors. Please help me to suggest some points to run the code.

Hi Guys. I have installed but seems not work.
I am using Debian 10 (buster) Server (no-GUI)

The /etc/pam.d/common-auth

here are the per-package modules (the "Primary" block)

auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_duress.so allow

here's the fallback if no module succeeds

auth requisite pam_deny.so

prime the stack with a positive return value if there isn't one already;

this avoids us returning an error just because nothing sets a success code

since the modules above will each just jump around

auth required pam_permit.so
auth sufficient pam_duress.so

and here are more per-package modules (the "Additional" block)

auth optional pam_cap.so

end of pam-auth-update config

The command to adduser was, Return no error:

sudo pam_duress_adduser tester yougone /home/tester/pam_duress/examples/delete-all.sh

auth.log

Feb 22 14:11:01 tester systemd-logind[1019]: New seat seat0. Feb 22 14:11:01 tester systemd-logind[1019]: Watching system buttons on /dev/input/event0 (Power Button) Feb 22 14:11:01 tester systemd-logind[1019]: Watching system buttons on /dev/input/event1 (AT Translated Set 2 keyboard) Feb 22 14:11:02 tester sshd[1210]: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:11:02 tester sshd[1210]: message repeated 3 times: [ PAM unable to resolve symbol: pam_sm_setcred] Feb 22 14:11:02 tester sshd[1210]: Please use exactly one argument with pam_duress.c, not 0 Feb 22 14:11:02 tester sshd[1210]: Accepted password for root from 192.168.1.102 port 8074 ssh2 Feb 22 14:11:02 tester sshd[1210]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 22 14:11:02 tester systemd-logind[1019]: New session 1 of user root. Feb 22 14:11:02 tester systemd: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:11:02 tester systemd: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:11:02 tester systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0) ##################### NEW REBOOT ######################### Feb 22 14:16:34 tester sshd[1587]: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:16:34 tester sshd[1587]: message repeated 3 times: [ PAM unable to resolve symbol: pam_sm_setcred] Feb 22 14:16:34 tester sshd[1587]: Please use exactly one argument with pam_duress.c, not 0 Feb 22 14:16:34 tester sshd[1587]: Accepted password for root from 192.168.1.102 port 8125 ssh2 Feb 22 14:16:34 tester sshd[1587]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 22 14:16:34 tester systemd-logind[1019]: New session 4 of user root. Feb 22 14:16:39 tester sshd[1518]: Exiting on signal 15 Feb 22 14:16:49 tester sshd[1032]: Server listening on 0.0.0.0 port 22. Feb 22 14:16:49 tester systemd-logind[990]: New seat seat0. Feb 22 14:16:49 tester systemd-logind[990]: Watching system buttons on /dev/input/event0 (Power Button) Feb 22 14:16:49 tester systemd-logind[990]: Watching system buttons on /dev/input/event1 (AT Translated Set 2 keyboard) Feb 22 14:16:49 tester sshd[1090]: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:16:49 tester sshd[1090]: message repeated 3 times: [ PAM unable to resolve symbol: pam_sm_setcred] Feb 22 14:16:49 tester sshd[1090]: Please use exactly one argument with pam_duress.c, not 0 Feb 22 14:16:49 tester sshd[1090]: Accepted password for root from 192.168.1.102 port 8126 ssh2 Feb 22 14:16:49 tester sshd[1090]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 22 14:16:50 tester systemd-logind[990]: New session 1 of user root. Feb 22 14:16:50 tester systemd: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:16:50 tester systemd: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:16:50 tester systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0) Feb 22 14:17:01 tester CRON[1467]: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:17:01 tester CRON[1467]: message repeated 3 times: [ PAM unable to resolve symbol: pam_sm_setcred] Feb 22 14:17:01 tester CRON[1467]: pam_unix(cron:session): session opened for user root by (uid=0) Feb 22 14:17:01 tester CRON[1467]: pam_unix(cron:session): session closed for user root

On console try do Duress password and get on auth.log:
Feb 22 14:19:05 tester login[1124]: PAM unable to resolve symbol: pam_sm_setcred Feb 22 14:19:05 tester login[1124]: message repeated 3 times: [ PAM unable to resolve symbol: pam_sm_setcred] Feb 22 14:19:11 tester login[1124]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=tester Feb 22 14:19:11 tester login[1124]: mkstemps failed for /tmp/action.XXXXX.tester: Invalid argument Feb 22 14:19:14 tester login[1124]: FAILED LOGIN (1) on '/dev/tty1' FOR 'tester', Authentication failure

Are I am missing some configuration? I have read on issues someone has put working on Debian Buster.

Thank you and good work!

Update:
I have tried change line position. This Accept 2 passwords. But dont run the script :(

auth sufficient pam_duress.so
+here are the per-package modules (the "Primary" block)
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_duress.so allow

When put the PAnic Password get zombie proccess

After upgrading, I'm getting the following:

$ make -j$(nproc)
gcc -fPIC -fno-stack-protector -c -I/usr/local/ssl/include -DHASH_ROUNDS=1000 -DDB_PATH='"/usr/share/duress"' adduser.c
gcc -fPIC -fno-stack-protector -c -I/usr/local/ssl/include -DHASH_ROUNDS=1000 -DDB_PATH='"/usr/share/duress"' deluser.c
gcc -fPIC -fno-stack-protector -c -I/usr/local/ssl/include -DHASH_ROUNDS=1000 -DDB_PATH='"/usr/share/duress"' pam_duress.c
gcc -L/usr/local/ssl/lib -lcrypto deluser.o -o deluser
gcc -L/usr/local/ssl/lib -lcrypto adduser.o -o adduser
gcc -L/usr/local/ssl/lib -lcrypto -shared pam_duress.o -o pam_duress.so
/usr/bin/ld: deluser.o: in function `sha256hash':
deluser.c:(.text+0x75): undefined reference to `SHA256_Init'
/usr/bin/ld: deluser.c:(.text+0x97): undefined reference to `SHA256_Update'
/usr/bin/ld: deluser.c:(.text+0xaa): undefined reference to `SHA256_Final'
/usr/bin/ld: deluser.o: in function `pbkdf2hash':
deluser.c:(.text+0xc9): undefined reference to `EVP_sha256'
/usr/bin/ld: deluser.c:(.text+0x10a): undefined reference to `PKCS5_PBKDF2_HMAC'
collect2: error: ld returned 1 exit status
make: *** [Makefile:22: deluser] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: adduser.o: in function `sha256hash':
adduser.c:(.text+0x75): undefined reference to `SHA256_Init'
/usr/bin/ld: adduser.c:(.text+0x97): undefined reference to `SHA256_Update'
/usr/bin/ld: adduser.c:(.text+0xaa): undefined reference to `SHA256_Final'
/usr/bin/ld: adduser.o: in function `pbkdf2hash':
adduser.c:(.text+0xc9): undefined reference to `EVP_sha256'
/usr/bin/ld: adduser.c:(.text+0x10a): undefined reference to `PKCS5_PBKDF2_HMAC'
/usr/bin/ld: adduser.o: in function `genSalt':
adduser.c:(.text+0x141): undefined reference to `RAND_bytes'
/usr/bin/ld: adduser.o: in function `Encrypt':
adduser.c:(.text+0x1fa): undefined reference to `EVP_aes_256_cbc'
/usr/bin/ld: adduser.c:(.text+0x203): undefined reference to `EVP_sha256'
/usr/bin/ld: adduser.c:(.text+0x34e): undefined reference to `EVP_BytesToKey'
/usr/bin/ld: adduser.c:(.text+0x357): undefined reference to `EVP_CIPHER_CTX_new'
/usr/bin/ld: adduser.c:(.text+0x3b9): undefined reference to `EVP_CIPHER_CTX_reset'
/usr/bin/ld: adduser.c:(.text+0x3be): undefined reference to `EVP_aes_256_cbc'
/usr/bin/ld: adduser.c:(.text+0x3e0): undefined reference to `EVP_EncryptInit_ex'
/usr/bin/ld: adduser.c:(.text+0x40c): undefined reference to `EVP_EncryptUpdate'
/usr/bin/ld: adduser.c:(.text+0x43f): undefined reference to `EVP_CIPHER_CTX_free'
/usr/bin/ld: adduser.c:(.text+0x4d8): undefined reference to `EVP_EncryptFinal_ex'
/usr/bin/ld: adduser.c:(.text+0x50b): undefined reference to `EVP_CIPHER_CTX_free'
/usr/bin/ld: adduser.c:(.text+0x563): undefined reference to `EVP_CIPHER_CTX_free'
collect2: error: ld returned 1 exit status
make: *** [Makefile:18: adduser] Error 1

libpam-dev (selecting 'libpam0g-dev' instead of 'libpam-dev') and libssl-dev are installed.

I'm testing it on a virtual machine. At the time of defining the module on the /etc/pam.d/common-auth file.

I tried to add it like this:

# here are the per-package modules (the "Primary" block)
auth	[success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_duress.so allow

And is not working.

Trying auth sufficient pam_duress.so just broke my logins.

BTW: I have eCryptfs installed too.

First of all, the script's name should not be static (/tmp/action), but be constructed on the fly with mkstemp(3) to avoid clashes, when multiple logins (by the same or different users) to the same host happen at the same time.

Second, should not the code perform a setuid(2) after fork() to the user before invoking the script? Unless PAM somehow does this automatically, it seems like this is a major security flaw in the current implementation -- allowing users' scripts to run as root...

Hello everyone,
I'm pretty new to github so apologies if this is inappropriate. Let me know and I'll remove it.

OpenSSL 1.1 made many types opaque and pam_duress will not compile with that version. I forked it and, time permitting, will chip away at this issue