Re: Lua [in]security and the distributors

[William Ahern <william@...>]

On Fri, Aug 29, 2014 at 11:01:11AM +0200, Axel Kittenberger wrote:
> > [1] Hackers don't appear to have much trouble breaking out of
> hardware-level
> > virtual machines like VMWare, KVM, or Xen; or meticulously designed
> > environments like the Java JVM. So you can't judge a sandbox merely by
> what
> > it theoretically limits. You 1) have to do so by _how_ it limits
> > privileges--e.g. how complex the logic is and how easy it is to debug.
> 
> I disagree. In that case running Javascript from the internet would be a
> terrible idea or any multi user unix system. Yes, there has been a long
> history of exploits, but that doesn't mean that any try of caging is futile
> from start.

I wasn't arguing that those things were worthless from a security
perspective. Yes, they're all manifestly futile in the face of someone with
limitless resources. But that's beside the point. I was only pointing that
out to shift the context of what "security" means.

I was simply arguing that a pure Lua sandbox isn't necessarily less secure
than those things, and in some contexts more secure. Although a Lua sandbox
doesn't work at the hardware level, the Lua VM is likely to have fewer bugs
which are exploitable from the sandbox by dint of Lua having such a small
and relatively simple VM with shared interfaces at both the script and C
language level, making them well tested in corner cases. So even in an
apples-to-oranges comparison a Lua sandbox stands up quite well. (Excluding
all the third-party C modules out there which unintentionally permit
scribbling random memory. For example, luaposix fcntl accepts arbitrary
cmds. For cmds it doesn't know about it will pass the third argument as an
integer. But if the cmd was expecting an address, you have just allowed a
script to write to arbitrary memory.)

I always try to run my daemons in a chroot environment. And I keep sensitive
systems on physically separate hardware. A kind of a defense-in-depth,
although that term is overused and a little misleading, leading to all kinds
of suspect convolutions.

> About the issue itself, I don't get it. Thats exactly why we have major
> and minor releases. If there is a critical bug fix or a list of smaller
> patches has been accumulated to a major release thats still in use, you do
> a minor release for it, in case of a critical bug, as soon as feasible.
> Upgrading a minor realese should never break something, so its okay for
> distros to do that security fixes for already released systems. For the
> next major release they can take on the next system release of their
> disto. End of story. (?)

Two suggestions

1) PUC Lua could have a lua-announce (lua-a) list which vendors could
subscribe to for announcements, including security announcements. This is
even better than having a big warning on the front page because it doesn't
require polling.

2) Debian already manages minor versions of various packages. Maybe an
external Lua tree could be maintained and shared by multiple distributors
which includes security fixes and dynamic library support. And for Linux, a
libtoolized build. Maybe off-list we can locate and coordinate with the
package maintainers of various Linux and BSD distros. I'd be happy to help.
I already help package and maintain Lua for the firmware at my company,
Barracuda Networks.