disallow interaction with "outside world"

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

disallow interaction with "outside world"

Nathan Hüsken
Dear Lua community,

I am completely new to lua (not to programming) and also to this
community, so hello everyone :-).

I am considering to use Lua as a scripting language for scripts to which
I have special requirements.
The requirements are because the scripts deal with sensitive data. At
the same time they can be written by third party people. So the danger
of someone writing a "virus" in this scripts and sneaking the data out
(outside of the lua environment) in some way that would give them access
to it must not be possible.

On the other hand, the scripts are loose on other requirements. They do
not need to interact with the outside of the scripting environment very
much. The data they need can be provided through a handful of variables
(or maybe some other mechanism in lua I do not know yet :-) ). All
interactions and outputs happen by 2-3 functions.

So my Idea: simple do not load a handful of libraries when starting the
lua interpreter (I am guessing "io" and "os") and by this I guarantee
that no data can go out except by the functions provided by me.

Now, is this possible? Can I be sure that this way that it is impossible
to "sneak" data out?

Thanks - even if you can not help - for reading through this long post :-).

Best,
Nathan


Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Ignacio Burgueño-2

On Wed, Jul 1, 2015 at 4:27 PM, Nathan Hüsken <[hidden email]> wrote:
Dear Lua community,

I am completely new to lua (not to programming) and also to this
community, so hello everyone :-).

Welcome, Nathan.
Surely someone more versed on sandboxes will pop soon, but in the meantime, you can search the archives of the mailing list for "sandboxing", because that is an issue that gets regularly discussed.
You'll find some food for thought there.



Regards,
Ignacio

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Nathan Hüsken
On 01.07.2015 21:37, Ignacio Burgueño wrote:

> On Wed, Jul 1, 2015 at 4:27 PM, Nathan Hüsken <[hidden email]>
> wrote:
>
>> Dear Lua community,
>>
>> I am completely new to lua (not to programming) and also to this
>> community, so hello everyone :-).
>>
>
> Welcome, Nathan.
> Surely someone more versed on sandboxes will pop soon, but in the meantime,
> you can search the archives of the mailing list for "sandboxing", because
> that is an issue that gets regularly discussed.

Ok, cool. That is exactly what I am looking for!
I might also be targeting the browser. Does sandboxing also work with an
javascript interpreter like moonshine? I am wondering because as far as
I can see the way a script is loaded is different.

Thanks!
Nathan

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Dirk Laurie-2
2015-07-01 22:00 GMT+02:00 Nathan Hüsken <[hidden email]>:

> I might also be targeting the browser. Does sandboxing also work with an
> javascript interpreter like moonshine? I am wondering because as far as
> I can see the way a script is loaded is different.

Enthusiasm for Javascript is not prevalent on this list.

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Nagaev Boris
In reply to this post by Nathan Hüsken
On Wed, Jul 1, 2015 at 8:00 PM, Nathan Hüsken <[hidden email]> wrote:

> On 01.07.2015 21:37, Ignacio Burgueño wrote:
>> On Wed, Jul 1, 2015 at 4:27 PM, Nathan Hüsken <[hidden email]>
>> wrote:
>>
>>> Dear Lua community,
>>>
>>> I am completely new to lua (not to programming) and also to this
>>> community, so hello everyone :-).
>>>
>>
>> Welcome, Nathan.
>> Surely someone more versed on sandboxes will pop soon, but in the meantime,
>> you can search the archives of the mailing list for "sandboxing", because
>> that is an issue that gets regularly discussed.
>
> Ok, cool. That is exactly what I am looking for!
> I might also be targeting the browser. Does sandboxing also work with an
> javascript interpreter like moonshine? I am wondering because as far as
> I can see the way a script is loaded is different.
>
> Thanks!
> Nathan
>

(Unrelated) You can find several Lua implementations in JavaScript and
other cool Lua software [1].

With sandboxing, you can start from [2]. Most difficult things are
isolating 'string' metatable (otherwise its members are available
through any string variable) and prevention of DoS attacks (like
`while true do end`, which can bypass `debug.sethook` on some Lua
implementations).

