[PATCH] [doc] [repost] warnings about restricted shell (Was: Zsh - Multiple DoS Vulnerabilities)

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

2019-05-12 17:21:49 +0100, Stephane Chazelas:
[...]
> At least, we should give more warning about it and recommend
> alternatives. Here's an attempt below:

I'm bringing this up again as it looks like it has stayed mostly
unnoticed (except maybe by Chet ;-))

IMO, the restricted mode should be deprecated. In any case, we
should at least warn against using it. Below was my attempt
which could definitely be improved, I hope it can serve as a
basic for discussio.

See also what Chet recently added about it in the bash
documentation at
https://git.savannah.gnu.org/cgit/bash.git/commit/doc/bash.info?id=52e469696418877c5b7cd7f752f5f8309ef65a38
which is more concise.


diff --git a/Doc/Zsh/restricted.yo b/Doc/Zsh/restricted.yo
index 6cf9b36b5..121e2ae8d 100644
--- a/Doc/Zsh/restricted.yo
+++ b/Doc/Zsh/restricted.yo
@@ -37,3 +37,46 @@ Restricted mode can also be activated any time by setting the
 tt(RESTRICTED) option.  This immediately enables all the restrictions
 described above even if the shell still has not processed all startup
 files.
+
+A shell em(Restricted Mode) is an ancient way to restrict what users may
+do. However modern systems have better, safer and more reliable ways to
+confine user actions like em(chroot jails), em(containers) or em(zones).
+
+A restricted shell is very difficult to implement safely. That feature
+may be removed in a future version of zsh.
+
+It's important to realise the restrictions only apply to the shell and
+not to the commands it runs (except for some of its builtins). While a
+restricted shell can only run the restricted list of commands accessible
+via the predefined `tt(PATH)` variable, it doesn't prevent those
+commands from running any other command.
+
+As an example, if `tt(env)' is among the list of em(allowed) commands,
+then it allows the user to run any command as `tt(env)` is not a shell
+builtin command and can run arbitrary executables.
+
+So when implementing a restricted shell framework it's important to be
+fully aware of what actions each of the em(allowed) commands or features
+(think em(modules)) can perform.
+
+Many commands can have their behaviour affected by environment
+variables. Except for the few listed above, zsh doesn't restrict setting
+environment variables.
+
+Having a `tt(perl)', `tt(python)', `tt(bash)` script as a restricted
+command probably means the user can work around the restriction by
+setting specially crafted `tt(PERL5LIB)', `tt(PYTHONPATH)',
+`tt(BASHENV)' environment variables. On GNU systems, one can have any
+command doing character set conversion (which includes zsh itself) run
+arbitrary code by setting a `tt(GCONV_PATH)' environment variable, those
+are only a few examples.
+
+Bear in mind that contrary to some other shells, `tt(readonly)' is not a
+security feature in zsh as it can be undone and so cannot be used to
+mitigate the above.
+
+A restricted shell is only going to work if the allowed commands are few
+and carefully written so as not to grant more access to users than
+intended. It's also important to restrict what zsh module the user may
+load as some of them like `tt(zsh/system)', `tt(zsh/mapfile)' or
+`tt(zsh/files)' would allow bypassing most of the restrictions.

-- 
Stephane