I have trouble configuring duress on arch linux. First of all I am not even sure if using /etc/pam.d/system-auth is ok since there is no common-auth. The default content of system-auth is:

#%PAM-1.0

auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow sha512
password   optional                    pam_permit.so

-session   optional                    pam_systemd_home.so
session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_permit.so

I have tried replacing

-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so

with

-auth      [success=3 default=ignore]  pam_systemd_home.so
auth       [success=2 default=bad]     pam_unix.so          try_first_pass nullok
auth       [success=1 default=ignore]  pam_duress.so
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so

When I run a test with regular password I get:

~ $ sudo pam_test $USER                                                                                                                                             [master]
[sudo] password for dusan:
Credentials accepted.
Not Authenticated

And when I use a pass I've set for a script I just get "sorry, try again" and pass prompt

Summary: There are some memory leaks in the code that have been squashed and some additional checks are written to handle if malloc fails. Issue: #34 Test:

$ pam_test $USER
Credentials accepted.
Password: 
Hello World
Account is valid.
Authenticated

Valgrind Results:

$ 2>&1 valgrind pam_test $USER > /dev/null | tail -n 14 | head -n 9
==44655== HEAP SUMMARY:
==44655==     in use at exit: 5,089 bytes in 15 blocks
==44655==   total heap usage: 5,716 allocs, 5,701 frees, 1,261,870 bytes allocated
==44655== 
==44655== LEAK SUMMARY:
==44655==    definitely lost: 0 bytes in 0 blocks
==44655==    indirectly lost: 0 bytes in 0 blocks
==44655==      possibly lost: 0 bytes in 0 blocks
==44655==    still reachable: 5,089 bytes in 15 blocks

The initial implementation does not run user scripts as the target user; nor checks to see if the script being run is owned by the user; only if it's readable and executable by the "owner". Then all scripts are run as root, even the local ones. This could allow and attacker to use a non-privileged account to execute root level commands if the PAM Duress module is employed.

Repro steps:

I installed a new image of Ubuntu to test the project and kept encountering an error where the code would not execute:

Jun 24 01:38:49 zaku pam_test: File is valid.
Jun 24 01:38:49 zaku pam_test: Processing /etc/duress.d.
Jun 24 01:38:49 zaku pam_test: Could not open directory /etc/duress.d, No such file or directory.
Jun 24 01:38:49 zaku pam_test: Executing /home/zaku/.duress/hello.sh.
Jun 24 01:38:49 zaku pam_test: Could not run script /home/zaku/.duress/hello.sh, Exec format error.

I resolved the issue by specifying on top of the shell script that it's a shell script

echo -e '#!/bin/sh\necho "Hello World"'
#!/bin/sh
echo "Hello World"

This is what we want to indicate that this is a shell script

https://github.com/nuvious/pam-duress/blob/04e607f9ab674c8dbbf27ea8bb59158178a72f69/src/duress.c#L141

I was skimming the code and noticed you forgot to free duress_hash in the function is_valid_duress_file since sha_256_sum allocates memory in the heap, it should be freed before calling return

After logging in with a duress password, the keyring notification window pops up and says the login password no longre matches the keyring password and asks for the password

Hey :-)

Does anyone, especially the author have tried or has some opinion if this will work for macOS?, I have to study the differences when it comes to how PAM operates in each of this systems tho.

Thanks!

Hi,

I will leave it here, maybe someone will find this useful:

https://github.com/pampanic/pam_panic https://github.com/x13a/pam-party https://github.com/nekohasekai/lockup https://github.com/x13a/Duress

Feel free to close it. Have a good day.

