Sandboxing (poll)

[Robin]

the problem with people is as soon as you imply that it could be evil, it becomes massively evil to them

That's what I thought: many users will probably either accept anything anyway, or become paranoid. Best would be to avoid having to ask the user whether to allow the game to do potentially dangerous things.

I'm kind of thinking about making io read-only, and preferably even home only.

You mean /home on 'nix and \Documents and Settings on winxp, etc.? That would be a massive improvement already, but games can still trash your home folder.

[Tenoch]

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

[rude]

In fact, if I could have LÖVE as a Lua module, i'd be even happier.

You can!

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 doesn't matter that evul guys can do harm otherwise. I use LÖVE much more than anything else.

It might seem that I'm pro-sandboxing, but I don't really want to change Lua at all ...

[Notfonk]

I'm for the idea of warning the user when the program tries to access certain libs, like io.
I'm not very sure about the feasability of it but i view it as the only viable solution except no sandboxing

On a sidenote, how do you use löve as a module ?

[subrime]

Another problem with sandboxing is the assumption of what constitutes a game.

Just because your game ideas don't usually need to do something, doesn't mean someone else will be happy with the same restriction.

Look at all the things people have done with the net that could not have been envisioned 15 years ago... these come from the freedom to do stuff nobody thought of before, and relied on being able to do things people didn't think were necessary.

[CryoNox]

erm I don't really know what sandboxing is, even after reading it up on Wikipedia. All I know it is some security mechanism :X Anyone care to explain with an example?

[Robin]

Well, I don't know about that. AFAIK, you can still connect to the 'net. What is wrong with a game that cannot run arbitrary programs on your hard-disk, and cannot read/write to all files outside of it's own personal file system space?

Freedom is good, but I cannot see how arbitrary freedom can be good for games. If you want to run programs, you need a shell, not a game!

I've included a file which, to my knowledge, should do the same. Now tell me: does that give problems with any games?

EDIT: CryoNox: sandboxing is basically a place where something can't get out. A sort of quarantine: a program cannot do as much harm if it cannot do everything. For example: you suspect a program might be malware. You place it in a sandbox. It tries to recursively remove / (or C:\, if you're on Windows). It fails, because the sandbox denied access.

[subrime]

Another though... make a cage using love.

For people who are worried about security, there is always the option of running love inside a love sandbox. It could be built from love instead of into love... this is the standard lua approach to dealing with untrusted code.

To address the convenience factor, I would suggest putting the isolation work into some kind of "game selector", which offers a list of love games to choose from (local or online) and sets up the sandbox to run it in. This requires no modification or restriction of love itself. The selector (love app. heh!) can redefine all the os/system calls it feels necessary before passing off to the untrusted game. eg:

Code: Select all

-- fancy selection code goes here...
-- unleash the paranoia!
os.remove=restricted_remove
os.rename=restricted_rename
os.execute=restricted_execute
io.open=restricted_open
-- etc.
-- now (download and) run the selected game

[Robin]

So, a bit like my sandbox.lua. Only how would the selector (I think Löve me (or whatever I should call it) could do this) insert this into the game? Putting it in main.lua? Putting a require"sandbox" in the main file? Or should the cage be inside LÖVE, disabled by default, enabled by a command line option (like "love.exe --safe dangerous.love")?

[subrime]

Robin: re your sandbox.lua
That's kind of what I'm getting at, but totally wiping out the io table is problematic.

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.

In terms of implementing the game selector (as opposed to a command line option) you could do something like this (game selector main.lua):

Code: Select all

-- select game here
  game=select_game()
-- make things safe
  os.remove=restricted_remove
  -- and so on
-- set things up for new game
  preserve={include=love.filesystem.include,require=love.filesystem.require}
  base=get_directory(game)
  function love.filesystem.include(f) return preserve.include(base..f) end
  function love.filesystem.require(f) return preserve.require(base.f) end
-- run the game
  love.filesystem.include('main.lua') -- note this runs the game main.lua