My own sandbox implementation [3]. In my implementation, 'string'
metatable is isolated at the cost of side effect: when sandboxed code
is called, metatable of all strings is changed. It can break
non-sandboxed code operating with strings called from sandboxed code.
Maybe this can be fixed by providing __index metamethod to that
metatable of 'string' so that 'string' behaves like normal 'string' in
non-sandboxed code called from sandboxed code. This information can be
provided by debug.getinfo. Not implemented yet!


[1] http://getawesomeness.com/get/lua
[2] http://lua-users.org/wiki/SandBoxes
[3] https://github.com/starius/config/blob/master/bin/sandbox.lua


--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Rena
On Thu, Jul 2, 2015 at 3:16 AM, Nagaev Boris <[hidden email]> wrote:

> On Wed, Jul 1, 2015 at 8:00 PM, Nathan Hüsken <[hidden email]> wrote:
>> On 01.07.2015 21:37, Ignacio Burgueño wrote:
>>> On Wed, Jul 1, 2015 at 4:27 PM, Nathan Hüsken <[hidden email]>
>>> wrote:
>>>
>>>> Dear Lua community,
>>>>
>>>> I am completely new to lua (not to programming) and also to this
>>>> community, so hello everyone :-).
>>>>
>>>
>>> Welcome, Nathan.
>>> Surely someone more versed on sandboxes will pop soon, but in the meantime,
>>> you can search the archives of the mailing list for "sandboxing", because
>>> that is an issue that gets regularly discussed.
>>
>> Ok, cool. That is exactly what I am looking for!
>> I might also be targeting the browser. Does sandboxing also work with an
>> javascript interpreter like moonshine? I am wondering because as far as
>> I can see the way a script is loaded is different.
>>
>> Thanks!
>> Nathan
>>
>
> (Unrelated) You can find several Lua implementations in JavaScript and
> other cool Lua software [1].
>
> With sandboxing, you can start from [2]. Most difficult things are
> isolating 'string' metatable (otherwise its members are available
> through any string variable) and prevention of DoS attacks (like
> `while true do end`, which can bypass `debug.sethook` on some Lua
> implementations).
>
> My own sandbox implementation [3]. In my implementation, 'string'
> metatable is isolated at the cost of side effect: when sandboxed code
> is called, metatable of all strings is changed. It can break
> non-sandboxed code operating with strings called from sandboxed code.
> Maybe this can be fixed by providing __index metamethod to that
> metatable of 'string' so that 'string' behaves like normal 'string' in
> non-sandboxed code called from sandboxed code. This information can be
> provided by debug.getinfo. Not implemented yet!
>
>
> [1] http://getawesomeness.com/get/lua
> [2] http://lua-users.org/wiki/SandBoxes
> [3] https://github.com/starius/config/blob/master/bin/sandbox.lua
>
>
> --
>
>
> Best regards,
> Boris Nagaev
>

I'd be surprised if "while true do end" can break debug hooks, since
it's not making any C calls. Any time you make a C function available
though (such as string.rep) you have to watch out that the user can't
abuse it to overwhelm your app, e.g. with string.rep("a", 99999999) or
("a"):rep(9999):rep(9999):rep(9999):rep(9999)...

--
Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Etiene Dalcol
In reply to this post by Dirk Laurie-2


2015-07-02 8:17 GMT+02:00 Dirk Laurie <[hidden email]>:
2015-07-01 22:00 GMT+02:00 Nathan Hüsken <[hidden email]>:

> I might also be targeting the browser. Does sandboxing also work with an
> javascript interpreter like moonshine? I am wondering because as far as
> I can see the way a script is loaded is different.

Enthusiasm for Javascript is not prevalent on this list.


Not so fast! Moonshine looks pretty cool and I can't wait to test it out. Plus, being able to talk to JavaScript is the big first step into not using it anymore ;)
--
Etiene Dalcol

Software Engineering student at ENSTA Bretagne and PUC-Rio
Sailor Developer http://sailorproject.org
Lua Ladies Founder 
http://lualadies.org

Mobile: <a href="tel:%2B33%206%2046%2083%2093%2083" value="+33646839383" target="_blank">+33 6 46 83 93 83
Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Nagaev Boris
In reply to this post by Rena
>>
>> With sandboxing, you can start from [2]. Most difficult things are
>> isolating 'string' metatable (otherwise its members are available
>> through any string variable) and prevention of DoS attacks (like
>> `while true do end`, which can bypass `debug.sethook` on some Lua
>> implementations).
>>
>
> I'd be surprised if "while true do end" can break debug hooks,

