[0.4.12-dev] Mod security

User avatar
ShadowNinja
Member
 
Posts: 194
Joined: Tue Jan 22, 2013 22:35
GitHub: ShadowNinja
IRC: ShadowNinja
In-game: ShadowNinja

[0.4.12-dev] Mod security

by ShadowNinja » Fri Jun 05, 2015 23:04

Mod security has recently been implemented. This prevents rogue mods from doing whatever they want to your computer.
For now the feature is disabled, because it breaks a few legitimate mods (although most of them have been patched by now).
You can explicitly enable it by setting secure.enable_security = true in your minetest.conf.


What does this mean for me, the user?
As long as you update all of your mods you shouldn't have any issues. However if you're using some mods (notably IRC) you'll have to list them as trusted. Mods are trusted if they are listed in the secure.trusted_mods setting (see minetest.conf.example). Mods might not be updated in the mod store, so you might have to download the latest version from Git or the mod's download page.

Mods that have to be updated to support security:
  • IRC done. Must be listed as trusted.
  • WorldEdit done.
  • DataStorage done.
  • player_textures done but not merged (PR)

I'm a modder, will my mods break?
Probably not. I tried very hard to minimize the amount of breakage that this causes. But the following things shouldn't work:
  • Using some insecure functions like require(), os.execute(), or debug.getlocal().
  • Running compiled Lua bytecode.
  • Reading/writing to anywhere outside the world directory or your mod directory.
  • Reading/writing to anywhere in your mod directory after the init stage. (this is a limitation of the way that minetest implements mods. A workaround is to open all files that you will need at startup and use the file descriptors later. Note that you should never write in your mod directory though, only read; the mod directory is not always writable. Use the world directory if you have to save something)
  • Setting any setting with a name starting with "secure."

If you need to do one of these things you can use minetest.request_insecure_environment() (see lua_api.txt for details) to access functions that are normally inaccessible or unusable for mods. If you use this your mod will have to be listed as trusted though.
I play on my Minetest server and VanessaE's.
The best way to contact me is usually IRC (InchraNet, freenode).
 

User avatar
Wuzzy
Member
 
Posts: 2161
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: [0.4.12-dev] Mod security

by Wuzzy » Sun Jun 07, 2015 03:08

You forgot to mention that “untrusted” mods also can't (shouldn't) set any setting starting with “secure.” (according to latest dev version).

Besides: What other functions are considered “insecure”? Can you give a list? And what about “dofile”?

What about unknown mods which would break when turning mod security on? How would the player or server operator notice that the mod does not work because of a mod security violation. Will there be an error message?
 

User avatar
ShadowNinja
Member
 
Posts: 194
Joined: Tue Jan 22, 2013 22:35
GitHub: ShadowNinja
IRC: ShadowNinja
In-game: ShadowNinja

Re: [0.4.12-dev] Mod security

by ShadowNinja » Mon Jun 08, 2015 02:52

Wuzzy wrote:You forgot to mention that “untrusted” mods also can't (shouldn't) set any setting starting with “secure.”.

The list isn't meant to be exhaustive, but I've added your suggextion.

Wuzzy wrote:What other functions are considered “insecure”? Can you give a list? And what about “dofile”?

Actually, no, because there's no blacklist. It's whitelist-based for better security, so anything not on the whitelists (except for things that Minetest itself adds, such as the minetest table and some other internal things) is blocked. You can see the whitelists here though. You probably don't have to worry about it unless you're doing something that is obviously not going to be allowed though. dofile() is allowed (and I'd consider breaking that a very big problem since it's so widely used), but of course the locations you can load from are restricted and you're not allowed to load byte code.

Wuzzy wrote:What about unknown mods which would break when turning mod security on? How would the player or server operator notice that the mod does not work because of a mod security violation. Will there be an error message?

Depends on what the mod does. Currently, most functions (like os.execute()) are simply removed, so you'll see a not-too-helpful error message like "attempt to call a nil value". An exception to this is require(), which exists but always throws an error (when mod security's on and the mod isn't using a trusted environment) along the lines of "require() is disabled when mod security is on." Attempting to access files in restricted locations will throw an informative error message mentioning mod security.
I play on my Minetest server and VanessaE's.
The best way to contact me is usually IRC (InchraNet, freenode).
 

User avatar
Wuzzy
Member
 
Posts: 2161
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: [0.4.12-dev] Mod security

by Wuzzy » Mon Jun 08, 2015 13:20

