There are a number of reasons this is a bad idea.
First and foremost being that bash, fundamentally, is written to facilitate users doing whatever they want to do. It was written to make it easy to do anything you'd want to do a vast number of different ways, and as a result it's possible to do most things a vast number of different ways. It was not written with access controls in mind, and as a result it lacks access controls. As a result, adding access controls on top of it, and making certain tasks impossible within it, is a bit like trying to use a bulldozer for needlepoint; maybe not impossible, but very, very difficult.
So, for example, any command run from
.bashrc can be interrupted, backgrounded, or killed if the user (or more likely a script that the user wrote) is fast enough (by sending
^Z). On the command line, users can unset variables, they can open subshells, they can specify direct paths to executables (many of which are in predictable locations), and they can even send things over the network even if you don't have any network-accessible applications available to them, because they can open tcp streams directly from bash.
These restrictions are enforced after any startup files are read.
When a command that is found to be a shell script is executed (see Shell Scripts), rbash >turns off any restrictions in the shell spawned to execute the script.
And then, of course, there's the fact that you must constantly make sure your version of bash is up to date, and that your kernel is up to date and that you're using an explicit whitelisting approach and carefully vetting each application you allow. It's a pretty Herculean task, and most of the time there is a better / simpler way to accomplish what you want to accomplish.
If you have a particular security setup in mind, and you were considering using
- Do some more research around the internet (Google and DuckDuckGo are both quite helpful for this, although the site you're currently reading is one of the best resources you'll find), and once you have some alternatives in mind and some research to back each,
- Ask about your setup here! Read the site FAQ, and try to ensure your question isn't a duplicate, first. But apart from that, this is where you'd want to ask the questions you're having.