Love security flaw

[EmmanuelOga]

Hi,

I don't think it will be worth to try to build any "security features" in löve.

To me, love is a tool to build games as much a GCC and libsdl are. Nobody would try to make GCC "secure" by removing the ability to perform system calls in a C program. The same goes with löve. There is no point in removing os.execute() or any other "dangerous" functions.

This reasoning builds in the idea that I do not expect the end user to have his own love binary to use my games (i.e. I won't be shipping .love files). When I finish my game I plan to provide binaries to the end public, that means that the public will have to trust me when they run the software. Don't we all trust our favorite game won't try to format our hard drive or steal our data while we are running it?

In the end, if any program wants to do nasty stuff, who must ensure security is the operating system.

[Robin]

This reasoning builds in the idea that I do not expect the end user to have his own love binary to use my games (i.e. I won't be shipping .love files). When I finish my game I plan to provide binaries to the end public, that means that the public will have to trust me when they run the software. Don't we all trust our favorite game won't try to format our hard drive or steal our data while we are running it?

But see the principle of least privilege.

[BlackBulletIV]

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.

Great idea. Although, what when distributing merged executables? It wouldn't look great if Love suddenly got in the way of a seemingly independent executable.

[miko]

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.

May I propose something simpler?
If love could run ~/.loverc.lua (or $USER\loverc.lua) on every invotacion (if there was any), that file could contain for example:

Code: Select all

local disabled=function(...) error("This function is disabled according to local security settings. Check your loverc.lua") end

io.popen=disabled
io.open=disabled

And then sample loverc.lua files could be distributed with love (maybe with good-looking dialog for the message).
There could be also a switch for love:

Code: Select all

love --securityfile ~/.mylovesecurity.lua program.love

Such a file could be useful for other things (setting local paths, replacing other functions, etc), and the user would be in total control of it.

[bartbes]

Yeah, I remember thinking of something similar some time ago. I don't think it was security related, but getting to run your own code before a game could be nice. It could also encourage cheating..

[tentus]

May I propose something simpler?
If love could run ~/.loverc.lua (or $USER\loverc.lua) on every invotacion (if there was any), that file could contain for example:

Code: Select all

local disabled=function(...) error("This function is disabled according to local security settings. Check your loverc.lua") end

io.popen=disabled
io.open=disabled

And then sample loverc.lua files could be distributed with love (maybe with good-looking dialog for the message).
There could be also a switch for love:

Code: Select all

love --securityfile ~/.mylovesecurity.lua program.love

Such a file could be useful for other things (setting local paths, replacing other functions, etc), and the user would be in total control of it.

That is a better solution. If someone was distributing their own exe we'd be powerless anyhow, so this is a pretty elegant answer to both sides of the debate: it's not reducing Love, while making the use of Love for malicious purposes just difficult enough to be not worth it.

@bartbes: I guess that depends on what all is available in the Love config. If it's a full lua file then you run a cheating risk, yeah, but if its just a cfg for Love itself then it's much less so.

Also, cheating in an open-source game? Never in my day!

[bartbes]

@bartbes: I guess that depends on what all is available in the Love config. If it's a full lua file then you run a cheating risk, yeah, but if its just a cfg for Love itself then it's much less so.

Also, cheating in an open-source game? Never in my day!

Yeah, I'd be going for full-blown lua then, imagine the stuff you could do.. great mods!
And the cheating was merely a joke, it's harder to write an external file to mod it for you than to just edit while reading.

[EmmanuelOga]

This reasoning builds in the idea that I do not expect the end user to have his own love binary to use my games (i.e. I won't be shipping .love files). When I finish my game I plan to provide binaries to the end public, that means that the public will have to trust me when they run the software. Don't we all trust our favorite game won't try to format our hard drive or steal our data while we are running it?

But see the principle of least privilege.

principle of least privilege: privileges is something the operating system manages, not the software. For instance, in a linux system the way to run any software in a secure way is to create a new user w/o access privileges to stuff he does not own.

[Robin]

principle of least privilege: privileges is something the operating system manages, not the software. For instance, in a linux system the way to run any software in a secure way is to create a new user w/o access privileges to stuff he does not own.

Yes, but software should act responsibly by not accepting more rights than they need. Besides, LÖVE as a framework is a system on its own, and acts like an operating system to the game.

[slime]

LÖVE is a tool to make game development easier. It's not a sandbox or modding environment like WoW's Lua API, where they're restricting access in order to prevent people from doing unintended things to their game. When we restrict access to LÖVE features from ourselves, we're just shooting ourselves in the foot because we aren't modding a game, we're making a game. If I wanted, I could compile a malicious program that uses Lua's io.popen and distribute it. What's the difference between doing that and creating a löve game that does the same thing? If you're so concerned about security shouldn't you be trying to get io.popen removed from Lua itself?

It's up to the OS and developers themselves to insure greater security. The tools they use are simply that, tools.