janet-lang / janet

A dynamic language and bytecode vm
https://janet-lang.org
MIT License
3.58k stars 229 forks source link

Improve sandboxing to allow more granular permissions #1358

Open tionis opened 10 months ago

tionis commented 10 months ago

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:

iacore commented 10 months ago

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

sogaiu commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

amano-kenji commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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...