Summary: luasql (database.lua) threat model unclear, security
measures get in the way
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Sat May 12 21:35:00 2012
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: Need Info
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
                 Release: S2_4
         Discussion Lock: Any
        Operating System: Any
         Planned Release: 2.4.0,2.5.0



data/database.lua (the Lua script handling authentication and database access
in 2.4+) is loaded in its own Lua instance, separate from the instance in
which the older server-side "game"/"scenario" scripts run.

However, the "auth" Lua instance gets the same restricted environment that
"scenario" scripts do (see bug #15624, bug #15725).

Right now this is a pain for me because for patch #3287, I want to call Lua's
os.time() rather than invoke non-portable SQL time functions (as used
currently). The "os" module is not included in the restricted environment.

In general, it seems a bit daft for the database script, which has read/write
access to some of the highest-value data the server deals with (user
credentials) as well as a suite of general-purpose database access functions,
to run with the same restrictions as "scenario" scripts. Perhaps this instance
should run in an unrestricted Lua?

The threat model which the Lua security measures are responding to is a bit
murky. Bug #15624 indicates that the desire is to allow users to continue to
confidently treat downloaded scenarios/rulesets as "simple data", without any
risk that embedded scripts can have any nasty effects beyond the game
environment they're running in (such as disclosing or overwriting user data
outside Freeciv). Now we have freeciv-modpack, that assurance should probably
extend to anything a user downloads with it.

It seems fairly clear that that threat model shouldn't apply to database.lua,
because that's essentially part of the server. So it's tempting to remove the
restrictions for the auth instance. (Perhaps that would also mollify Michal
per bug #19006?)


database.lua is loaded from the data path, which defaults to:


and can be overridden by environment variables FREECIV_DATA_PATH and
FREECIV_PATH. Thus, there is plenty of scope for an attacker to override the
standard database.lua by tricking a user into running the server from a chosen
directory, or (I think) by tricking them into downloading a dodgy modpack via

Even with things as they stand, such an attacker would be able to impersonate
other Freeciv server users, or possibly leak their credentials via side
channels. If we remove the Lua restrictions for database.lua, they could do
much more.

Looking at the contents of data/, I think database.lua is probably the first
file in there with this sort of security property. Other "code"-y files
include game scripts (handled by existing Lua security) and .serv files (only
limited potential for mischief -- "save ~/.bashrc").

So, even if I find another solution for my os.time() issue (such as
whitelisting bits of os.*), we still have a problem. What should we do about
* Invent a new category of "data" file, with database.lua as the only current
member, loaded from a much more restrictive default path that only includes
the installation path (cf patch #2827)?
** How will a non-root server operator override it on a machine where Freeciv
is installed system-wide? Is an environment variable acceptable? That would
still be sufficient guard against the dodgy-modpack / chosen-directory

If we do mitigate the path problem, would there be any other issue with
relaxing the restrictions on database.lua?


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to