Okay, thanks for your reply.
I think having some kind of Lua sandboxing is an important addition. I guess I will activate this feature as soon the next stable Minetest version gets out. It is kinda scary if all it takes is that you just have to be fooled by one rogue modder with an evil mod and all hell breaks loose.

I wonder why the security won't be activated it as default. If I see it correctly, there are actually only a few mods which would be possibly affected, of which almost all have already be edited to comply with the new mod security system. So I don't see that the argument of inconvinience actually applies.
Or are there many more mods which use the “forbidden” functions?
By the way, for my mods, I have never needed any functions which are not on the whitelist and I only ever used files in the world path, so I guess this means my mods are already compliant without moving a finger. :-)

I have seen that the Lua built-in function “setfenv” is on the whitelist. This function can overwrite environment variables, are you sure this is not a problem?
 

User avatar
ShadowNinja
Member
 
Posts: 194
Joined: Tue Jan 22, 2013 22:35
GitHub: ShadowNinja
IRC: ShadowNinja
In-game: ShadowNinja

Re: [0.4.12-dev] Mod security

by ShadowNinja » Mon Jun 08, 2015 14:42

Wuzzy wrote:I wonder why the security won't be activated it as default. If I see it correctly, there are actually only a few mods which would be possibly affected, of which almost all have already be edited to comply with the new mod security system.

It will be on by default soon, I just left it off for a bit so that I could be fairly confident that any mods that might be broken were updated.

Wuzzy wrote:I have seen that the Lua built-in function “setfenv” is on the whitelist. This function can overwrite environment variables, are you sure this is not a problem?

