Sandboxing (poll)

[Tenoch]

Having two sets of binaries seems a bit overkill, and would probably confuse beginning LÖVE users. I can already see people popping in on the IRC asking "So, what's this sandbox version, which one should I take, what is better for me, is LÖVE so dangerous that we need a protection? oh my gods, are the sea otters hacking my computer?"



I'd opt for one binary with an option.

[Robin]

I'd opt for one binary with an option.

As in a command line switch:

Code: Select all

love --unsandbox game.love
love --danger game.love
love --iexplorer game.love
love --sudo game.love

?

[Tenoch]

Well no. Since most games are going to be distributed with the .love merged in the executable (or at least mine...), and that sandboxing is a decision for the game developer (not the game player) I was thinking more of something from the Lua code like:

Code: Select all

function love.load()
    love.disableSandbox()
end

[Robin]

Code: Select all

function love.load()
    love.disableSandbox()
end

Hmm... I thought that was suggested before, but I can't find anywhere.

[bartbes]

I thought that too, and I know rude commented on it, other thread or IRC? Anyway, it's been suggested, and it might be a good solution..

[Zorbatron]

Well, I'm one of the people who voted against, but I see what they mean. C example, beginners might write a forkbomb by accident (is not explained here, please move on), as they don't know what it could do, extreme example, but possible. A lua example: a not too experienced programmer wants to write a love script which writes 1337 to a file (yes, kick that guy if you see him, please, he deserves nothing better). This guy is a beginning linux user and thinks it's funny to write it to bash (assuming he had root rights, and I know this story gets less probable by the letter), so he does:

Code: Select all

bash = io.open("/bin/bash", "w")
bash:write("1337")
bash:close()

A few seconds later we get a frightened scream, he did it, he has overwritten bash...

Another extreme example, but I can't think of anything that is probable and harmful at the same time.. I voted against for a reason. However, I hope you get the point.

I understand it is possible to screw something up with raw io functions however, it is also possible a meteor could fall onto your home town and completly destroy everything. That doesn't mean you should hide in your basement for the rest of your life to avoid the slight possibility.

I just don't see the point in worrying about it, the only time I have ever seen sandboxing preformed is when there is a security risk that is exploitable from a remote source (obvious example would be javascript, or anything related to clientside http). No such risk exists in this situation, the user has full control over whether or not he wants to run the game.


Overall, you have to actually try to screw something up in order to hurt yourself, honestly its like adding saftey protocols to a butter knife, sure you could hurt yourself if you stick it in your eye hard enough, or saw with all your might, but common....

btw, a 'fork bomb' is an application that creates too many threads (aka programs) and locks your system from running any more programs until it is restarted (for those who want to know).

Exampe in C/C++:

Code: Select all

#include <unistd.h>
 
int main(void)
{
  for(;;)
    fork();
  return 0;
}

[bartbes]

Yes, I don't think there should be a sandbox either, but it isn't too useful to just go around and tell people they should run a fork bomb (I might try that at school..), well, anyway, I don't think this discussion is going anywhere, we all have the same argument, but we think different about it, so... rude, wrap this up.

[Robin]

I don't think this discussion is going anywhere, we all have the same argument, but we think different about it, so... rude, wrap this up.

Agreed. All the interesting stuff has been said already. Let rude make a decision, and we'll all shut up about this and move on.

[Rad3k]

I know it's an ancient thread, but I think I've got an idea that has not yet been mentioned.

If we could use LÖVE as Lua module, then the standard LÖVE executable could be sandboxed (possibly unbreakably). If people wanted to make an app, or something that requires more than the sandbox permits, they would just use LÖVE as a module (and distribute their works as Lua programs - people who run Lua programs wouldn't have it any more dangerous than usual). This way both sides would be happy - people who download and run random .love games would be safer from accidental (or not*) harm, and those who want to use LÖVE with full power of Lua would be able to.

What do you think?


* Just imagine that someone posts a malicious .love in "Projects and Demos". How many of you examine all the code from the demos before running them?

[bartbes]

This has, to some degree, been added to 0.8.0, games now have a 'release' mode, and if that is set, and it's a fused game, it can do more things, at the moment, that's really only no longer having the save dir under love's dir.

As for the malicious code, some research has been done quite some time ago, and it seems like you can get away with a lot without people noticing.