Hi, On 7/14/20 11:16 AM, Mickaël Salaün wrote: > --- > Documentation/admin-guide/sysctl/fs.rst | 45 +++++++++++++++++++++++++ > fs/namei.c | 29 +++++++++++++--- > include/linux/fs.h | 1 + > kernel/sysctl.c | 12 +++++-- > 4 files changed, 80 insertions(+), 7 deletions(-) > > diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst > index 2a45119e3331..02ec384b8bbf 100644 > --- a/Documentation/admin-guide/sysctl/fs.rst > +++ b/Documentation/admin-guide/sysctl/fs.rst Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> with one tiny nit: > @@ -165,6 +166,50 @@ system needs to prune the inode list instead of allocating > +The ability to restrict code execution must be thought as a system-wide policy, > +which first starts by restricting mount points with the ``noexec`` option. > +This option is also automatically applied to special filesystems such as /proc > +. This prevents files on such mount points to be directly executed by the Can you move that period from the beginning of the line to the end of the previous line? > +kernel or mapped as executable memory (e.g. libraries). With script > +interpreters using the ``O_MAYEXEC`` flag, the executable permission can then > +be checked before reading commands from files. This makes it possible to > +enforce the ``noexec`` at the interpreter level, and thus propagates this > +security policy to scripts. To be fully effective, these interpreters also > +need to handle the other ways to execute code: command line parameters (e.g., > +option ``-e`` for Perl), module loading (e.g., option ``-m`` for Python), > +stdin, file sourcing, environment variables, configuration files, etc. > +According to the threat model, it may be acceptable to allow some script > +interpreters (e.g. Bash) to interpret commands from stdin, may it be a TTY or a > +pipe, because it may not be enough to (directly) perform syscalls. thanks. -- ~Randy
