On 2024-02-15 16:17:58 -0800, Russ Allbery wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote: > > >> and pkexec is essentially a type of sudo and should be unavailable to > >> anyone who is using a restricted shell. > > > The pkexec source doesn't say that the goal is to check whether > > the user is in a restricted shell. > > So far as I am aware, the only purpose served by /etc/shells historically > and currently is to (a) prevent users from shooting themselves in the foot > by using chsh to change their shell to something that isn't a shell, and > (b) detect users who are not "normal users" and therefore should have > restricted access to system services. See shells(5), for example: > > Be aware that there are programs which consult this file to find out > if a user is a normal user; for example, FTP daemons traditionally > disallow access to users with shells not included in this file.
But note that checking the login shell of the user in /etc/shells (which seems OK for me) is different from checking the value of $SHELL. > > Also note than even in a restricted shell, the user may set $SHELL to a > > non-restricted shell. > > This is generally not the case; see, for example, rbash(1): > > It behaves identically to bash with the exception that the following > are disallowed or not performed: > > [...] > > * setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or > BASH_ENV Well, SHELL is read-only. But a restricted shell can be started with a $SHELL value that doesn't point to a restricted shell: $ echo $SHELL /bin/sh $ rbash -l vinc17@qaa:~$ echo $SHELL /bin/sh So, making decisions based on the $SHELL value is prone to security issues, and I think that it would be better to look at the login shell in /etc/shells. > > Moreover, /etc/shells also contains restricted shells. > > That definitely should not be the case and any restricted shell that adds > itself to /etc/shells is buggy. See chsh(1): > > The only restriction placed on the login shell is that the command > name must be listed in /etc/shells, unless the invoker is the > superuser, and then any value may be added. An account with a > restricted login shell may not change her login shell. For this > reason, placing /bin/rsh in /etc/shells is discouraged since > accidentally changing to a restricted shell would prevent the user > from ever changing her login shell back to its original value. On my machine, both rbash and rksh93 are in /etc/shells. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
