LÖVE

nevon wrote:

Taehl wrote:

miko wrote:So if you need to block it, just do it in your game, but please do not do it for the whole platform.

... That makes no sense. How is it any safer to politely ask an attacker to disable it?

Isn't the best solution to have the user not be an idiot and only run applications they trust? I really see it as a hindrance to throw in a bunch of artificial limitations that may prevent some "attacks" (though the attacker can just use another method), while definitely preventing lovers from doing legitimate, cool stuff.

Exactly. As tentus said, a malicious hacker could get around sandboxing techniques.

nevon wrote:

Taehl wrote:

miko wrote:So if you need to block it, just do it in your game, but please do not do it for the whole platform.

... That makes no sense. How is it any safer to politely ask an attacker to disable it?

Isn't the best solution to have the user not be an idiot and only run applications they trust? I really see it as a hindrance to throw in a bunch of artificial limitations that may prevent some "attacks" (though the attacker can just use another method), while definitely preventing lovers from doing legitimate, cool stuff.

+1

It's not like löve is the only program in the world to have this ability. Restricting a feature simply because it has a remote chance of being abused is not the right way to go about things. If someone had malicious intent, löve probably would not be very high on their list of tools to use, anyway.

slime wrote:It's not like löve is the only program in the world to have this ability. Restricting a feature simply because it has a remote chance of being abused is not the right way to go about things. If someone had malicious intent, löve probably would not be very high on their list of tools to use, anyway.

This changes for browser plug-ins. It has been shown that such a plug-in is very possible, and then it becomes a very real security risk. I for one would love LÖVE in the browser, thus my efforts *ahem* for SELÖVE.

And while perfect safety doesn't exist, that doesn't mean that we should make things very easy for attackers. In fact, malware has knowingly been distributed on this very forum in the past. Almost no-one knows about this.

I don't think anyone is debating whether it's a good idea to make things hard for malicious attackers. What isn't a good idea is restricting legitimate features for all of us based on that fear. If someone feels the need to use SELÖVE, that's fine, but don't make the rest of us suffer.

Robin wrote:In fact, malware has knowingly been distributed on this very forum in the past. Almost no-one knows about this.

And that "malware" was made completely without the use of io.popen, iirc.

Also, I noticed.

What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.

Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.

If we use the above technique, could we also allow saving and loading OUTSIDE of the appdata directory as I have suggested before?

Taehl wrote:What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.

Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.

How about this: make a sandboxed config option.

• Sandboxed = true (default) => io functions are not available, and love.filesystem only works on the usual places. Just like it works now.
• Sandboxed = false => io functions are available, but LÖVE displays a dialog ("This love program is requesting access to your filesystem. Do you authorize it? (yes/no)") at the beginning. If the user presses no, the program ends.

kikito wrote:

Taehl wrote:What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.

Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.

How about this: make a sandboxed config option.

• Sandboxed = true (default) => io functions are not available, and love.filesystem only works on the usual places. Just like it works now.
• Sandboxed = false => io functions are available, but LÖVE displays a dialog ("This love program is requesting access to your filesystem. Do you authorize it? (yes/no)") at the beginning. If the user presses no, the program ends.

I like this, but could I make three suggestions?
* First, make it so this only needs to be asked once per game. Getting a popup every time you want to run something would be a serious turn off.
* Second, let the game author justify themselves in the dialog. A 100-character string that could be set by the programmer to say why they want these abilities, shown right after the default Love "This program is requesting access to ...".
* Three, don't auto-close the program. Let it try to run anyhow: maybe users don't care if they can save screenshots or pull up the help website. A smart programmer could probably keep everything dependent on these functions relatively optional.

nevon wrote:And that "malware" was made completely without the use of io.popen, iirc.

Yeah, that just shows how leaky LÖVE is.

nevon wrote:Also, I noticed.

I know you did.

Taehl wrote:What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.

I don't see that happening, at least not with the current dev team (or any dev team). Also: this would probably be really annoying to use, both for the gamer and the lover, and we'll need proper sandboxing if we want it to work. (So the debug library is right out, among others.)

Taehl wrote:Until someone makes a .love file malware scanner,

I think the only way to find that out (thanks to Turing-completeness), is to run it in a sandboxed environment.

Taehl wrote:I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.

Good point.

Also, there is another argument for sandboxing which has been neglected: portability. All this fuzzing with the system outside of LÖVE makes it harder to port. Wouldn't it be great if a .love ran on one platform, it would run on every platform without a doubt? (With the exception of obviously handicapped targets, see nlove).