3 ms·

It's a really cool feature, but be aware that MSIX can be tricky to use in its raw form. My company makes a tool [1] that can produce both signed and self-signe

It's a really cool feature, but be aware that MSIX can be tricky to use in its raw form. My company makes a tool [1] that can produce both signed and self-signed MSIX packages from any OS including Linux or macOS using a much friendlier toolchain than what MS provides. It also produces a small installer EXE that works around the unfortunately large number of bugs in Windows to produce a reliable and easier to use experience. We're waiting for this feature to emerge from the insiders builds before adding support for sandboxing, but should do so once it's ready. Released Conveyor currently only supports native, Electron, Flutter and JVM apps. But, we have some unfinished support for shipping Python apps as well. In the tutorial MS sort of hand-wave how to do this, basically saying to repackage the entire Python interpreter and details like pipenvs and native code are left as an exercise for the reader. Real apps do need to think about this of course. If anyone has a need for shipping sandboxed [Python] apps on Windows please do get in touch. It'd be good to understand how much demand is out there before investing in finishing off these features. An alternative approach that can also work well is to use software-level sandboxing, either in replacement or in combination with OS level sandboxing. For example GraalPy is a Python interpreter and JIT engine that not only runs Python faster than CPython but which also supports sandboxing with a high level API and easy interop with other languages: https://www.graalvm.org/python/ https://www.graalvm.org/python/ For example if you want to expose capabilities to your code, this is a good way to do it that's much easier than with kernel sandboxing (ditto for JavaScript). The cost is that Python compatibility isn't yet 100%, and memory usage can be higher. But if it works for your app it can be a useful weapon in your armory. Tying the above together, because GraalPy can be turned into a JVM app (including an ahead-of-time compiled JVM app) you can also ship customized sandboxing Python interpreters with Conveyor, including making a server that uses systemd to start up and sandbox, to really lock down the process tightly. So you can get both software and kernel sandboxing on Linux and macOS, for desktop apps and servers, and maybe in future Windows too. Pretty cool stuff. Disclosure: I own the company that makes Conveyor, and also do part time research work with the Graal team. So I'm talking my own book here, but only because it's a good book. [1] https://conveyor.hydraulic.dev https://conveyor.hydraulic.dev

throwaway2037 3y ago
Thank you to write this detailed post. It is very helpful. Do I understand GraalVM correctly: It can run CPython native extensions (C code extensions compiled to run from CPython)? It sounds like you need to recompile the extension for GraalVM, but it should work OK.
- mike_hearn 3y ago
  Yes it can with caveats. A lot of packages that use native code work but not all. The Python ecosystem is pretty messy and doesn't care much about alternative impls, so some packages do silly things like hard-code that the interpreter must be named "CPython". Others make extremely deep assumptions about the CPython internals that GraalPy can't meet. There's no equivalent of a standardized interface like JNI in the Python world yet (there's an effort called HPy but it's new). GraalPy comes with a modified pip that knows how to patch popular packages that do bad things to work with it. Still, GraalPy actually can use native extensions and in theory in future even sandbox them (or maybe even today, I forget the status). Most alternative implemenations were never able to do it at all! Now if you want to sandbox Python code you must also be able to sandbox arbitrary C/C++. Python is so slow that almost any real program will rely on extensions. The tech stack can do it and it's been done for other languages, because Graal can actually JIT compile and sandbox LLVM bitcode as well. In that case you recompile with a special toolchain and the native code always thinks it's running on Intel Linux. But that has some warmup time impacts and you have limited access to hardware/the OS in that mode obviously, as with any sandboxing. For example PyTorch couldn't be sandboxed in that way. Also I don't know if GraalPy supports sandboxing yet, it might be taking a back seat to other priorities like more ecosystem compatibility.
marwis 3y ago
Is the GraalVM sandboxing only applicable to polyglot runtime or also to JVM itself?
- mike_hearn 3y ago
  Only the polyglot runtime. But, there's a JVM implemented using polyglot/truffle called Espresso. It doesn't fully support sandboxing yet but it's being worked on. Then you would be able to load Java code and execute it inside a sandbox without the SecurityManager. Ask on their slack if you want to learn more about it.

throwaway2037 3y ago

Thank you to write this detailed post. It is very helpful. Do I understand GraalVM correctly: It can run CPython native extensions (C code extensions compiled to run from CPython)? It sounds like you need to recompile the extension for GraalVM, but it should work OK.

mike_hearn 3y ago
Yes it can with caveats. A lot of packages that use native code work but not all. The Python ecosystem is pretty messy and doesn't care much about alternative impls, so some packages do silly things like hard-code that the interpreter must be named "CPython". Others make extremely deep assumptions about the CPython internals that GraalPy can't meet. There's no equivalent of a standardized interface like JNI in the Python world yet (there's an effort called HPy but it's new). GraalPy comes with a modified pip that knows how to patch popular packages that do bad things to work with it. Still, GraalPy actually can use native extensions and in theory in future even sandbox them (or maybe even today, I forget the status). Most alternative implemenations were never able to do it at all! Now if you want to sandbox Python code you must also be able to sandbox arbitrary C/C++. Python is so slow that almost any real program will rely on extensions. The tech stack can do it and it's been done for other languages, because Graal can actually JIT compile and sandbox LLVM bitcode as well. In that case you recompile with a special toolchain and the native code always thinks it's running on Intel Linux. But that has some warmup time impacts and you have limited access to hardware/the OS in that mode obviously, as with any sandboxing. For example PyTorch couldn't be sandboxed in that way. Also I don't know if GraalPy supports sandboxing yet, it might be taking a back seat to other priorities like more ecosystem compatibility.

marwis 3y ago

Is the GraalVM sandboxing only applicable to polyglot runtime or also to JVM itself?

mike_hearn 3y ago
Only the polyglot runtime. But, there's a JVM implemented using polyglot/truffle called Espresso. It doesn't fully support sandboxing yet but it's being worked on. Then you would be able to load Java code and execute it inside a sandbox without the SecurityManager. Ask on their slack if you want to learn more about it.