rbash

Start an interactive shell session

$ rbash

$ rbash -c "[command]"

$ rbash [path/to/script.sh]

$ rbash -x [path/to/script.sh]

$ rbash -e [path/to/script.sh]

$ rbash -s

rbash [options] [arguments]
bash -r [options] [arguments]

-r
    Enables the restricted shell mode. When bash is started with this option, or invoked as rbash, it enters restricted mode.

--login or -l
    Makes this shell a login shell, reading appropriate startup files like .bash_profile.

-c string
    Reads and executes commands from string instead of positional parameters.

-s
    Reads commands from standard input. If this option is used, positional parameters are set to the remaining arguments.

-i
    Makes this shell interactive.

rbash, or Restricted Bash, is a version of the Bash shell that operates in a restricted mode. Its primary purpose is to provide a controlled environment for users, limiting their capabilities and preventing certain actions that could compromise system security or stability. When running in restricted mode, users are typically unable to change directories with `cd` beyond certain paths, set `PATH` or `SHELL` variables, execute commands with `/` in their names, redirect output, or call `exec`. This makes it suitable for scenarios like FTP servers, kiosks, or specific application interfaces where users should only perform predefined actions. However, rbash is not a security sandbox and should not be relied upon as a standalone security measure. It is relatively easy to bypass its restrictions if not combined with other Linux security mechanisms.

rbash is often insufficient as a standalone security measure. Experienced users can frequently bypass its restrictions through various methods, such as using `ssh` escape sequences, exploiting poorly configured system utilities (`vi`, `less`, `awk`, `find`, `nmap`), or through environment variable manipulation. It is strongly recommended to combine rbash with other Linux security mechanisms like `chroot` jails, `SELinux`/`AppArmor`, cgroups, and strict file system permissions (`sudo` for specific commands) to create a truly secure restricted environment.

When rbash is active, the following actions are typically restricted:

• Changing directories with the cd builtin command.
• Setting or unsetting the values of the SHELL, PATH, ENV, or BASH_ENV variables.
• Specifying command names containing a slash (`/`).
• Specifying a filename containing a slash as an argument to the . builtin command.
• Using the hash builtin command to specify command names containing a slash.
• Importing function definitions from the shell environment at startup.
• Parsing the SHELLOPTS environment variable from the shell environment at startup.
• Redirecting output using `>`, `>>`, `>|`, `&>`, `&>>`.
• Using exec to replace the shell with another command.
• Adding or deleting builtins with the enable builtin command.
• Turning off restricted mode with `set +r` or `set +o restricted`.

To set up rbash for a user, you typically need to:

• Create a symlink from rbash to bash (if rbash doesn't already exist as an executable linked to bash).
• Change the user's default shell in /etc/passwd to /bin/rbash (or wherever rbash is located).
• Configure the user's PATH variable in their ~/.bash_profile or equivalent to include only safe executables within specific, controlled directories.
• Ensure that the user's environment and startup files (.bashrc, .bash_profile) do not contain commands that could allow a bypass.
• Combine with a `chroot` jail for stronger isolation.

The concept of a restricted shell has existed in Unix-like systems for a long time, often implemented by `sh` (Bourne shell) or other shells. rbash is not a separate executable but rather bash itself invoked with the -r option or through a symlink named rbash. This functionality has been an integral part of the Bash shell for many years, providing administrators with a built-in method to create restricted user environments without needing external tools. Its development has mirrored the evolution of Bash, with ongoing efforts to address potential bypasses, though it remains primarily a deterrent against accidental misuse rather than a robust security sandbox.

bash(1), chroot(8), sudo(8), sh(1), zsh(1), csh(1), setsid(2)