[HN Gopher] Sandboxing Python with Win32 App Isolation
       ___________________________________________________________________
        
       Sandboxing Python with Win32 App Isolation
        
       Author : pjmlp
       Score  : 11 points
       Date   : 2024-03-12 20:32 UTC (2 days ago)
        
 (HTM) web link (blogs.windows.com)
 (TXT) w3m dump (blogs.windows.com)
        
       | mmis1000 wrote:
       | So, is that basically app-armor for windows? You define which
       | file/netowrk/process a program can access, while not result in a
       | full container resolution like docker/snap/flat pack/uwp.
        
         | pjmlp wrote:
         | This is the evolution of UWP sandboxing into Win32, given that
         | UWP went as we all know.
        
       | mike_hearn wrote:
       | 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/
       | 
       | 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
        
       | sciencesama wrote:
       | Venv for python with a gui ??
        
       ___________________________________________________________________
       (page generated 2024-03-14 23:00 UTC)