An idea for script security measures

[dewiniaid]

There's a couple issues about security already, but each only covers a small portion of the scope. I hope that this idea can lead to a more comprehensive solution.

This adds a notion of security levels to functions (via a modifier word in DECLARE FUNCTION) and files (via a new command.). These levels are:

RESTRICTED - The default for all files and functions unless otherwise specified. May not define SECURE functions. May not call or define TRUSTED files or functions.

TRUSTED and SECURE - No restrictions. The difference between these is SECURE functions can be called from untrusted code, trusted functions cannot. In this way, a secure function may serve as a mechanism to allow untrusted code to perform limited calls into trusted code.

The console (and telnet clients) are considered trusted. Functions defined by entering the definition into the console are still considered restricted (unless explicitly declared otherwise). Note this does allow a minor vulnerability in the case of blind copy/paste, but still closes most of it.

Scripts are considered restricted unless that access is changed (via a command that is only allowed from trusted/secure code -- initially, this is just the console). Compilation should fail if a restricted script declares a function of a type other than restricted. Execution should fail if a restricted script calls a function marked as trusted or a delegate of said function, or runs a file marked as trusted.

The following operations should fail in a restricted script:

• Any changes to config, and any access (even get) to configuration involving the telnet server.
• Anything that reads files outside of the actual scripts folder or (optionally) a user-controlled sandbox.
• Anything that writes (including delete) from anything outside the sandbox.
• Anything else that seems like it should be restricted.

To allow a transition period with old code, KOS should have an option to simply yell loudly wherever restricted code calls into unrestricted code, rather than blocking the call outright. This option should be immediately deprecated and removed at some point in the future. Attempts to define unrestricted code within restricted code should fail regardless of this setting.

[dewiniaid]

Mobile made me accidentally post this in the middle of writing; will fix it when I can. (Now fixed)

[hvacengi]

With the new sub directories work, we have outright restricted the ability to write to folders outside of the Script directory (unless you create a symbolic or hard link inside that directory, in which case you did it to yourself). I think attempting to create a true sandbox is probably beyond the scope of this project.

Otherwise, security that is dictated within the scripts themselves is difficult at best. Presumably your concern is that a downloaded script may attempt to maliciously change your settings and/or delete your files. So, if you download a script that wants to set the the IPU value to 2000, you then have to run it as trusted or secure. If that same script then deletes all of the files on your archive, you still gave it permission. This is why Android has a manifest of many permissions, which are now able to be allowed or denied.

Enabling or disabling the telnet server I suppose has some level of concern, but setting the telnet config setting will pop up the confirmation window before actually enabling the telnet server. So long as you tell this window to continue to pop up, you can prevent scripts from turning on the server without your permission. I would expect your firewall to block an external telnet connection by default anyways. If this presents a major risk, we can revisit how telnet is handled by simply blocking it's access from the script. The connection itself can be secured using a VPN or SSH tunnel.

Because scripts are inherently open source, the best form of security is to review the code before executing it.

[hvacengi]

Further discussion on telnet: Setting the telnet server to allow listening on non-loopback IP addresses also pops up its own confirmation window. So if you tell kOS to allow telnet to be enabled without the UI, you can still restrict it from listening on your network IP address. This works especially well with SSH tunneling, since you can remotely tunnel the localhost:5410 to be the ssh server's localhost:5410. Toggling this option on Windows also resulted in a confirmation dialog box from the windows firewall.

[dewiniaid]

While I realize that people should be vetting the source of anything they install (particularly when the source code is usually right there in front of them), my original idea was to give some measure of security in case they don't. Particularly if someone downloads .ksm files instead of .ks files and thus can't really inspect it.

I presume Android-esque individual permissions is a bit overkill. My thoughts were more:

• If I wrote it, it runs Trusted. (Not even necessarily true if I'm trying to guard against bugs deleting files off the archive).
• If it's a function specifically intended to grant limited access to an untrusted script (e.g. allowing an IPU change), it runs Secure.
• Otherwise, untrusted unless I'm fully vetted the source.

On Mon, Jun 6, 2016 at 10:38 AM Brad White notifications@github.com wrote:

Further discussion on telnet: Setting the telnet server to allow listening on non-loopback IP addresses also pops up its own confirmation window. So if you tell kOS to allow telnet to be enabled without the UI, you can still restrict it from listening on your network IP address. This works especially well with SSH tunneling, since you can remotely tunnel the localhost:5410 to be the ssh server's localhost:5410.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/KSP-KOS/KOS/issues/1647#issuecomment-224031188, or mute the thread https://github.com/notifications/unsubscribe/ADPJpVdcYmucl2AxsMsNCbrPKYkGHYlfks5qJFr_gaJpZM4IcoK2 .

[Dunbaratu]

Ugh. Don't get me started on the uselessness of Android-esque individual permissions. "This app wants to access your local files". Uhm.. Okay... WHICH ONES? Can I restrict it by folder? No? Well, then I don't know what I'm allowing it to do, do I? "This app wants to access the internet." Uhm, okay, which domains on the internet? Just its own? Can I pick? No? Then I don't know what I'm allowing, do I?

As to the issue of using a link to "escape" the jail subdirectory of kOS, it's only a security problem if we allow kOS scripts to create links. I don't think it knows how to do that. The only links that can exist are ones that were created from outside the script itself.