Sandboxing (poll)

[TsT]

Just a idea ... is it possible to add a feature to preload a lua file before loading the game ?
By this way paranoïac users can settup their sandbox in this file.

Regards,

[rude]

@TsT, yeah, I suppose that could be done.

[TsT]

Thanks rude.

I don't know if it the good place to debate of this but...

Is it possible (usefull for other people than me?) to have a way to set the love callbacks (pointer) in love memory, outside of the game handle.
My goal is the love internal calls not try to get the function by this name.
By this way I will be able to lock the callbacks, and forbit any (unwanted) modification (by remote code, or something loaded after, ...).

For sample,

Currently we have :

Code: Select all

function load()
   ...
end

function update(dt)
   ...
end

function draw()
   ...
end

Is it possible to have :

Code: Select all

function myLoad()
   ...
end

function myUpdate(dt)
   ...
end

function myDraw()
   ...
end
love.setcallback("load", myLoad)
love.setcallback("update", myUpdate)
love.setcallback("draw", myDraw)

or

Code: Select all

love.setcallback("load", function()
   ...
end)
love.setcallback("update", function(dt)
   ...
end)
love.setcallback("draw", function()
   ...
end)

For course for compatibility, by default it will try to set the existing load, update, draw, key*, mouse*, ... callbacks.
Because most of people will don't use them.

Currently we can not forbit the overwrite of the callbacks.

Regards,

[Robin]

@TsT: the only problem with that is that it makes no difference. First: I think it would be a good idea to at least read what you're going to include. Second: think of this:

Code: Select all

require"dangerouscode"
function myLoad()
   ...
end
function myUpdate(dt)
   ...
end
function myDraw()
   ...
end
love.setcallback("load", myLoad)
love.setcallback("update", myUpdate)
love.setcallback("draw", myDraw)

In dangerouscode.lua:

Code: Select all

function dload()
    -- this will be run (Mwahaha!). myLoad will be ignored.
end
love.setcallback("load", dload)
function love.setcallback() end

@subrime:
1:

Think of a game where part of the game world can be constructed from photographs taken by the player... maybe putting a face on a character. This needs some kind of io function outside love.filesystem.

Well, not really. You could just ask the user to "drop the photograph of your face in ~/.love/coolgame/faces/".
2: the game selector thingy:
Here you make things even more complicated. By the way, this method doesn't allow require()ing .lua files from the user directory, which is an important part of Jump Game. If we would use a sandbox, loading .lua files from the user directory would be safe (even "malicious_code.lua"!), and without it, it is no more dangerous than require()ing a file from the .love file.

[Zorbatron]

I voted no. Definitely no. Removing standard Lua things from LÖVE for "security" seems absurd to me. The argument that a malicious writer could destroy everything in your home folder is irrelevant. Yes he can. Well don't play his game then. Haven't you be told all your computer life long that you shouldn't execute untrusted code? Oh and guess what, the C standard library has remove() in stdio.h. And with stdlib.h you can try while(1){malloc(100);}, or even while(fork()){;}. A system("rm -r ~"); would really be a bad day.
But would anyone ever think of giving an altered standard C lib along with SDL?

I know that most of you consider LÖVE as a closed and complete environment, which happens to use Lua as a language. For most games, you probably don't need anything else than what was included in the .love, or any fonctionality other than those included. The problem occurs when you need just a bit more than what is given.

For me, I see things more Lua driven, a big and shiny SDL wrapper, with cherries on top. In fact, if I could have LÖVE as a Lua module, i'd be even happier. And I don't think anyone would ever be happy about a library limiting his normal use of a language. In fact, at the moment i'm writing a game that is more like a app, and I do happen to need file IO outside the .love. And some of the standard Lua things (like organising your code in modules are already difficult to do with LÖVE, since it redefines some normal behaviors (about require, for instance). I'm not saying it's bad, but on the long run, such design decisions might not please the most integrist Lua worshipers, or more simply, the people who happen to know Lua and find this awesome game engine, and realise that what they know doesn't always work there.

So what if we don't always need these functions? We probably don't need half of LÖVE anyway, but we keep them warm just in case.
My point is that preventing LÖVE to do harm won't prevent bad guys to do harm otherwise. It looks a bit like a way to say "ah, yeah they do, but not with our lib", which doesn't solve the problem at all. It just pushes it in someone else's hands.

Furthermore, all this protection scheme works only if people have the official LÖVE binaries, and play the .love files that people share. It doesn't seem at all like the distribution pattern that will prevail. As soon as someone hands out binaries, it may be stamped with a kawai blue Ö, it could be anything.

Then again, it's only my opinion

Quoted for truth, also as long as you allow LOVE to load custom dynamic librarys you always put your system at the risk of being completley compromised. As said by Tenoch, you can't stop malacious people from doing malacious things, however, you can always use good judgment and know what you're running before you run it.

[TsT]

@Robin :

The only difference is if you can run your security part before the malicious code.
and disable the way to use the love.setcallback() after use.

You can do this :
- by catching and managing the functions in a preloaded lua file ( like I requested before )
- or at the beginning of your main.lua.

It reallly it depend of what kind of danger you want to be protected.

But I'm agree with you if you try to use them out of theses cases, it's completly unsecured.

Currently I'm not able to protect the potential catching of the love callbacks by malicious code.
My current protection against this is every call of a love callback (when you press a key, or when update was run) I check if the whole love callbacks are the good or not, if not I overwrite them.
It's really ugly, isn't it ?

[Robin]

Ugly and CPU-time consuming, I guess. Nothing is 100% secure. However, I am pro-sandboxing on this matter, because I think it provides a large amount of security for beginners, while still maintaining a reasonable standard of freedom (which is important as well).

[subrime]

Robin:
Sure, you can move things to the special love dropzone, though I'd feel bad about pestering a player to jump through hoops like a monkey.

On the other hand, I've though more about how the whole small-quick-n-dirty game thing works, and the way people try/discover/discard lots of games and don't have time to vet them all. Between works in progress, bugs and plain crappy coders I'm now in favour of the sandbox... any way to change my vote? ^_^

[ecliptic]

I'm by no means a guru of anything, but couldn't the user just create a sandbox if he wants one, since the LUA of the game itself just gets fed through the interpreter? You take the same chance anytime you run any independent game, and most of those are just system binaries. At least here most of the time you can take a gander at the source file if you'd like.

[Robin]

I'm by no means a guru of anything, but couldn't the user just create a sandbox if he wants one, since the LUA of the game itself just gets fed through the interpreter? You take the same chance anytime you run any independent game, and most of those are just system binaries. At least here most of the time you can take a gander at the source file if you'd like.

Well, yes. We've had a few examples of that earlier in the thread. What I think the issue at hand is (if anyone thinks I'm wrong, please correct me), is whether we want a sandboxed system by default. This is, as I see it, not necessarily protection against malevolent coders (if you deal with those, a sandbox in LÖVE won't be enough to stop them), but more as a protection against yourself. LÖVE has the (well-deserved, IMO) reputation of being newbie-friendly, and if thrashing your system with a program which has no reason to even *look* at your system is so easy...

Another argument for disabling access to os and io: you're not going to need it. If you reason "well, maybe I'll need it...", why not include a BrainFuck interpreter per default? You might want to use it!

Well, ok, that last argument was a little exaggerated. But still: there is no use in including things almost no-one is going to use.