It cannot override environment variables (os.getenv gets them and there's no setter). It can set function environments though. This is pretty harmless because just about all you can do is give a function a more restrictive environment (like the mesecons Luacontroller does).
I play on my Minetest server and VanessaE's.
The best way to contact me is usually IRC (InchraNet, freenode).
 

nrz
Member
 
Posts: 51
Joined: Sat Feb 07, 2015 17:16
GitHub: nerzhul
IRC: nrzkt
In-game: nrz

Re: [0.4.12-dev] Mod security

by nrz » Wed Jun 10, 2015 06:18

This is a very good news. I hope mods will update to converge to mod_security and we could enable it by default
 

Sokomine
Member
 
Posts: 2980
Joined: Sun Sep 09, 2012 17:31

Re: [0.4.12-dev] Mod security

by Sokomine » Sun Jul 19, 2015 01:59

I hope mod security gets developed further and enabled by default. My handle_schematics mod needs an exception as it needs to read schematics in other folders, but that works very fine so far. I've asked ShadowNinja for support for the very useful minetest.get_dir_list in a secure environment. Right now it can't read directories outside its scope (i.e. other worlds). Hopefully that'll get added once ShadowNinja got the time. But what about other mods? Are there any further needs regarding the new feature?
A list of my mods can be found here.
 

est31
Member
 
Posts: 172
Joined: Mon Dec 29, 2014 01:49

Re: [0.4.12-dev] Mod security

by est31 » Mon Jul 20, 2015 14:18

I think restricting file read access is part of the sandboxes' features.
 

Sokomine
Member
 
Posts: 2980
Joined: Sun Sep 09, 2012 17:31

Re: [0.4.12-dev] Mod security

by Sokomine » Fri Jul 24, 2015 15:06

est31 wrote:I think restricting file read access is part of the sandboxes' features.

Yes, certainly. But I'm mostly worried about write access to other files. Read access - especially limited to the Minetest folders - is far less critical. And a file browser just needs to be able to get directories....
A list of my mods can be found here.
 

User avatar
ArguablySane
Member
 
Posts: 116
Joined: Sun Oct 12, 2014 21:29

Re: [0.4.12-dev] Mod security

by ArguablySane » Mon Aug 31, 2015 23:03

Is there any protection against the following scenario:

Mod A has privileges and calls minetest.some_function every so often.
Mod B doesn't have privileges, but sets minetest.some_function to point to its own malicious function which calls a restricted function to do something evil.
Now, when mod A calls minetest.some_function it will actually be running evil code with elevated privileges.

The same attack might be possible by substituting functions held inside a mod's global variable, such as mod_a.some_function.

I did a quick test and it seems there's nothing stopping a mod from overwriting minetest.some_function, and that change affects other mods. I haven't tested if it lets you use restricted functions though.
The above post and any ideas expressed therein are released to the public domain under a Creative Commons CC0 license.
 

est31
Member
 
Posts: 172
Joined: Mon Dec 29, 2014 01:49

Re: [0.4.12-dev] Mod security

by est31 » Mon Aug 31, 2015 23:39

ArguablySane, lua security doesn't have the "state" approach. Instead, security is managed using functions. If you have no functions you can use to do evil stuff, you are in a sandbox. Trusted mods get a table with a set of "dangerous" functions. Now mod B can't do any evil things inside minetest.some_function, as it only has access to the "safe functions" of its environment when overriding the functions.
 

est31
Member
 
Posts: 172
Joined: Mon Dec 29, 2014 01:49

Re: [0.4.12-dev] Mod security

by est31 » Mon Aug 31, 2015 23:43

That being said, trusted mods of course have to watch out, and must not trust output of the minetest.something API.
 

User avatar
ArguablySane
Member
 
Posts: 116
Joined: Sun Oct 12, 2014 21:29

Re: [0.4.12-dev] Mod security

by ArguablySane » Mon Aug 31, 2015 23:50

est31 wrote:ArguablySane, lua security doesn't have the "state" approach. Instead, security is managed using functions. If you have no functions you can use to do evil stuff, you are in a sandbox. Trusted mods get a table with a set of "dangerous" functions. Now mod B can't do any evil things inside minetest.some_function, as it only has access to the "safe functions" of its environment when overriding the functions.

If I understand correctly, there is at least one function they could use to do evil stuff: minetest.request_insecure_environment()

Just write something like:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
minetest.log = function (whatever)
    local root = minetest.request_insecure_environment()
    root.do_evil_thing()
end
The above post and any ideas expressed therein are released to the public domain under a Creative Commons CC0 license.
 

est31
Member
 
Posts: 172
Joined: Mon Dec 29, 2014 01:49

Re: [0.4.12-dev] Mod security

by est31 » Mon Aug 31, 2015 23:55

Okay, this only works though if the evil mod gets loaded before the trusted mod, and the trusted mod uses that facility while loading(quite common). This seems to be a valid way to escape the sandbox, congratulations.
 

User avatar
Sane
Member
 
Posts: 103
Joined: Tue Jun 17, 2014 09:31
GitHub: mt-sane
In-game: Sane

Re: [0.4.12-dev] Mod security

by Sane » Tue Sep 01, 2015 06:41

Huh? dosn't minetest.request_insecure_environment() check where it's called from? Wouldn't that be the key point of setting securiy to true?
Trying to stay me.
 

User avatar
ArguablySane
Member
 
Posts: 116
Joined: Sun Oct 12, 2014 21:29

Re: [0.4.12-dev] Mod security

by ArguablySane » Tue Sep 01, 2015 08:48

est31 can probably explain in more detail because I don't know all the inner workings, but essentially this exploit works by tricking another mod into calling minetest.request_insecure_environment(). Mod B creates the evil function, but mod A is the one which actually calls it during the loading stage.
The above post and any ideas expressed therein are released to the public domain under a Creative Commons CC0 license.
 

User avatar
Sane
Member
 
Posts: 103
Joined: Tue Jun 17, 2014 09:31
GitHub: mt-sane
In-game: Sane

Re: [0.4.12-dev] Mod security

by Sane » Tue Sep 01, 2015 09:12

ArguablySane wrote:est31 can probably explain in more detail because I don't know all the inner workings, but essentially this exploit works by tricking another mod into calling minetest.request_insecure_environment(). Mod B creates the evil function, but mod A is the one which actually calls it during the loading stage.

Yes I do see that B is overwriting the minetest.log function. But to do so it has the minetest.request_insecure_environment() call in it's own code. I thought setting security to on forbids using that function.
Trying to stay me.
 

est31
Member
 
Posts: 172
Joined: Mon Dec 29, 2014 01:49

Re: [0.4.12-dev] Mod security

by est31 » Tue Sep 01, 2015 14:23

The problem is what do you define as "your own code"? Right now we use the currently loading mod in order to find out which mod's code is currently running. This is wrong of course, as ArguablySane has pointed out, because other mods' code can run as well, thanks to this trick.

A fix for this exploit would be to look at the stack (as well).
 

User avatar
Sane
Member
 
Posts: 103
Joined: Tue Jun 17, 2014 09:31
GitHub: mt-sane
In-game: Sane

Re: [0.4.12-dev] Mod security

by Sane » Tue Sep 01, 2015 21:09

est31 wrote:The problem is what do you define as "your own code"? Right now we use the currently loading mod in order to find out which mod's code is currently running. This is wrong of course, as ArguablySane has pointed out, because other mods' code can run as well, thanks to this trick.

A fix for this exploit would be to look at the stack (as well).

A fix would be greatly appreciated. Well I think. At least I'd greatly appreciate a fix.
Sometimes I get the feeling that I am the only one who is setting security to true. That is setting it to true not for trying to hack it.
Trying to stay me.
 

User avatar
ArguablySane
Member
 
Posts: 116
Joined: Sun Oct 12, 2014 21:29

Re: [0.4.12-dev] Mod security

by ArguablySane » Tue Sep 01, 2015 22:23

Sane wrote:A fix would be greatly appreciated. Well I think. At least I'd greatly appreciate a fix.
Sometimes I get the feeling that I am the only one who is setting security to true. That is setting it to true not for trying to hack it.

A temporary fix would be to add all trusted mods to the dependencies of all untrusted mods, except where that would create a dependency loop.
That way the trusted mods run first and any malicious code can't hijack them.
The above post and any ideas expressed therein are released to the public domain under a Creative Commons CC0 license.
 

Sokomine
Member
 
Posts: 2980
Joined: Sun Sep 09, 2012 17:31

Re: [0.4.12-dev] Mod security

by Sokomine » Wed Sep 02, 2015 23:42

Sane wrote:Sometimes I get the feeling that I am the only one who is setting security to true.

You're not the only one. I've set it to true immediately after learning about the new feature. What bothers me is that I have to add my handle_schematics mod to the list of trusted mods. Of course I do trust my mod; but others may have a hard time checking a complex mod for trustworthiness. And it's only in order to be able to read schematics in other folders. Which doesn't really work yet as minetest.get_dir_list doesn't cooperate if it's the folder of another mod. Maybe I ought to put the reading files part into a sepearte mod so that the code will be easier to analyze by users intrested in security.

The bright side is that there are very few mods which actually need to be set as trusted mods. It's obvious in case of the IRC mod. handle_schematics needs it for reading files. That seems to be about all. Setting security to true by default and telling players to adjust their minetest.conf files might be a good idea.
A list of my mods can be found here.
 

User avatar
Minetestforfun
Member
 
Posts: 936
Joined: Tue Aug 05, 2014 14:09
GitHub: Darcidride
IRC: Darcidride + MinetestForFun
In-game: Darcidride + MinetestForFun

Re: [0.4.12-dev] Mod security

by Minetestforfun » Thu Sep 03, 2015 10:11

Security setting is enforced to true for some mods on all MinetestForFun's Team servers ;)
 

User avatar
Sane
Member
 
Posts: 103
Joined: Tue Jun 17, 2014 09:31
GitHub: mt-sane
In-game: Sane

Re: [0.4.12-dev] Mod security

by Sane » Tue Sep 15, 2015 22:43

Sokomine wrote:... Maybe I ought to put the reading files part into a sepearte mod so that the code will be easier to analyze by users intrested in security.

Yes I think that separating the critical parts of mods that need to do trusted stuff is a good idea.

Sokomine wrote:Setting security to true by default and telling players to adjust their minetest.conf files might be a good idea.

Also right, security should definitly be on by default.
Trying to stay me.
 

User avatar
Wuzzy
Member
 
Posts: 2161
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Mod security will be enabled by default in next relase

by Wuzzy » Tue Nov 08, 2016 14:27

Note to all
Mod security (secure.enable_security) is enabled by default in the current developer version of Minetest, which means:
Mod security will be enabled in the next Minetest release.

Modders which need “dangeours” functions like reading from outside of mod/world directories, etc. for their mods should prepare their mods sooner or later, and test it with setting secure.enable_security = true. To make sure everything transitions smoothly in the next Minetest release.
Otherwise, we might experience a little “surprising” mod breakage in the next release. xD

If your mod does not need “fancy” OS functions or file writing, then you're probably OK. But when in doubt, you can already test your mod with stable Minetest 0.4.14 just by setting secure.enable_security to true.

If your mod does still work then, you're done. If not, you should try to take the time and follow the advice in the first post. Please do not ask players “to temporarily disable mod security” just for your mod, this is just rude and makes your mod 1000% less trustworthy. ;-)

On my machine, I have now enabled the mod security setting, in hope I will stumple upon any mods which will break. If I find some, I will report it here and the respective mod threads.

Note to players
What this all means is, that mods will be (by default) more restricted in what they can do, unless they are “trusted”. This is to avoid mods going rogue by e.g. randomly deleting files all over the place. So this is a very important feature.
The vast majority of mods does not need insecure functions, so they should work “out of the box” as before.
The few mods which require this will need to be trusted. Modders might ask you to modify the setting secure.trusted_mods by adding their mod to their list. This is a legitimate request if (!) there is a good reason for it. E.g. the [irc] mod needs extended access for the mod to “talk to” an actual IRC server. However, a simple mod which (for example) only registers decorational blocks (e.g. moreblocks) almost certainly does not need extended access to anything. Also, note that mods which need to be trusted should be very rare. It should NOT be a common thing. If a modder ask you to add such a mod as trusted, this should make you skeptical. But you should always decide if you want to trust a mod with extended access on your machine. When in doubt, read the source code or ask a friend or someone on the Minetest forums.

What should make you very skeptical is when a modder asks you to disable mod security altogehter. I can only think of two reasons why a modder could do that: Either because the modder is too lazy to make the mod properly compatible with mod security (clumy programming) or the modder has bad intentions. Both are unacceptable.

To sum it all up: The mod security system is supposed to protect you from mods going rogue. But a proper security also requires you to think; don't get fooled and don't mindlessly follow any instructions given to you. ;-)
I'm creating MineClone 2, a Minecraft clone for Minetest.
I made the Help modpack, adding in-game help to Minetest.
 

