Jail/Sandbox

[hdon]

Hi all, new lover here. My question is simple:

Can LOVE run untrusted code safely? Is it intended to work as a sandbox/jail around the code it runs? It kinda has that vibe, and that would be a great feature, but honestly I'm pretty much just making this up and hoping it's true.

The next step for me would be adding routines in LOVE to allow one LOVE app to dispatch to another LOVE app via URL. Then LOVE games could link to each other, and that would be awesome.

[bartbes]

Currently you can still access the basic lua functions, but rude (the most active developer, sorry mike) has been talking for AGES about disabling that (you should see the roadmap ), so it probably will be all 'sandboxed' next version.

[whitebear]

Did I understand right? You want Löve to disable all "unsafe" functions? (like file writing)
Personaly I think you should understand that if you are into something like Löve then you are asumedly a developer (or interested in coding). There for there is mutual trust between us and those who use it wrong pay dearly for the rest of their internet life (well most likely real life aswell).

Just keep it that you only download things from trusted sources and don't download other than love/zip files. Both of those can be virus checked safely.

[rude]

What bartbes said.

We've been keeping this in mind all along, and all read/writes through love.filesystem are safe. However, the standard io and os are still availablein the current version. The plan is to disable those libraries by default and add a command line option for running "unsafe" mode.

[whitebear]

Well only big problems come when people start working on scripts that use internet. But then again, everything is customer's responsibility.

[mike]

This is all speculation based on my experiences with making LÖVE, but here goes:

In the original idea we were going to be making an all-encompassing system with it's own GUI for browsing games, GUI system, A* navigation algorithm, map creation kit, kittens and giggles, etc, but that soon became unfeasable because the backbones of the system weren't implemented yet (image handling, sound, text, etc). As we worked on it the focus shifted from providing everything but the kitchen sink to more of making a good system for letting people provide their own features. We were going to have a built-in GUI system (see another thread somewhere on this forum), but people started making their own libraries so it quickly became apparent that building a good TOOL for people to base their work around was better than making it all ourselves (takes less time too).

However, keeping all the functions within LÖVE and removing all the general lua features would allow us more security, the ability to code specific features into the functions (file handling that automagically read a zip file, etc) and it would also mean that people didn't need to code "outside" of LÖVE. Personally I would think it ugly if a game used 50% love functions and 50% random lua crap. We can and will implement all that you need to build a game, making LÖVE the greatest thing since sliced bread with spam.

PS: rude, if I tread out of line please correct me. I am simply speculating...

[osuf oboys]

I believe several games will want to have access to more data than whatever they come packed with and their application data folders. At the very least, they need access to other LÖVE applications' data (read and write) and all the usual folders (home folder, Documents and Settings, etc.). Perhaps you could simply provide read access to everywhere initially, and write access after an internal function has been called. This internal function could then halt the game and query the user whether or not to allow this.

[hdon]

it probably will be all 'sandboxed' next version.

We've been keeping this in mind all along... However, the standard io and os are still available in the current version.

Awesome!

But...

The plan is to disable those libraries by default and add a command line option for running "unsafe" mode.

That sounds like a good start. I have something better in mind though. (Read on..)

Did I understand right? You want Löve to disable all "unsafe" functions? (like file writing) Personaly I think you should understand that if you are into something like Löve then you are asumedly a developer (or interested in coding). There for there is mutual trust between us and those who use it wrong pay dearly for the rest of their internet life (well most likely real life aswell).

Just keep it that you only download things from trusted sources and don't download other than love/zip files. Both of those can be virus checked safely.

All good observations. I have a great deal of appreciation for the level of security and stability I enjoy when computing because I am part of the developer community. If you have any family members who are not developers, you're probably very familiar with the woes of malware, yet we never seem to have those same problems.

I feel very strongly, however, that code execution sandboxes can open the floodgates on social computing, which I think LOVE is the perfect platform for. That having been said: I do not want to "disable all 'unsafe' functions." Those are some very harsh words! There are some very sexy alternatives, though, that can provide a great deal of security and stability while providing a great deal more flexibility to accommodate developers and users.

Here's one of them:

all read/writes through love.filesystem are safe.

Provide separate "safe" APIs. Not a terrible idea. It's certainly intuitive and relatively easy to design implement. But I would prefer API proxies to this. Secure API proxies provide the same programming abstractions to hackers, but with a different implementation under the hood that can make more advanced decisions about how to actually execute API invocations. Here's a few reasons why:

