Plugin permissions

[Mm2PL]

I recently went insane and made #4341. A PR that dumps a Lua interpreter into Chatterino. As of today (2023-02-01) Plugins can request access to the following parts of the standard library:

• basic functions (_G) - the most basic built-in lua functions (manual)
• coroutines (coroutine) - asynchronous programming library, no support is explicitly provided in Chatterino for this
• modules library (package) - this allows to use multiple files easily by requireing them. This one could be considered dangerous since in some configurations might load native shared libraries (it does not on Linux x86-64, Windows and Mac remain untested)
• utf8 library
• table library - lua tables are like generic JS objects, these are functions that manipulate them
• math library - your basic sin and stuff
• io library - performs input and output, contains open(), read(), write(), and popen (which spawns a new process and makes its output available as a file)
• os library - all sorts of weird functionality that doesn't fit anywhere else: time, removing files, reading/writing environment, exit(). In particular it has a function called execute which spawns a new process and waits until it exits.
• debug library - access to Lua's internals. We should consider disabling this as it allows messing with Lua's registry table which is currently used for storing references to callbacks (c2.register_command).

Note that for this to be available they must declare it in their info.json (here is how one looks). The UI does indicate what's used, even if the plugin isn't executing any code The whole dangerous library used is a little bit of a placeholder for a more proper system.

In the Lua global namespace there is also a table with Chatterino specific functions available, Plugins don't need any specific permission to use it.

Before #4341 is anywhere near getting merged, we must decide what kind of threat model are we going to use for Plugins. Mainly:

• Should we limit functionality to protect the user and if so how much? (totally disabling certain libraries that can for example execute native code or read/write files)
• What are we trying to protect the user against?
• Finally, should we even worry about this? The user themselves most likely installed the Plugin.

[treuks]

[LosFarmosCTL]

(it does not on Linux x86-64, Windows and Mac remain untested)

If you can tell me how to test it, I can look into that for macOS.

[Mm2PL]

You'll either need to locate a Lua shared library or compile your own to test if it loads.

Here is the source for a tiny library that does nothing but print stuff on load and when it's loaded with Lua.

// test.c
#include<stdio.h>

__attribute__((constructor))
static void construct() {
    puts("shared load");
}

int luaopen_libtest(void* L) {
    puts("owned.");
    return 0;
}

The compile command on Linux GNU is gcc -fPIC -shared -Wall test.c -o libtest.so. It might work as is, but probably requires tweaks to the compiler arguments, stuff like output filename.
Stackoverflow suggests to use -dynamiclib instead of -shared:

gcc -fPIC -dynamiclib -Wall test.c -o libtest.dylib

Then after you have a working library you can open Chatterino with the test plugin. That provides a useful /eval command which can allow you to run the following:

package.loadlib('/path/to/libtest.dylib', 'luaopen_libtest')()

If you get a attempt to call a nil value error, external libraries are disabled. If you don't you probably get a nil or something and the stdout should contain shared load.

[Nerixyz]

On Windows, it errors with "(illegal coroutine yield) init.lua:3: attempt to index a nil value (global 'package')". Not sure why there would be platform differences, since loadlib is disabled on a "Lua level" if I understand correctly:

// PluginController::openLibrariesFor
lua_pushnil(L);
lua_setfield(L, gtable, "loadfile");

[LosFarmosCTL]

Very similar error on macOS:

stdout:

[Nerixyz]

Before #4341 is anywhere near getting merged, we must decide what kind of threat model are we going to use for Plugins. Mainly:

• Should we limit functionality to protect the user and if so how much? (totally disabling certain libraries that can for example execute native code or read/write files)

Yes, we should limit functionality. I think a model similar to how Deno does it for Javascript or how it's done in web-extensions is good. There's info on built-in Lua functions related to sandboxing on lua-users.org and more info on sandboxing considerations for Roblox in Luau.

Permissions could be similar to how they're currently done. I would rename the permissions and give it an entry (one plugin should only have one entry):

{
  "$schema": "https://raw.githubusercontent.com/Chatterino/chatterino2/master/docs/plugin.schema.json",
  "entry": "plugin.lua", // or start...
  "name": "My Plugin",
  "description": "I exhaust all permissions",
  "authors": "me",
  "homepage": "https://chatterino.com",
  "source": "https://github.com/Chatterino/plugins",
  "tags": [],
  "permissions": [
    {
      "name": "read", // without "data" it only allows reading in the plugin directory
      "data": [
        "res/**", // globs
        "data.json",
        "*" // this would allow everything
      ]
    },
    "write", // same model as "read" - here: only in the plugin directory
    "run", // allows the plugin to run applications - same model as "read"
    {
      "name": "ffi",
      "data": {
        "windows-x64": {
          "files": [
            // maybe these should be downloaded to not waste storage
            { "path": "mylib.dll", "sha256": "3aa4c90b7a3263c64fee6222a4344692ce41501eb2b012b924e7414d168b8de0" }
          ]
        },
        "linux-aarch64": {
          // ...
        }
      }
    },
    {
      "name": "http", // only https should be allowed
      "data": [
        // See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns
        "https://*.mozilla.org/*"
      ]
    }
  ],
  "version": "0.1.0-alpha.0", // requires semver
  "license": "GPL-2.0"
}

There should also be a limit on how many resources a plugin can use (similar to how it's done in Luau).

• What are we trying to protect the user against?
• Finally, should we even worry about this? The user themselves most likely installed the Plugin.

Non-technical users. Basically the scenario where a user sees something cool on Discord and mindlessly downloads the plugin. Chatterino should at least tell them, that the plugin has permission to, for example, run any file on his PC - maybe even with a tooltip why that could be dangerous. This should be done before the first run (otherwise there's no point in a permission model).

---

I think permissions should be added in followup-prs. The initial implementation should only include the bare-minimum functions (e.g. math). This makes it easier to reason about a specific implementation of permissions.

[Mm2PL]

Accepted as issue #4620.