User avatar
Wuzzy
Member
 
Posts: 2161
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Attention, intllib users!

by Wuzzy » Wed Nov 09, 2016 02:57

IMPORTANT message to modders: If your mod includes intllib support, chances are that your mod will break when mod security will be enabled.

If your intllib boilerplate code looks like this:
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
Code: Select all
local S
if (minetest.get_modpath("intllib")) then
    dofile(minetest.get_modpath("intllib").."/intllib.lua")
    S = intllib.Getter(minetest.get_current_modname())
else
    S = function ( s ) return s end
end

Then your mod is affected and will break when both intllib and mod security are enabled at the same time. This is because this boilerplate code includes a “dofile” statement to the intllib directory, which is of course outside of your mod. And this is of course a mod security violation. Don't worry, it can be fixed easily.
The suggested boilerplate code for intllib has been changed. So to fix this, use the latest recommend boilerplate code. Refer to the intllib documentation. See here: https://github.com/minetest-mods/intllib

If there never was a “dofile” in your intllib boilerplate code, then your mod is probably safe.

For reference, here's how the bugfix will usually look like:
http://repo.or.cz/minetest_dice2.git/bl ... :/init.lua
I'm creating MineClone 2, a Minecraft clone for Minetest.
I made the Help modpack, adding in-game help to Minetest.
 