Please try this code under Lua and LuaJIT:

$ cat dos.lua
debug.sethook(function()
    print 'hook'
end, "", 1e3)
while true do end

$ lua dos.lua
hook
hook
hook
...

^C
$ luajit dos.lua
<prints nothing>

> since
> it's not making any C calls. Any time you make a C function available
> though (such as string.rep) you have to watch out that the user can't
> abuse it to overwhelm your app, e.g. with string.rep("a", 99999999) or
> ("a"):rep(9999):rep(9999):rep(9999):rep(9999)...

This is another problem...

--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Roberto Ierusalimschy
In reply to this post by Rena
> I'd be surprised if "while true do end" can break debug hooks, since
> it's not making any C calls. Any time you make a C function available
> though (such as string.rep) you have to watch out that the user can't
> abuse it to overwhelm your app, e.g. with string.rep("a", 99999999) or
> ("a"):rep(9999):rep(9999):rep(9999):rep(9999)...

You do not even need the string library for that. You can write
something like this:

s = "01234567890123456789012345678901234567890123456789"
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s

No loops, no libraries, no large constants, few instructions...
(It is even portable; it should break many languages :-)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Roberto Ierusalimschy
In reply to this post by Etiene Dalcol
> Not so fast! Moonshine looks pretty cool and I can't wait to test it out.
> Plus, being able to talk to JavaScript is the big first step into not using
> it anymore ;)

Embrace, extend, and extinguish :-)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Aapo Talvensaari
In reply to this post by Etiene Dalcol
On 2 July 2015 at 12:04, Etiene Dalcol <[hidden email]> wrote:
> Not so fast! Moonshine looks pretty cool and I can't wait to test it out.
> Plus, being able to talk to JavaScript is the big first step into not using it anymore ;)

One of the even bigger steps is the upcoming WebAssembly binary format:

That's somethingthe Lua and the community around it could look forward (say in WebAssembly support in luac — Makes sense?).

Regards
Aapo
Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

steve donovan
On Thu, Jul 2, 2015 at 4:11 PM, Aapo Talvensaari
<[hidden email]> wrote:
> That's somethingthe Lua and the community around it could look forward (say
> in WebAssembly support in luac — Makes sense?).

Totally!  But the elephant in the room is the DOM....

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Luiz Henrique de Figueiredo
In reply to this post by Aapo Talvensaari
> One of the even bigger steps is the upcoming WebAssembly binary format:
> https://github.com/WebAssembly
>
> That's somethingthe Lua and the community around it could look forward (say
> in WebAssembly support in luac ??? Makes sense?).

This is the first time I hear about WebAssembly. Is that the new Java? :-)

By support for WebAssembly in Lua, do you mean generating WebAssembly
from Lua source or converting WebAssembly to Lua source or bytecode?

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Javier Guerra Giraldez
In reply to this post by steve donovan
On Thu, Jul 2, 2015 at 9:14 AM, steve donovan <[hidden email]> wrote:
> <[hidden email]> wrote:
>> That's somethingthe Lua and the community around it could look forward (say
>> in WebAssembly support in luac — Makes sense?).
>
> Totally!  But the elephant in the room is the DOM....


fortunately, most DOM implementations have some native CSS selectors,
making jQuery-like access not too complex, and frankly mandatory for
any javascript-alternative. (i.e. it's one of the few basic built in
functions in Dart)


--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Etiene Dalcol
In reply to this post by Aapo Talvensaari


2015-07-02 16:11 GMT+02:00 Aapo Talvensaari <[hidden email]>:
On 2 July 2015 at 12:04, Etiene Dalcol <[hidden email]> wrote:
> Not so fast! Moonshine looks pretty cool and I can't wait to test it out.
> Plus, being able to talk to JavaScript is the big first step into not using it anymore ;)

One of the even bigger steps is the upcoming WebAssembly binary format:

That's somethingthe Lua and the community around it could look forward (say in WebAssembly support in luac — Makes sense?).



I agree this would be amazing. 



--
Etiene Dalcol

Software Engineering student at ENSTA Bretagne and PUC-Rio
Sailor Developer http://sailorproject.org
Lua Ladies Founder 
http://lualadies.org