I was interested in testing this package out on openSUSE so I managed (I think) to put in OBS in a very bare bones way. (https://build.opensuse.org/package/show/home:lilfroggy/pam-duress). It seems to install properly, however my pam config file doesn't really seem to have the same syntax as the one in the example and also says it won't except any modifications to it:

/etc/pam.d/common-auth:

#%PAM-1.0
#
# This file is autogenerated by pam-config. All manual
# changes will be overwritten!
#
# The pam-config configuration files can be used as template
# for an own PAM configuration not managed by pam-config:
#
# for i in account auth password session; do \
#      rm -f common-$i; sed '/^#.*/d' common-$i-pc > common-$i; \
# done
#
# Afterwards common-{account, auth, password, session} can be
# adjusted. Never edit or delete common-*-pc files!
#
# WARNING: changes done by pam-config afterwards are not
# visible to the PAM stack anymore!
#
# WARNING: self managed PAM configuration files are not supported,
# will not see required adjustments by pam-config and can become
# insecure or break system functionality through system updates!
#
#
# Authentication-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth	required	pam_env.so	
auth	optional	pam_gnome_keyring.so
auth	required	pam_unix.so	try_first_pass

Any ideas on how to make it work with such a setup?

Issu #29 uncovered an issue with Arch where pam_test would return authentication failures while ssh localhost and sudo su - USER was triggering the appropriate scripts. Determine if/why the pam_test isn't function in Arch and/or determine if it's worth trying to maintain that tester vs advising users to use ssh localhost or sudo su - USER to test properly.

/etc/duress.d scripts should be run after ~/.duress script to allow for a script to be implemented that removes pam-duress itself as a cleanup action. In the current implementation one would have to write a delayed-action script to remove pam-duress system-wide which if misconfigured may allow an attacker to see the modules presence after the attacker has dropped to a user shell.

I have set up pam_duress, but when a duress password is used it doesn't seem to run the script and just logs in without doing anything.

[email protected] ~$ cat ~/.duress/hello.sh 
#!/bin/sh
echo "Hello World"

[email protected] ~$ duress_sign ~/.duress/hello.sh 
Password:  # 1234
Confirm:  # 1234
Reading .duress/hello.sh, 30...
Done
818034A48A634AEACAB6753A80E2160D42EE25C44791A083D5F8727E2B3D7A99
[email protected] ~$ chmod 400 ~/.duress/hello.sh.sha256 
[email protected] ~$ ls -l ~/.duress/
total 8
-r-x------ 1 blecc blecc 30 Sep 30 16:48 hello.sh
-r-------- 1 blecc blecc 32 Sep 30 16:51 hello.sh.sha256
[email protected] ~$ ssh [email protected]
[email protected]'s password:  # 1234
< no hello world >
Last login: Fri Sep 30 16:46:36 2022 from ::1 
[email protected] ~$ 

Using an incorrect (non-duress) password still fails to log in at all, but no input causes the script to actually run. I have tried putting the script in /etc/duress.d instead of ~/.duress and using a non-outputting check (eg touching a file in /tmp/) with the same result.

Hello, first of all can I just say thank you for this project as it has worked well on other systems. However, on my gentoo install I am running into a few problems. Firstly, the system-auth vs common-auth issue, I followed the guidance for arch users however I do not know if it has worked for reasons I will state later Next, the library was placed in /lib/security and was not being detected. I moved it to /lib64/security and su stopped spitting out an error saying it could not find the library However, it still did not work. I attempted to log the PAM while ssh'ing in with and without my duress password. The only difference between the two was this line: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=max This suggests pam_duress.so is not even being loaded so that's why I believe that the system-auth might not be valid I am not knowledgeable at all with PAM so im sure there is an easy answer that I am just missing. Any help is appreciated! Max

When trying to enter a "password under duress", we return to the password entry window. If you enter a regular password, authentication is normal.

In the same time:

sudo pam_test $ USER
Credentials accepted.
Password:
Account is valid.
Authenticated

Configuration /etc/pam.d/common-auth

auth    [success=2 default=ignore]      pam_unix.so nullok
auth    [success=1 default=ignore]      pam_duress.so nullok
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional        pam_ecryptfs.so unwrap
auth    optional                        pam_cap.so

`

Hi there,

I think there are chances that a duress password could be the utmost simple one, which means it could be a dictionary word or easily being brute force and guessed it out. An adversary could also use PII or related information from the victim, to potentially guess what is the password(either the correct one or the duress code).

SHA256 is great, and it does the job on checksum, but not when it comes to the case that we should also protect the duress script itself.

I suggest introducing an option to add cryptographically signed duress script, ideally would be PGP signed, on top of the sha256 hashed script. So that the user can always know if the file has been tampered with, and failover to the sha256 hashed script if the validation failed.

Regards, Ivan

Some admins may not trust their users to create duress scripts and want full control to only have the ones in /etc/duress.d run when duress password is used. Modify the module such that it reads in a configuration file /etc/duress.conf to see if the administrator wants to enable ~/.duress for users and create a group that controls which users have their ~/.duress files parsed during login.