Revision some of server side security policy

[Disinterpreter]

2020 is close to be end. We have some of cool technologies for prevent and defend vulnerabilities of the server like Docker, linux jails, LXC and etc.

So I just want to suggest to add many of features which approve working with OS. Like os.* io.* dofile require... Lua methods.

Maybe I can't know deeper things of your security. But there are many server owners which want to allow to "talk" their servers with OS. Besides I had an experience in RAGE MP which server-side scripting so simple and it gives to scripters unique functions. (Like all DB drivers, fast connections to analytics like Grafana and a lot of great things! and we needn't to integrate LuaRocks it will be work.)

Yes, I know it is long way, and can't be solve fast. But it is really useful thing for real big servers.

If someone agree with me I suggest to start with adding in meta.xml options like unsafe

Of course the bad side of this it is insecurity of newbie players. And that's all I suppose.

P.S (offtop) I don't designed it by the template because it was moved from another repo.

[Pirulax]

Perhaps adding it with explicit config in meta.xml would be cool.
We could use ACL, but only to check if we should load the libs (os, etc..). Having a translation layer between the actual lua function and our would slow things down a lot.

[Disinterpreter]

Perhaps adding it with explicit config in meta.xml would be cool.
We could use ACL, but only to check if we should load the libs (os, etc..). Having a translation layer between the actual lua function and our would slow things down a lot.

Yes, I know. Thanks for your opinion and ideas! This problem not only about technical side. It's more about understanding modern development and scripting. I mean in the past it looked normal, MTA defend hosters and newbies. But today we have a lot of databases, lua frameworks (like MoonScript), interesting libraries, they so many and creating every day. And I think, today this server security prevent to merge new features to the server. Yes I know, I can write the module. But if module can do anything with OS, we really need to block some functions directly?

So I hope we will see many scripters which agree my idea.

[qaisjp]

The Lua modules branch allows you to set "allowed C modules" in the server config (or was it the ACL? I don't remember), which determines what Lua C modules a server resource can use. We could use the same system to allow some of the default Lua modules.

[qaisjp]

We also don't have to wait for Lua modules to be complete, we just need to make sure we're super happy with the config option we go for, so we reuse the same one when (if ever) we land Lua modules

[Disinterpreter]

We also don't have to wait for Lua modules to be complete, we just need to make sure we're super happy with the config option we go for, so we reuse the same one when (if ever) we land Lua modules

I really can say nothing for other scripters. But for me (as a scripter) simple call of local pgmoon = require("pgmoon") is the best variant. And I don't care about how it was implemented. I suppose we need to wait other opinions.

[sbx320]

The big issue is with server owners downloading backdoored resources. Allowing scripts to access external stuff like the filesystem directly would further broaden the attack surface of malicious resources. Therefore allowing binary modules in the meta isn't really a good option.

[MegadreamsBE]

The big issue is with server owners downloading backdoored resources. Allowing scripts to access external stuff like the filesystem directly would further broaden the attack surface of malicious resources. Therefore allowing binary modules in the meta isn't really a good option.

I agree. Definitely make it a setting in the server config instead of the meta file. Perhaps even display a message upon the server starting that warns a server owner they're opening up their server to possible vulnerabilities.

[CrosRoad95]

The big issue is with server owners downloading backdoored resources.

you can give people option to enable more advanced feature on wish, example c# language have "unsafe" keyword if you want to write unsafe code. Mta could have simillar but in config, where you can specify do you want to get access to unsafe, more advanced features, functions ( downloaders server could have this disabled while more advanced ones enabled. )

[Disinterpreter]

The big issue is with server owners downloading backdoored resources. Allowing scripts to access external stuff like the filesystem directly would further broaden the attack surface of malicious resources. Therefore allowing binary modules in the meta isn't really a good option.

Sure. It can be in mtaserver.conf or in acl.xml for all io, os... tables.

[Pirulax]

I wonder btw how the hell does RAGE manage to have C# client side?

[Disinterpreter]

I wonder btw how the hell does RAGE manage to have C# client side?

C# is a byte-code CLR. So you can remove some dangerous things on CLR level. ¯\(ツ)/¯

added: as i know, the c# code of RAGE is compiling at the client side with limited set of libraries + they use their dotnetcore fork

[AlexTMjugador]

@botder's comment in #1937 (comment) gave me the idea that maybe using the proxy pattern to check for ACL permissions would be a good approach. That proxy could even print some warning to the server console, as @MegadreamsBE suggests. But @Pirulax is concerned about the performance of a "translation layer", which the proxy would defintiely not be (or, at least, not in the painfully slow sense of necessarily having to reinterpret every single parameter). What do you think about this, @Pirulax?