Re: Security considerations around package.{path,cpath}

[Francisco Olarte <folarte@...>]

Augusto:

On Fri, 2 Dec 2022 at 17:36, Augusto Stoffel <arstoffel@gmail.com> wrote:
> As everybody knows, the default package.path and package.cpath include
> "./?.lua" and other relative entries.  I noticed that neither LuaRocks
> nor the Lua executables I installed in my Fedora system change this.
> This means that it may be unsafe to run Lua programs if the current
> directory contains evil files.  (This is of course undesirable; it's
> guaranteed that just doing "ls" on such a directory will not lead to
> trouble.)

Did you miss a not between "it's" and "guaranteed" ? Anyway, ls safety
in general has nothing to do with the evil contents of the $CWD, it
has to do with the $PATH, I ls from inside evil directories every day
without worries.

...
> As a comparison, Python also finds "local" modules, but in that case the
> lookup is relative to the file containing the import statement, after
> resolving symlinks.  This means that if a Python program is installed in
> a system directory, it can never load modules outside system
> directories.

To do this you would need to track the original (probably
canonicalized ) filename of every function. I think it is tracked, but
doing this is a non-trivial modification, and it may imply touching a
lot of code.

> One could argue that these are packaging bugs and should be solved
> downstream, but perhaps Lua should be more helpful?  For instance, it
> could include a "--safe-paths" switch to disable lookup in the current
> directory, or maybe even have the opposite behavior, i.e. add a switch
> to allow requiring modules from "./".

There are two things a packager can do. One is fixing the lua library
to avoid having those extras, these is trivial, lua is helpful and has
a couple places in the Makefile to do it. Other is adding the
--safe-paths, or --unsafe_paths option to bin/lua executable to
preconfigure lua to it's old behaviour, these is easy too, but
unneeded as there are already ways to do it, by wrappers using the
already mentioned environment variables and similar tricks.

> What do you think?

I, personally, use very few bin/lua, I mostly use embeded and the
first thing I do is zap the paths ( including system dirs ) and add my
own. I use luacheck from the system install and some test programs
using a local install and some mocks of the embeding project, so it is
not great problem to me. I think the default is reasonably fine, some
low impact path ( i.e. modifying path defaults and/or lua.c ) would be
okay for me, deep changes ( like implementing python behaviour where .
is not $CWD but the module path ) seem low priority. JMO.


Francisco Olarte.