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.
Love security flaw
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
- EmmanuelOga
- Citizen
- Posts: 56
- Joined: Thu Apr 22, 2010 9:42 pm
- Location: Buenos Aires, Argentina
- Contact:
Re: Love security flaw
--------------------------------------------------------------------------------------------------------
http://EmmanuelOga.com
http://EmmanuelOga.com
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: Love security flaw
But see the principle of least privilege.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?
Help us help you: attach a .love.
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: Love security flaw
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.tentus wrote:I like this, but could I make three suggestions?kikito wrote:How about this: make a sandboxed config option.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.
- 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.
* 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.
Re: Love security flaw
May I propose something simpler?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.
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
There could be also a switch for love:
Code: Select all
love --securityfile ~/.mylovesecurity.lua program.love
My lovely code lives at GitHub: http://github.com/miko/Love2d-samples
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Love security flaw
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
- Inner party member
- Posts: 1060
- Joined: Sun Oct 31, 2010 7:56 pm
- Location: Appalachia
- Contact:
Re: Love security flaw
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.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:And then sample loverc.lua files could be distributed with love (maybe with good-looking dialog for the message).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
There could be also a switch for 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.Code: Select all
love --securityfile ~/.mylovesecurity.lua program.love
@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!
Kurosuke needs beta testers
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Love security flaw
Yeah, I'd be going for full-blown lua then, imagine the stuff you could do.. great mods!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!
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
- Citizen
- Posts: 56
- Joined: Thu Apr 22, 2010 9:42 pm
- Location: Buenos Aires, Argentina
- Contact:
Re: Love security flaw
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 wrote:But see the principle of least privilege.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?
--------------------------------------------------------------------------------------------------------
http://EmmanuelOga.com
http://EmmanuelOga.com
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: Love security flaw
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.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.
Help us help you: attach a .love.
- slime
- Solid Snayke
- Posts: 3160
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Love security flaw
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.
It's up to the OS and developers themselves to insure greater security. The tools they use are simply that, tools.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot], Google [Bot] and 2 guests