linuxbashshell

Does rbash restrict the use of functions?

I've built a sandbox that restricts the user to the rbash shell. But what I've found was that the user was still able to execute functions which can be bad for the environment because it enables the use of a fork bomb:

:(){ :|:& };:

I don't want to set a process limit for the user. I would like to just disable the user from declaring and executing functions.

Solution

  • Does rbash restrict the use of functions?

    No.

    The manual documents the complete list of restrictions:

    A restricted shell behaves identically to bash with the exception that the following are disallowed or not performed:

    • Changing directories with the cd builtin.
    • Setting or unsetting the values of the SHELL, PATH, HISTFILE, ENV, or BASH_ENV variables.
    • Specifying command names containing slashes.
    • Specifying a filename containing a slash as an argument to the . builtin command.
    • Specifying a filename containing a slash as an argument to the history builtin command.
    • Specifying a filename containing a slash as an argument to the -p option to the hash builtin command.
    • Importing function definitions from the shell environment at startup.
    • Parsing the value of SHELLOPTS from the shell environment at startup.
    • Redirecting output using the ‘>’, ‘>|’, ‘<>’, ‘>&’, ‘&>’, and ‘>>’ redirection operators.
    • Using the exec builtin to replace the shell with another command.
    • Adding or deleting builtin commands with the -f and -d options to the enable builtin.
    • Using the enable builtin command to enable disabled shell builtins.
    • Specifying the -p option to the command builtin.
    • Turning off restricted mode with ‘set +r’ or ‘shopt -u restricted_shell’.

    These restrictions are enforced after any startup files are read.

    The only restriction on functions in restricted bash is that the shell does not inherit them from its parent's environment. There is no limitation on defining or calling them, though their behavior is of course subject to the above restrictions.

    You're concerned that access to functions enables users to create and execute fork bombs, but that's only half true. Bash functions can certainly be used to implement fork bombs, and they do work around some of the restrictions placed by a restricted shell on what commands can be executed. However, it is pretty easy to implement a fork bomb that works in a restricted shell without using functions, too, so functions are not a sole enabler of such malicious behavior.

    For example, as long as the user can create files in their working directory, they can create a file such as this:

    boom.sh

    while true; do
  bash boom.sh &
done

    and run it via bash boom.sh. With a bit more work, a malicious user can run a similar fork bomb even without being able to create files.

    You say you don't want to set a process limit for users, but I daresay you really do. Inasmuch as you account it a problem that a user might forkbomb the system, you should have at least as much concern that a non-malicious user may negligently try to use more resources, including processes, than they should do. Placing a process limit on untrusted users is absolutely an appropriate measure to take on a multi-user system where you are unwilling risk users negligently or maliciously creating excessive numbers of processes, whether via a bona fide fork bomb or via a well-intended normal workload.