Mobile: +33 6 46 83 93 83
Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Javier Guerra Giraldez
In reply to this post by Luiz Henrique de Figueiredo
On Thu, Jul 2, 2015 at 9:18 AM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> One of the even bigger steps is the upcoming WebAssembly binary format:
>> https://github.com/WebAssembly
>>
>> That's somethingthe Lua and the community around it could look forward (say
>> in WebAssembly support in luac ??? Makes sense?).
>
> This is the first time I hear about WebAssembly. Is that the new Java? :-)

it's a common bytecode for javascript.  it seems everybody is on
board, making is quite likely to acutually happen (apple, mozilla,
google, microsoft, really everybody)

think emscriptem without javascript.  the first demos are C compilers.


> By support for WebAssembly in Lua, do you mean generating WebAssembly
> from Lua source or converting WebAssembly to Lua source or bytecode?


the easiest thing would be to just compile current Lua C sources to
WA, as was done so long ago with emscriptiem.  that alone, would be
great!  then, modifying the Lua compiler to emit WA instead of Lua
bytecode would make it even faster and more 'native'.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Fabio Mascarenhas
On Thu, Jul 2, 2015 at 11:23 AM, Javier Guerra Giraldez <[hidden email]> wrote:

> By support for WebAssembly in Lua, do you mean generating WebAssembly
> from Lua source or converting WebAssembly to Lua source or bytecode?


the easiest thing would be to just compile current Lua C sources to
WA, as was done so long ago with emscriptiem.  that alone, would be
great!  then, modifying the Lua compiler to emit WA instead of Lua
bytecode would make it even faster and more 'native'.


Compiling the Lua VM to WA should yield performance on par with the C implementation, so I think will be good enough for most uses. Lua's small size will make the VM a small download. They are planning to add support for dynamic linking with dlopen [1], so it will even be possible to require C modules instead of statically linking them with the VM (or call other WA libraries from Lua).

Right now WA is too low-level for efficiently compiling Lua code to it, and there is no JIT compilation yet. I also suspect it is too high-level to gain anything by writing the interpreter loop in WA by hand, as LuaJIT does. But support for JIT compilers will come, and Brendan Eich specifically mentioned LuaJIT in his original announcement [2].
 
--
Javier



--
Fabio Mascarenhas

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Jay Carlson
In reply to this post by Roberto Ierusalimschy


On Jul 2, 2015 9:34 AM, "Roberto Ierusalimschy" <[hidden email]> wrote:
>
> > I'd be surprised if "while true do end" can break debug hooks, since
> > it's not making any C calls. Any time you make a C function available
> > though (such as string.rep) you have to watch out that the user can't
> > abuse it to overwhelm your app, e.g. with string.rep("a", 99999999) or
> > ("a"):rep(9999):rep(9999):rep(9999):rep(9999)...
>
> You do not even need the string library for that. You can write
> something like this:
>
> s = "01234567890123456789012345678901234567890123456789"
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
> s = s .. s .. s .. s .. s .. s .. s .. s .. s .. s
>
> No loops, no libraries, no large constants, few instructions...
> (It is even portable; it should break many languages :-)

It doesn't break MOO, since the interpreter sets an alarm(3) at the start/resume of each task. Running out of seconds is an uncatchable exception thrown at the beginning of the next bytecode. MOO runs in environments where swapping will begin before malloc returns NULL.

Because the scheduler is vindictive, tasks which eat a whole second will not run again until everybody else gets a full second, or until the queue is idle.

What protection from long bytecodes creates instead is a lack of atomicity. Because out-of-seconds is uncatchable, there is no way to unwind critical sections. What was proposed was an enhanced try-finally which reserves a specified number of bytecode ticks and seconds for the "finally" arm.

Note that exponential behavior in something like a regexp builtin function needs to be dealt with separately, potentially by mimicking the VM.

Jay

Reply | Threaded
Open this post in threaded view
|

Re: disallow interaction with "outside world"

Vaughan McAlley-2
In reply to this post by Etiene Dalcol
On 2 July 2015 at 19:04, Etiene Dalcol <[hidden email]> wrote:

> Not so fast! Moonshine looks pretty cool and I can't wait to test it out. Plus, being able to talk to JavaScript is the big first step into not using it anymore ;)

That’s basically what I do with any language: learn enough of it to
make a Lua call…

Vaughan