The article claims that things like Bash's restricted mode are ineffective. It gives the example:<p><pre><code> parent$ bash --restricted
child$ cd ..
bash: cd: restricted
child$ pwd
/home/rjones
child$ bash
grandchild$ cd ..
grandchild$ pwd
/home
</code></pre>
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 <i>in $PATH</i>; 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.<p>Something like:<p><pre><code> $ PATH=/etc/restricted-bin bash --restricted
</code></pre>
where /etc/restricted-bin contains symlinks to or stub-wrappers for programs that the restricted shell should be able to use.
Restricted shell escapes are a common topic in CTFs and they can be a very interesting test of one's knowledge of shell and Unix details. It's not clear to me whether people who commonly construct these challenges think that a restricted shell can actually be safe or not.<p>(It's clear that to <i>attempt</i> to have a safe restricted shell, you have to, among other things, whitelist rather than blacklist executable programs, studying each one individually to learn whether it allows arbitrary code execution or not.)
From the article:<p>> Another form of system hardening you can use is containers.<p>Let's not forget the 8k+ vulns on the top ten docker images, and the general security implications of containers.<p>Like, let me run my data export from inside the publicly downloaded container that connects to the database and hasn't been locked down, because who actually audits and hardens their containers or manually configures their docker runtime?