Is setting a mail user's shell to /usr/bin/passwd in the /etc/passwd file a safe way to allow them to change their own password by simply ssh'ing?

Question

I have a machine which is used mostly as a mail server:

$ uname -a Linux myhost.com 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

and I would like users who do not actually log into the machine (but use it to authenticate and get their mail) to be able to change their own passwords. If I put /usr/bin/passwd in /etc/shells (so the passwd command is a valid shell), and change the shell entry for the users as in:

someuser:x:557:557:Some User:/home/someuser:/usr/bin/passwd

then if they ssh to the host, they'll get something like this:

$ ssh myhost.com
someuser@myhost.com's password: <type their current password>
Last login: Wed Sep 25 16:07:35 2013 from some-ip
Changing password for user someuser.
Changing password for someuser.
(current) UNIX password: <type their current password again>
New password: <type their new password>
Retype new password: <type their new password again>
-passwd: all authentication tokens updated successfully.
Connection to myhost.com closed.

that works great... but is it safe? Is their some way to exploit that and break into a real shell?

Thanks.

P.S. In my environment, it is reasonable to assume that the users have ssh already--but if there is an alternative for password changing that is simply "better", I'd like to hear it :)

Answer 1

Allowing a well known program (ssh) remote access to a suid program is in principle insecure. passwd sets user id, i.e. elevates permissions. Ssh should be used with caution because it also delegates firewall administration to the remote user (port forwarding etc.). If sshd is your only remote access option, you have only one server, and you insist using this server as a means to change passwords and to serve mail, then limit all options for sshd and mail only and harden the rest of the box by removing everything except the bare services you need: mail and password changing.

passwd's source has been under scrutiny, but do you know the classic login hack that Ken Thompson (creator of unix) made in the C compiler? Read Ken's 'Reflections on Trusting Trust' to decide who to trust.

Answer 2

I like @datasmid's answer, it makes some good points.

Seems to me that what you are doing is equivalent to allowing users a shell prompt and access to the passwd command.

If you are comfortable doing that, then I see no reason why you should not do what you are doing. If anything, it's slightly more secure as you aren't letting the user execute any other commands easily.

There wouldn't be a way to break out of the passwd command and into a shell unless passwd makes some provision for execing into a shell. I don't see why it would. You can probably search against the source code for passwd pretty easily for that.

One thing an attacker might try is, if they already have a local password, is to buffer-overflow passwd by entering an insanely long reply to passwd's prompts. In that case, anything might be possible (risks may be mitigated by running on a CPU that has XD/NX support and heap address randomization). I don't know what passwd does if its input buffer is exceeded but that's the first thing that comes to mind for me. passwd is a setuid program but I would hope (haven't checked source) that it drops privileges once it discovers its euid is not 0 BEFORE checking for input.