Sokomine
Member
 
Posts: 2980
Joined: Sun Sep 09, 2012 17:31

Re: [0.4.12-dev] Mod security

by Sokomine » Tue Nov 29, 2016 20:27

I still have that problem stated in my previous postings: My handle_schematics mod can't work properly. It is in part a filie browser. Its purpose is to save schematics (so far so good - no problem there) and to place schematics into the world (WorldEdit, .mts or even .schematic format). Those schematics can be found in the worldname/schems/ folder (placed there by WorldEdit) or in some gamename/mods/modname/schems/* folder (may vary a bit from mod to mod). In order for my mod to be able to supply players with a way to transfer a building from one map to another, they need to be able to select it somehow. And the mod needs to be able to actually *read* the schema file. Just telling people to copy it over does not seem to be a good idea. Neither is telling them to turn security off.

I'd be fine with an extra, simple, easy-to-understand-and-check mod that provides read access to directories (filename extensions .mts, .schematic, .we and .meta are required - the rest is of no intrest anyway) and that provides read access to those files. Said read access is only required for files which *another world* or *another mod* could read anyway. The files need to be readable without having to be opened in the init phase.
A list of my mods can be found here.
 

User avatar
sfan5
Member
 
Posts: 3636
Joined: Wed Aug 24, 2011 09:44
GitHub: sfan5
IRC: sfan5

Re: [0.4.12-dev] Mod security

by sfan5 » Wed Nov 30, 2016 09:47

Please open an issue on Github so this isn't overlooked before the release.
Mods: Mesecons | WorldEdit | Nuke
Minetest builds for Windows (32-bit & 64-bit)
 

Lichtbringer
New member
 
Posts: 1
Joined: Fri Feb 24, 2017 21:36
In-game: Lichtbringer

Re: [0.4.12-dev] Mod security

by Lichtbringer » Fri Feb 24, 2017 22:54

do_evil_thing() needs to check the environment for which mod requested it and not which mod is running currently.

request_insecure_environment() needs to set "environment.mod = mod with this command in it's code" and prohibit further change in this instance of insecure_environment.
 


Return to Minetest News

Who is online

Users browsing this forum: No registered users and 7 guests

cron