Embed secure VM - Opt-Out File-IO

[frehberg]

Using Gluon as secure embedded engine, for security reasons it should be possible to remove file-io capabilities from std-libraries of Gluon VM. Also, any form of library for network IO or handling of sub-processes should be optional as well.

[Marwes]

IO actions, invoking arbitrary rust code and debug functions (which is rust code that specifically circumvents iO) are the only ways to have side effects so in theory you can just disable IO https://docs.rs/gluon/0.18.1/gluon/trait.ThreadExt.html#method.run_io and thereby avoid any side effects.

[frehberg]

Ah, thanks, I will check the run_io feature. Maybe, just a few ideas that came into mind:

• Is there a way to restrict the modules that can be loaded via "import!" ? Would it be possible per VM instance to define a whitelist of modules an expression may load into symbol-space via "import!" ?
• Is there a pool of system-threads being managed by a VM? Would it be possible to define an upper bound of system-threads an expression may create?
• As for File-IO, would it be possible to define an interceptor trait, auditing the file-open (read-only/read-write) actions, or maybe enforcing file-IO to certain directory (root-directory) only. And maybe a similar interceptor trait for network-connects to well known remote hosts, and binding listeners to local IPs/network-interfaces.

[Marwes]

Is there a way to restrict the modules that can be loaded via "import!" ? Would it be possible per VM instance to define a whitelist of modules an expression may load into symbol-space via "import!" ?

In theory, yes. import! is just a macro so it could be removed/replaced with something that does whatever you want (such as restricting possible imports). There may be code that assumes that the "correct import!" macro is in place though so it may not work out of the box.

Is there a pool of system-threads being managed by a VM? Would it be possible to define an upper bound of system-threads an expression may create?

No, https://gluon-lang.org/doc/crates_io/std/std/thread.html is rather primitive right now and has no support for limiting its use (other than not using it)

As for File-IO, would it be possible to define an interceptor trait, auditing the file-open (read-only/read-write) actions, or maybe enforcing file-IO to certain directory (root-directory) only. And maybe a similar interceptor trait for network-connects to well known remote hosts, and binding listeners to local IPs/network-interfaces.

No, same as for threading. You will have to prevent this modules use/replace it with our own.