[WIP] [PLUGIN] GetOffMyNetwork - A built-in firewall for KSP to enforce opt-in

[ragzilla]

Repo: https://github.com/ragzilla/GetOffMyNetwork

License: GPLv3 + KSP linking exception

What it does:

Attempts to run early in load order to inspect (using Mono.Cecil) all other plugins loaded into the KSP AppDomain. Does CIL inspection to determine if any plugins are using methods or classes inside System.Net, UnityEngine.Network, or UnityEngine.WWW and if references are found disables any instantiated monobehaviours to prevent them from running (so long as GetOffMyNetwork starts first this will prevent their Start() method from being called, afaik there's no way to prevent them from calling Awake()).

Still to do:

Ensure we run in other scenes to disable monobehaviours instantiated after initial KSP load (right now I've only tested it works during the initial load). (complete 20140731)

Interface in the Space Center scene to re-enable disabled plugins (rather than digging into the config file).

Develop framework for whitelisting certain usages of the classes (I'm getting some false positives from plugins which use, for example, UnityEngine.WWW to load Sounds from disk).

Why:

Confirmation and enforcement of the future opt-in rule, except it works now and enforces it at a code level so even if a developer forgets to prompt for network access this plugin will. If you have oppositions/reservations and want to start an argument I ask that you do so through PM to reduce moderator workload.

But what about rule 7:

Rule 7 specifically states the plugin may not work outside of the GameData folder, and the checkAssemblyForViolations method does check for this (if gamedata is not found in the assemblies path, it doesn't inspect the assembly and just returns no violation).

Changelog:

20140731 - 
Refactor Start() to be more modular
Now instantiate in every scene (catches assemblies which don't run immediately), if enabled assemblies are found cancels all coroutines/pending invocations then invokes OnDestroy to cleanup anything the addon did in Awake(). Doesn't seem to be any way to catch code before it enters Awake() that I can find
Don't restart stopped monobehaviours.

Currently looking for feedback on implementation (what stupid things have I done here that I shouldn't), and if I missed any Unity or CLR classes which contain classes/methods which can access the network. I'm not providing a binary build yet (want to wait until I have the dialog working in the Space Center scene), think of this as a developer preview at this point.

Edited August 1, 2014 by ragzilla

[sarbian]

Mods that are made to break other mods functions will get you in trouble too.

Make a popup that display what you think is bad, but don't go messing up other mods when you don't know about their legitimate use of the net code (Telemachus for exemple).

[ragzilla]

Mods that are made to break other mods functions will get you in trouble too.

Make a popup that display what you think is bad, but don't go messing up other mods when you don't know about their legitimate use of the net code (Telemachus for exemple).

It pops up when it's detected and gives the user a chance to whitelist it. Then it'll re-enable the monobehaviours (not sure if KSP/Unity call Start() on them at that point or not). Restarting KSP would cause the monobehaviours to start as normal though (GOMN loads user whitelist from config).

-edit-

Mods messing with other mods for the sake of it seem to be against the rules, but fulfilling a purpose (enforcing opt-in) seems to be ok, the SBTS thread is only locked due to arguments (hence the request for people to keep arguments out of the thread and keep things civil).

Edited July 31, 2014 by ragzilla

[maxrsp]

While in a perfect world this mod would be totally unneccesary... we obviously don't live in a perfect world so + for you.

[Greys]

This is at the very lease a creative and skillful attempt to solve a perceived issue.

Now, if I'm to understand how this all works, this would block and alert the user to any mods at all that have network code; so it's not really enforcing opt-in as much as it preempts it, and potentially this could make it impossible to run a mod even if you have disabled it's network operation depending on what else runs in that monobehavior. Say the mod has the network accessing code in their Start(). This isn't a complaint, I understand some people would prefer that out come, but you should mention this potentiality in the first post.

I'd also recommend as a future feature that you check the offending monobehavior against the 'events' methods, Start(), Active(), Update(), etc(), and if you're disabling potentially mandatory functionality of the mod, just go ahead and disable all, the other monobehaviors in that namespace too to make sure you don't leave some half dismembered code that wasn't properly initialized running.

[Dunbaratu]

Wouldn't it make a lot more sense to do this using the OS itself and not the library routines of a *particular language* running on that OS? If you want to implement this it seems like doing it at the level of .NET framework libraries is way, waaaay too high-level of a location to be catching network usage. What about the mod that calls out to a non-Csharp library to accomplish things?

Basically, if you're going to call it a firewall, then make it work like an actual firewall. Have it look for network traffic coming from the KSP application, regardless of what exact method call was used to cause the network traffic. Trap the *traffic*, not the API calls.

That would also solve your problem of picking up false positives from people using the WWW libraries to load local sound files, because of course using WWW to look at a file: url won't actually cause any network traffic that a real proper firewall would see.

Edited July 31, 2014 by Steven Mading

[ragzilla]

While in a perfect world this mod would be totally unneccesary... we obviously don't live in a perfect world so + for you.

Thanks!

This is at the very lease a creative and skillful attempt to solve a perceived issue.

Now, if I'm to understand how this all works, this would block and alert the user to any mods at all that have network code; so it's not really enforcing opt-in as much as it preempts it, and potentially this could make it impossible to run a mod even if you have disabled it's network operation depending on what else runs in that monobehavior. Say the mod has the network accessing code in their Start(). This isn't a complaint, I understand some people would prefer that out come, but you should mention this potentiality in the first post.

I'd also recommend as a future feature that you check the offending monobehavior against the 'events' methods, Start(), Active(), Update(), etc(), and if you're disabling potentially mandatory functionality of the mod, just go ahead and disable all, the other monobehaviors in that namespace too to make sure you don't leave some half dismembered code that wasn't properly initialized running.

After thinking this through (half dismembered code) I think I'm going to revise to not re-enable the Monobehaviours after users whitelist, and I'm going to require a KSP restart (at which point the whitelist will tell GOMN not to disable them in the first place). Currently this inspects all methods in all types deriving from monobehaviour in the assembly, and if network code is found anywhere it disables all monobehaviours in the assembly to prevent the mod being half enabled/half disabled (not tested in other scenes yet, still needs some work on this front).

Not sure I've ever had my programming called skillful before, I'm more of a bang two rocks together until something works kind of guy.

Wouldn't it make a lot more sense to do this using the OS itself and not the library routines of a *particular language* running on that OS? If you want to implement this it seems like doing it at the level of .NET framework libraries is way, waaaay too high-level of a location to be catching network usage. What about the mod that calls out to a non-Csharp library to accomplish things?

Basically, if you're going to call it a firewall, then make it work like an actual firewall. Have it look for network traffic coming from the KSP application, regardless of what exact method call was used to cause the network traffic. Trap the *traffic*, not the API calls.

That would also solve your problem of picking up false positives from people using the WWW libraries to load local sound files, because of course using WWW to look at a file: url won't actually cause any network traffic that a real proper firewall would see.

Re non-Csharp, I talked about this with a few other people and this isn't really a be-all end-all, people can obviously get around it, if they want to (non Csharp libraries, reflection and invoke) but at that point the code is being deliberately obfuscating which will hopefully reflect on the author of said code (if you deliberately try to bypass something like GOMN you're actively trying to be sneaky). Currently if people want to block all network traffic from KSP it's trivial enough to do so in windows firewall, this is trying to provide an option halfway between blocking everything and blocking nothing.

Another item with the false positives I've been considering is embedding a whitelist of known false positives, and plugins which implement responsible opt-in behavior (popup on first load, space center scene applauncher functionality) and implicitly whitelist those for being well behaved or false positives (would need some community help on that since I don't run a lot of plugins).

Edited July 31, 2014 by ragzilla

[Dunbaratu]

Your response is predicated on the presumption that preference for other languages besides CSharp must be due to deception - an unfair presumption. It might be that what the mod does is a lot more sensible to implement in another language, or that the author is a lot more familiar with another language. And you don't have to implement an entire separate firewall, or use the OS's firewall to get what I'm talking about - just have the mod look for calls to the much more low-level OS calls instead of looking for calls to the higher level API. i.e. look for the opening of sockets, the sending of packets, that sort of thing, rather than the Csharp .NET libraries, which are just one particular abstraction of the network calls. So it would basically be a firewall, yes, but one that is inside of KSP and is only looking at traffic owned by KSP's application. I think that would be a far more robust and sane design.

[Kerbart]

KSP LAUNCHER

1. Disable network connection
   
2. Launch KSP
   
3. Wait until KSP exits
   
4. Enable network connection
   

Might be easier to implement?

[Dunbaratu]

KSP LAUNCHER

1. Disable network connection
   
2. Launch KSP
   
3. Wait until KSP exits
   
4. Enable network connection
   

Easier, but if your goal is to discover WHICH mod is doing the traffic that doesn't tell you because it would just treat all of KSP as one monolithic application. All you would learn is "network being used by some part of KSP".

I'm not familiar enough with Windows to know how to track it at the level of individual DLLs, without the mistake of doing it at way too high a level (Csharp calls), which has the problems I've already mentioned.

[ragzilla]

KSP LAUNCHER

1. Disable network connection
   
2. Launch KSP
   
3. Wait until KSP exits
   
4. Enable network connection
   

Might be easier to implement?

The goal here is something to enforce opt-in, not shut off networking as a whole (that's easy enough to do in the Windows firewall).

Your response is predicated on the presumption that preference for other languages besides CSharp must be due to deception - an unfair presumption. It might be that what the mod does is a lot more sensible to implement in another language, or that the author is a lot more familiar with another language. And you don't have to implement an entire separate firewall, or use the OS's firewall to get what I'm talking about - just have the mod look for calls to the much more low-level OS calls instead of looking for calls to the higher level API. i.e. look for the opening of sockets, the sending of packets, that sort of thing, rather than the Csharp .NET libraries, which are just one particular abstraction of the network calls. So it would basically be a firewall, yes, but one that is inside of KSP and is only looking at traffic owned by KSP's application. I think that would be a far more robust and sane design.

I agree but this gets well beyond the current inspection (and isn't something I'm even sure is possible in Windows these days). Back in the days you could patch the call table but that's harder to do nowawdays with security features like ALSR. Usually to hook all network traffic from a process you need to do so at the kernel level, and there you lose visibility of what inside the app is initiating the traffic.

I don't see a good way to handle this, and will instead admit it's a weakness in the current plan. There's too many valid uses of reflection (ToolbarWrapper, and other API wrapping interfaces) to blacklist that (without digging into the operands to find what methods people are using) and inspecting pinvoked code is too much work (that's straight up dll disassembly rather than CIL inspection that Mono.Cecil enables, or at least inspecting the imports, but not sure if there's C# code around for that- not something I particularly feel the need to write), so I'm tempted to leave those around as known caveats.

[ragzilla]

Now running and disabling plugins in other scenes. First round on the SpaceCenter GUI but re-using the popup I used during the load phase is causing issues since it's a non-modal popup (so clicks go through it to the spacecenter scene if the user's cursor passes through a clickable object on the way to the dialog).