search

rafket / pam_duress

A pam module written in C for duress codes in linux authentication
GNU General Public License v2.0
146 stars 11 forks source link

Executing /tmp/action #6

Open UnitedMarsupials-zz opened 7 years ago

UnitedMarsupials-zz commented 7 years ago

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...

rafket commented 7 years ago

For the first issue you are completely right, I will fix it as soon as I can.

I have no plans in fixing the second one, it is in fact normal functionality, as some scripts that would be useful in duress require root privileges (for example rm -rf /). I don't think that this is a flaw in the PAM implementation either, because adding those scripts requires root privileges.

UnitedMarsupials-zz commented 7 years ago

some scripts that would be useful in duress require root privileges

The stuff like rm -rf / can be accomplished with sudo or a similar existing mechanism -- there is no need to provide a separate one (along with the inevitable attack-vector).

As things stand, the more general-purpose use of the module is limited -- access to scripts can only be given to a small group of trusted users. This may not matter for folks travelling with their single-user laptops, but administrators running remotely-accessible multi-user Unix-servers may wish to restrict the module's use to the users' own files only.

For example, a user travelling to Iran may need to wipe his /var/mail/mbox on a remote server in a hurry, but not the entire spool directory...

adding those scripts requires root privileges.

This increases the admin's workload -- it means, the admin needs to be able to carefully read each new script to vet it. It is bad enough having to do that for the sudoers -- there is no need to introduce a new mechanism. By implementing a setuid-call, you can make much of the usage self-administered by the users -- without removing any functionality from those desiring it.

If you still disagree, whether or not to change UID can be controlled by a command-line argument...

UnitedMarsupials-zz commented 7 years ago

I added use of mkstemp(2) to #7.

FYI: http://superuser.com/questions/72164/panic-password-on-linux/1176739