LinuxQuestions.org - PAM & SUID bit on /usr/bin/passwd ("Authentication Token Manipulation Error")

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - PAM & SUID bit on /usr/bin/passwd ("Authentication Token Manipulation Error") (https://www.linuxquestions.org/questions/linux-security-4/pam-and-suid-bit-on-usr-bin-passwd-authentication-token-manipulation-error-4175657266/)

PAM & SUID bit on /usr/bin/passwd ("Authentication Token Manipulation Error")

I've started playing a little bit with PAM on my Debian 9 server (kernel 4.9.0-9-amd64), especially with libpam-cracklib in order to enforce a better account password policy.
So in my /etc/pam.d/common-password, I've added the following:

Code:

password requisite pam_cracklib.so retry=3 difok=3 dcredit=-1 lcredit=-1 minlen=12 ocredit=-1 reject_username ucredit=-1

password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 remember=400

password [success=1 default=ignore] pam_winbind.so use_authtok try_first_pass

I didn't need to create file /etc/security/opasswd as it was already present (probably created during libpam-cracklib installation), with the appropriate permissions:

Code:

-rw------- 1 root root 0 jul 12 12:50 /etc/security/opasswd

However, users are not able to change their password anymore via passwd (prompt says: "Authentication Token Manipulation Error"). It worked before...
NB: it still works via root

I've tried to delete the remember=400 part with no avail, even after reboot.

After investigation, I've noticed that the SUID bit on /usr/bin/passwd has disappeared:

Code:

-rwxr-xr-x 1 root root 59680 may 17 2017 /usr/bin/passwd

So I've just set it up again with chmod u+s /usr/bin/passwd and guess what, no problem anymore!

Question: do you have an idea why the SUID bit disappeared on /usr/bin/passwd?
Thank you in advance :)

Quote:

Originally Posted by l0f4r0 (Post 6014360)

So I've just set it up again with chmod u+s /usr/bin/passwd and guess what, no problem anymore!

Question: do you have an idea why the sticky bit disappeared on /usr/bin/passwd?
Thank you in advance :)

I haven't got an answer to your question, just a remark:

u+s is setting the setuid (set user id) bit, just like g+s is setgid (set group id).
The "sticky" bit is set with +t, and isn't used much anymore (it meant that the code of the executable should "stick" in RAM after exit as it was likely to be needed very soon again).
They are the three special bits and mostly get cleared on all "chmod" operations on the file, unless you explicity specify them IN that chmod again.

Quote:

Originally Posted by ehartman (Post 6014538)

u+s is setting the setuid (set user id) bit, just like g+s is setgid (set group id).
The "sticky" bit is set with +t, and isn't used much anymore (it meant that the code of the executable should "stick" in RAM after exit as it was likely to be needed very soon again).

Oups...you're completely right!!
Of course, I meant the SUID (s/S or 4000 in octal), not the sticky bit (t/T or 1000 in octal). I've just edited my OP, thank you very much ehartman :)

NB: it's true, the sticky bit applied to a file is not very used anymore as computers are always more powerful. However the sticky bit on a directory is much more common. It allows you to restrict the "write" permissions on it so only the owner can delete his/her files/folders inside a directory where the sticky bit is applied even if everyone has permission "w". See the /tmp folder.

Quote:

Originally Posted by l0f4r0 (Post 6015039)

NB: it's true, the sticky bit applied to a file is not very used anymore as computers are always more powerful. However the sticky bit on a directory is much more common.

I know, but here we were talking about an executable (normal file with x-bits).
The caching in (much larger) RAM in modern machines does all of what the t bit for executables was meant to do. And the offloading of functionality into (resident) shared libraries (objects) also did its part.
The sticky (that's what its name came from) bit was invented to stick important executables into the (low amount of) RAM at that time.

As it was only useful for executables, people have invented other uses for it later, like that usage for directories.
But in HP-UX I've also seen usage for the t-bit for symbolic links (it's called a "transition link")

Quote:

sticky bit on symlinks
======================
In HP-UX 10.0 and later, a symbolic link that has its sticky bit set is called a transition link (i.e. links to ease the transition to the new SVR4 filesystem layout). Transition links are a bit faster, because the linked-to filename is stored in the inode itself, instead of using an allocation unit to store the link.

and there are probably other uses I'm not aware of.