Is rbash secure if user login and ssh passwords are disabled?

Question

I've got a server that I want to use as an SSH gateway for remote and local port forwarding. I don't want arbitrary commands to be able to be executed on it, only my scripts.

I keep reading about how restricted shells are easy to break out of, but is rbash good enough if:

• the user has no password (so s/he can't log in to a shell)
• ssh passwords are disabled (so a key is required)
• PATH=~/usr/bin (only, so no files from elsewhere can be executed)
• the entry in ~/.ssh/authorized_keys is prefixed with: command="cmd_handler",no-pty,permitopen="127.0.0.1:*",permitopen="localhost:*",no-agent-forwarding,no-X11-forwarding

"cmd_handler" is an rbash shell script that can do a couple of different specific things based upon what is piped into ssh from stdin. It lives in the ~/usr/bin folder along with symlinks to executables it requires, specifically fold, head, nc, sed, ssh-keygen, tee, tr. ~/usr/bin is the only folder in PATH, so these are the only commands available.

The user is the group owner, with read-only access, for any files or folders requiring access (including the ~/usr/bin folder). The user is not the owner, and does not have write access, to any files and folders other than ~/.ssh and ~/.ssh/authorized/keys (which is required).

I don't see any way this leaves the system vulnerable, since the single command that can be executed by the remote computer is "cmd_handler". And if, somehow, the remote user could in fact execute another command, there's not much avaialble. tee, sed, and ssh-keygen create the theoretical possibility of ~/.ssh/authorized_keys being modified to execute arbitrary commands, but even if they could, all that's around to use are the seven commands, and if they write something into /tmp or ~/.ssh, it won't matter because rbash won't execute anything not in PATH.

So, back to the original question: is this good enough for what I want to do, or do I really need to look into AppArmor or something? I'd like an answer that explains a specific vulnerability, rather than general statements about everyone knowing that rbash is easy to break out of and whatnot. That may be true, but is it specifically insecure for this application?

Answer 1

Having a script that consumes untrusted user input basically means you've got a full shell user in that session (if there is a vulnerability in your script's parsing routines). So, your "PATH" setting is not really at play.

Moreover, your authorized_keys key prefix allows the remote user to open connections to any local ports on the machine, which can be used to exploit the environment (if you have a weak local service listening on the loopback interface).

To answer your question correctly (with highlighting specific vulnerabilities), one needs to see the script you are running and how it processes its input, since that would be the primary exploitation vector in your case. However, if you are building a reliable environment, I would suggest not to rely on the "deny list" approach (when you are trying to block all the bad stuff), but instead use the "allow list" approach (when you define what is allowed explicitly, with the default implicit deny). In your case though, given that you want to use bash scripting, I would look into MAC solutions such as SELinux, where I would assign a SELinux user to the account and would define a restricted domain to the processes run by that user.