Why does $chsh have to be a Set-UID command? What are the vulnerabilities of a normal user changing his/her own shell from perhaps bash to zsh?

Any help would be greatly appreciated!

  • There is no $ within the name of this command on any Unix. Its correct name is: chsh or /usr/bin/chsh. – dan Oct 8 '15 at 21:19

chsh is setuid because in order to change a user's shell, it must modify the root-owned read-only /etc/passwd file.

The system administrator may wish to limit which shells a user may choose, for example if users are assigned a shell which logs all commands to syslog. The traditional way to do this would be to remove all other shells from the /etc/shells file, as chsh restricts users to choosing shells in that file. (That then implies that for any users who aren't restricted in that manner, an administrator needs to change their shells by hand - editing /etc/passwd - since they can no longer use chsh to do it.)

  • Should a system admin. restrict normal users from changing their own shells? If so, what security concerns may arise if normal users are able to change their shells? – gabece Oct 10 '15 at 7:00

There is no vulnerability for a normal user to change their shell.

However, a user's shell is stored in the user database, together with other sensitive fields. Most Unix variants store the database of local users in a single file, /etc/passwd. (The name comes from the fact that the original Unix stored users' passwords in that file; on modern systems, passwords are no longer stored in /etc/passwd, which is world-readable, but in a file that isn't world-readable, such as /etc/shadow on Solaris and Linux.) While allowing a normal user to change their shell isn't a security concern, some other fields are sensitive (e.g. the user ID) — but mostly, the file contains information about all users, so allowing a user to modify it would be disastrous since they could change anybody else's account.

Thus users can only modify /etc/passwd indirectly, through commands such as chsh and chfn.

Furthermore, it would be a vulnerability to allow restricted users to change their shells. An account can be restricted to run a specific command by setting that specific command nothing as their shell (or even or effectively prevented from logging in altogether by setting /sbin/nologin or /bin/false — or /bin/true for that matter — as the shell). If the user was somehow able to change their login shell, they would evade the account restriction. The restriction is implemented in chsh by refusing to change the shell if the user's current shell is not in a whitelist of permitted “generalist” shells stored in /etc/shells.

Additionally, the chsh command refuses to change a user's shell to a shell that isn't in this whitelist. This ensures that users won't lock themselves out of their account by setting a bad shell there, which isn't a security concern but is a support concern.

To summarize, chsh has to have elevated privileges because it needs to modify a file that's shared among all users. This allows chsh to apply additional useful policies.

While it would be possible to split out the shell into a separate per-user file, that would require a more complex design with one separate file per account. Unix was based on simple designs, with information stored on flat text file. Fine-grained access control with one datum per file is not traditional, would have a performance impact (not a big one nowadays though), and the advantages in terms of security (not requiring chsh and chfn to have elevated privileges) are pretty small. So there's no compelling reason to change this design.

While it would be possible and relatively simple to make /etc/passwd owned by a dedicated system account (or better, a group), and make chsh setuid (or better, setgid) to that dedicated account, there wouldn't really be a security benefit. If you manage to exploit chsh, never mind what else you can do with chsh itself, you're pretty much guaranteed to be able to allow yourself access to the root account.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.