LÖVE

EmmanuelOga wrote: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?

tentus wrote:

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.

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.

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

io.popen=disabled
io.open=disabled

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

miko wrote: 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.

tentus wrote: @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!

Robin wrote:

EmmanuelOga wrote: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.

EmmanuelOga wrote: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.