Improve sandboxing to allow more granular permissions

[tionis]

I'd like the sandbox (or a similar command that's more powerful, perhaps called sandcastle :stuck_out_tongue_winking_eye: ) to support limiting network connections per host and file operations per path (also restrict to read, write or read/write etc.) I might work on this when I find some time, but I wanted to create this issue to track ideas around this. To summarize, the following features could be added to sandbox:

• allow specifying a list of allowed paths for sandboxing (directories allow implicit access to all files in them)
• allow limiting file access by capability (read, read/write etc.)
• allow specifying a list of allowed hosts for networking connections during sandboxing (subdomains might be allowed or not based on input)
• these lists could also be replaced by a peg to allow users to specify more complicated patterns (this would of course carry a performance penalty)

[iacore]

sandboxing is a task that should be done by the operating system.

[sogaiu]

At least some of what is proposed seems like reasonable extensions to the existing sandbox function.

---

On a side note, as an example of a concrete use case, the sandbox feature was already put to good use by @AlecTroemel in the Janet support for TIC-80 to improve the security situation. See this PR if interested.

[tionis]

I'm mainly interested in laying some groundwork for a more granular permission model so that it could maybe later be also exposed in janet's cli. I'm mainly inspired by deno's permission model and think that janet's good fit for scripting could benefit from that.

[amano-kenji]

Janet's own sandboxing should not conflict with external sandboxing by things like firejail, SELinux, and apparmor.

If janet does its own sandboxing, I want to impose more restrictions through firejail and apparmor.

[amano-kenji]

I'm worried that granular internal sandboxing will make janet bloated....

[amano-kenji]

Whitelisting approach will force janet to carry lists of common whitelisted paths. Apparmor and firejail carry such lists.

Even apparmor can't block outgoing network connections by hostname. I don't know whether SELinux can do that.

Apparmor can allow unix domain sockets by paths. It can't allow network connections by IP addresses or hosts.

[amano-kenji]

I think this is the kind of thing that's best written as an external tool. You could write such a tool in janet and C.

However, I already have firejail and apparmor for that. I don't want to reinvent wheels.

[amano-kenji]

I'm mainly interested in laying some groundwork for a more granular permission model so that it could maybe later be also exposed in janet's cli.

If you want this to be configured in command line options, then you should probably just use firejail or apparmor....

If janet ever does this, only sandboxing API makes sense. Landlock is linux sandboxing API.

You really don't want to specify granular permissions on command line unless command line options are constructed programmatically. You want something like a firejail/apparmor profile for granular permissions.

[amano-kenji]

allow specifying a list of allowed hosts for networking connections during sandboxing (subdomains might be allowed or not based on input)

That's the job of firewall. Even SELinux doesn't block outgoing network connections by hosts or IP addresses.

[amano-kenji]

allow limiting file access by capability (read, read/write etc.)

This is what apparmor does with profiles..... I really don't want to write verbose permissions on command line.....

[amano-kenji]

My assessment is that this is best done as an external janet library that sandboxes a janet function....

Or, it goes into spork... I don't know whether it's possible to sandbox janet.... from within...