• Pre-existing APIs means less work porting existing code to LOVE.
• Pre-existing APIs means more people can hack existing LOVE apps.
• Pre-existing APIs means more people can hack their own LOVE apps.
• Only giving the user the option to disable or enable access to certain APIs will most likely result in a LOVE app either not running at all, or running with fewer features.
• When users don't get all the features they want with "safe mode" enabled, they will just disable it out of impatience.
• Users can connect different units of LOVE code with different API proxies, thus providing them with different system privileges, allowing the user to give them whatever is appropriate.
• A sophisticated API proxy layer will allow a single LOVE process to run different units of code with different API proxies!

With API proxies, users can choose policies for the apps they use that can react to applications' requests for resources in a wide variety of ways. Seeing the user's filesystem can be completely cut off. A subset of the filesystem could be shown, but read-only. Some files could be writable. A fake filesystem could be made up for the app. Access to individual files, or access to networking end-points like attempting to connect to a new server on the internet, or a new server on your LAN/VPN, could all provide the user with GUI prompts which allows the user to further refine their policy for that app. It might be a good idea to initially restrict all apps to a limited amount of local storage space on your hard drive, but I'd rather get a popup dialog asking me if I want to give it more space, than simply denying the app the space.

I've had a dream for some time of a social / communal gaming platform that allows users to hack their own games and their own game content, without an arbitrary barrier between what constitutes data and what constitutes code. This is an important feature because it unconstrains developers' creativity, and because separating code and data is simply an ineffective security measure since each app's code must be responsible for policing the data it accepts, which violates the DRY principle, adds code complexity, and is more error prone and therefore less secure.

In the original idea we were going to be making an all-encompassing system with it's own GUI for browsing games, GUI system, A* navigation algorithm, map creation kit, kittens and giggles, etc, but that soon became unfeasable because the backbones of the system weren't implemented yet (image handling, sound, text, etc). As we worked on it the focus shifted from providing everything but the kitchen sink to more of making a good system for letting people provide their own features. We were going to have a built-in GUI system (see another thread somewhere on this forum), but people started making their own libraries so it quickly became apparent that building a good TOOL for people to base their work around was better than making it all ourselves (takes less time too).

I agree 100%. There would be nothing wrong, however, with LOVE endorsing a set of libraries that are conducive to a healthy LOVE community. Here are some of the features I envision as being part of a social gaming platform:

• Networking core supporting content updates, and low latency state update delivery for network gaming (both client-server and peer-to-peer.)
• Cryptographic authentication of all content and network messages.
• Graphical proxy API configuration editor.
• Popular "start menu" app featuring a content guide, social networking, forum and chat -- perhaps under the abstraction of an actual game (imagine running around a Super Mario Bros-esque type of game, alongside other players with whom you can chat, and jumping into different pipes to reach new games.)
• Easy means of allowing content providers to link to each others' work, be it either entirely new games, different levels for the same game, different servers, or even individual game elements (the latter of which is much more relevant to developers, but also relevant for people who might want their "home screen" to be something like Animal Crossing / The Sims where they can keep a collection of a bunch of crap they have found while interacting on LOVE.

With cryptographic authentication, you can choose which developers and/or code reviewers you trust your computer with, and with API proxies you can configure individual policies for those apps or the developers themselves.

I hate to bring this up, because I'm a big FOSS advocate, but you could also potentially provide a means of selling content through LOVE.

Anyhow this post is like... really long... and I'm sure tons of it is faaaar off into the future, so for now I'm going to leave it at this and see what others have to say before writing any more. I can donate some of my time to adding some of these features. If LOVE can be monetized somehow, I'd love to dedicate all of my time to a great open source platform like this one. Thanks for listening!

[bartbes]

Well only big problems come when people start working on scripts that use internet. But then again, everything is customer's responsibility.

Missed one of the biggest topics on the forums?

@hdon:
Why does it all have to be for money? I love LÖVE the way it is, as a way for hobby programmers to create the games they want to create, no money involved.
Second, I think the 'virtual meeting place' is a nice idea, but I doubt it should be part of an engine. And, most important, I don't think it's time for that yet, we should wait for the 1.0 release, which is planned just before the next big bang.

[rude]

Cool thoughts hdon.

In the short term (< v1.0) the plans will not change though, io and os will be REMOVED no matter how harsh that seems. I dislike the idea of modifying the way standard Lua libraries work (though not ruling it out 100%) , and would rather create separate "safe" libraries.

I've been wanting to create a Steam-like distribution platform for LÖVE games for some time (with both libre, free and commercial games), though I'm not going to start doing that until the engine itself stabilizes. I think that the "social" aspect of LÖVE should be implemented in a separate application. As it looks now, LÖVE itself will approach a more "library" feel than a monolithic system/framework/engine, so embedding that completely will not be feasible anyway.

We'll see how things develop.