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

[Augusto Stoffel <arstoffel@...>]

On Sat,  3 Dec 2022 at 10:03, Francisco Olarte wrote:

> 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" ?

No.  As you mentioned yourself, doing "ls" from inside evil directories
_is_ safe.  It would still be safe if /bin/ls is replace with a Python
script using the default interpreter settings.  It would not be safe if
/bin/ls is replaced with a Lua script without tweaking the package
paths.

>> 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.

Yes, I mentioned Python for comparison, but I don't mean it's a good
approach for Lua.

>> 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.

I don't think a Linux distro will want to do this.  The same interpreter
used to run prepackaged scripts is also available for the user, who
expects the default Lua behavior.

> 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.

As I mentioned before, there's always some way to do it.  But neither
LuaRocks nor Fedora do it, despite being otherwise well-engineered
systems, so my the conclusion is that a better way to do this is
necessary.

> 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 think embedded use has a very different set of considerations.