Security – How to prevent an rbash escape using Control-C

bashSecurity

I have assigned an account the login shell /bin/rbash and have found a vulnerability that seems to render rbash largely useless.

The account's .bash_login just runs .bashrc:

. $HOME/.bashrc

and .bashrc sets PATH to a directory containing the only permissible commands:

PATH=/restrict/bin

This nominally works. However, I find that if I ssh into the account and hit Control-C almost instantaneously after entering the password, there is a modest chance (maybe one in five) that rbash is interrupted and drops to the shell prompt before running .bashrc, whereupon PATH has not been changed and the user ends up with unfettered access to /bin.

Please tell me I'm missing something, because a solution seems difficult short of actually fixing and recompiling bash. I'm also wary of the long list of specific behaviors rbash modifies to obtain "security". I would abandon bash for this purpose, except that bash scripting is firmly ingrained with my users.

Best Answer

One solution could be to set the path in the .bash_login file, completely skipping loading it from .bashrc

EDIT:

After coming back and looking at this, I realized that just simply setting the $PATH variable does not actually accomplish anything as the user can just change it to include other directories that include binaries that are restricted in the sense you are taking about, nor does it prevent directly calling the executable. In POSIX compliant shells, you can set a variable as readonly (readonly PATH=/restricted/bin). To then solve the later, you would then have to restrict the user / group to not access other bin files / folders.

Related Topic