9

I've read a few things to indicate that restricted shells can be broken out of if not implemented properly (even wikipedia, for instance).

I'm looking for some guidance on what causes security holes in restricted shells and how to solve these problems.

I assume the main problem is the binaries that you allow the user to use; if any of these programs facilitate execution of further programs/scripts with higher privileges.
Does that mean a default rbash shell is relatively secure?
Are there any specific programs that are (more-or-less) definitely safe / not safe (so far I've seen specific examples of vim and scp used to break out)?
And are there other things to think about?

Also, are there better alternatives to using a restricted shell when you want to limit the commands that a user can run?


Update 1
Following on from what bstpierre mentioned with using ssh command=, has anyone tried using command= to force the user to run a script that took input from the user using SSH_ORIGINAL_COMMAND and then ran limited additional commands/programs based on that input? I imagine this would have quite a limited use-case, but seems viable to me so long as the script was careful about the input it accepted.

Update 2
The suggestion I made in Update 1 turns out to be exactly what gitolite does; using command= and SSH_ORIGINAL_COMMAND, with some hook magic to differentiate between branches. Info from their docs.
So I know that this method is a viable alternative, but I'm still after an answer to the original query about restricted shells.

Improve this question
1
  • 1
    Re: your update, you can take a look at what gitolite does with SSH_ORIGINAL_COMMAND. Gitolite relies heavily on ssh -- a single unix login account is shared by many users who only have access to a subset of git operations via ssh.
    – bstpierre
    Dec 14, 2011 at 13:30

1 Answer 1

Reset to default
9

I've set up restricted shell environments that put the user into a chroot jail. Only the bare minimum executable files are copied into the jail. The shell user has hardly any permissions in the jail -- everything is defaulted to deny, and I only provide permissions where necessary. You could combine the jail with rbash for an extra layer of protection. The advantage of a chroot jail is that, if the user breaks out of rbash, he's still stuck in a chroot jail and can't access the rest of your system. (There have been instances where it's been possible to break out of a chroot jail, but properly constructed on a patched OS it is hard to attack.)

Another point to consider is whether you really need to provide a shell. Could the service you need to provide be set up as a simple, secure web service?

Finally, if the shell is provided via ssh, you can restrict the command set available to the user by requiring login via keys and setting the command= in your authorized_keys file. You do have to be careful here, though, because if the command(s) you permit allow the user to "break out", you're no better off than with the same attack against a restricted shell.

Improve this answer
3
  • 1
    +1 If I can't VM, chroot is my next step for test/untrusted platforms
    – Rory Alsop ♦
    Dec 13, 2011 at 21:13
  • 1
    What are the benefits of using a chroot jail rather than a program like rbash? Do you just have more control over how the environment is restricted? And have you ever used something like makejail for that? I've also updated the question based on what you've said about ssh command.
    – Demelziraptor
    Dec 14, 2011 at 9:43
  • @Demelziraptor: I haven't used makejail. I haven't set up a jail recently but I do use a script to help set them up. (Can't remember where I got it, sorry.)
    – bstpierre
    Dec 14, 2011 at 13:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .