News for hackers. Stuff that matters.

A comment on Restricted Shells: Sometimes Persuasive but Usually Fallacious.

Re:Restricted Shells: Sometimes Persuasive but Usually Falla... by LukeShu on Wednesday March 13, 2019 @05:42PM (#19384177)
The article claims that things like Bash's restricted mode are ineffective. It gives the example:

    parent$ bash --restricted
    child$ cd ..
    bash: cd: restricted
    child$ pwd
    /home/rjones
    child$ bash
    grandchild$ cd ..
    grandchild$ pwd
    /home
where the escape is that 'child' was able to create the non-restricted shell 'grandchild'. If you think that properly configuring a restricted bash shell is a simple as executing `/bin/bash --restricted`, then you need to read the manual. The restricted shell can execute arbitrary programs in $PATH; to deploy a restricted Bash shell, you'll need to construct a PATH with whitelisted programs that it is safe to execute. The restricted Bash cannot adjust PATH, and it cannot execute programs outside of PATH.

Something like:

     $ PATH=/etc/restricted-bin bash --restricted
where /etc/restricted-bin contains symlinks to or stub-wrappers for programs that the restricted shell should be able to use.
[ Parent | on HN ]
Re:Restricted Shells: Sometimes Persuasive but Usually Falla... by russjones on Wednesday March 13, 2019 @06:41PM (#19384704)
Maybe I did not provide the best example, but the point I was driving at is that the restrictions here are at the application level and not at the system level.

If you take the approach you are taking, similar to ForceCommand, you have to make sure none of the commands in your PATH allow code execution. For example git, vim, less, awk, and find, all of which I use on a daily basis, can all be used to re-launch a restriction free bash.

Once you remove all the commands you have to, how much of a shell do you have left?

[ Parent | on HN ]
Re:Restricted Shells: Sometimes Persuasive but Usually Falla... by LukeShu on Wednesday March 13, 2019 @07:25PM (#19385024)
> but point I was driving at is the restrictions here at the application level and not at the system level.

Your point is well-taken!

I'm obviously not privy the the conversations you've had with potential customers, so I'm not entirely sure what they're asking for. But (IMO) the way to think of a restricted shell is to think of it as a shell that can't do anything, except for a small list of narrowly defined tasks. Thinking of it as a normal full shell, with "unsafe" things disabled, that's a losing game, as you note.

[ Parent | on HN ]
Re:Restricted Shells: Sometimes Persuasive but Usually Falla... by gruez on Wednesday March 13, 2019 @07:10PM (#19384916)
sounds like a weaker version of chroot, in the sense that it's possible to escape if you can get any of the whitelisted programs to run an arbitrary command.
[ Parent | on HN ]
Re:Restricted Shells: Sometimes Persuasive but Usually Falla... by matthewbauer on Wednesday March 13, 2019 @07:25PM (#19385020)
Can it execute direct paths to files or is it restricted to what is in PATH?
[ Parent | on HN ]
Re:Restricted Shells: Sometimes Persuasive but Usually Falla... by LukeShu on Wednesday March 13, 2019 @07:31PM (#19385061)
It is restricted to what is in PATH. Among other things, it disallows "Setting or unsetting the values of the … PATH… variables.", and disallows "Specifying command names containing slashes."

https://www.gnu.org/software/bash/manual/html_node/The-Restr...

[ Parent | on HN ]