5 ms·

Windows does all of those, in addition to fine grained access controls. I would go so far as to say that the Chromium sandbox implementation is better than on A

Windows does all of those, in addition to fine grained access controls. I would go so far as to say that the Chromium sandbox implementation is better than on Android because of the ability to completely de-privilege processes.

pl4nty 4y ago
Windows struggles with feature adoption though. Win11 helped with the TPM requirement and features on by default, but MSIX apps are still underrepresented so userspace sandboxing is weaker. Windows virtualization-based security is great though, imo it's a significant advantage over Android
- mike_hearn 4y ago
  MSIX doesn't implement sandboxing. Apps can opt in to being sandboxed via that tech, but you can also write totally unsandboxed apps. There's also a very light weight app container mode called (internally) Helium which just redirects some filesystem and registry stuff, but the goal is to make uninstalls clean, not security. The Windows kernel does offer an impressive number of options to lock down processes. Look at the Chrome sandbox code some time. The Windows API is huge but you can really lock it down a lot. The macOS sandbox architecture is, however, the best. The Linux approach is sadly in third place.
  - mwcampbell 4y ago
    Is Helium mandatory for MSIX-packaged apps?
    - mike_hearn 4y ago
      I think they recently added a way to opt out of it entirely. That said, it does very little and because it's not a sandbox it's easy to 'escape': • Copy an EXE to %TEMP% and run it from there. • Use a Win32 API flag to start a process (of any path) outside the app container. There are only a few cases where Helium is an issue and they're all easy to work around. One example is writing a log file to your app private UserData directory and then opening Notepad on it. If you do it the 'naive' way then Notepad won't be able to find it, because you'll pass a redirected path which it can't see. The fix is simply to resolve the redirect before passing the argument to Notepad using a Win32 API call. I know we talked about Conveyor a few days ago so I'll note here that if you package a JVM app with it then the %LOCALAPPDATA% and %APPDATA% environment variables are rewritten to their target locations automatically, so as long as you use them to decide where to write app private files then their paths will be visible to other apps, avoiding the Notepad issue. This doesn't apply to native or Electron apps though, at least not at this time.
      - actionfromafar 4y ago
        Thanks, that's very useful info for me.
  - helloooooooo 4y ago
    App silos are pretty neat, I also find it kind of shameful that server silos are locked down to server SKUs. I would figure there could be some significant benefit to using them in browser renderer processes.
    - mike_hearn 4y ago
      Chrome does use app containers for its kernel sandbox.
vladvasiliu 4y ago
> Windows does all of those, in addition to fine grained access controls. Aren't those still user-based? So, in the typical case of a single-user computer, a rogue app that I run with my account would be able to access my data. There's the protected folders thing (not sure about the name) since a few versions ago, which attempts to block random apps from accessing random folders. But it's opt-in (folders are not protected by default, you have to add them one by one). It's also all or nothing: either a given app is "untrusted" and it can't access any of the protected folders, or it's "trusted" and it can access all of them. I can't say I trust Photoshop to only touch my pictures folder, but not my .ssh folder.

pl4nty 4y ago

Windows struggles with feature adoption though. Win11 helped with the TPM requirement and features on by default, but MSIX apps are still underrepresented so userspace sandboxing is weaker. Windows virtualization-based security is great though, imo it's a significant advantage over Android

mike_hearn 4y ago
MSIX doesn't implement sandboxing. Apps can opt in to being sandboxed via that tech, but you can also write totally unsandboxed apps. There's also a very light weight app container mode called (internally) Helium which just redirects some filesystem and registry stuff, but the goal is to make uninstalls clean, not security. The Windows kernel does offer an impressive number of options to lock down processes. Look at the Chrome sandbox code some time. The Windows API is huge but you can really lock it down a lot. The macOS sandbox architecture is, however, the best. The Linux approach is sadly in third place.
- mwcampbell 4y ago
  Is Helium mandatory for MSIX-packaged apps?
  - mike_hearn 4y ago
    I think they recently added a way to opt out of it entirely. That said, it does very little and because it's not a sandbox it's easy to 'escape': • Copy an EXE to %TEMP% and run it from there. • Use a Win32 API flag to start a process (of any path) outside the app container. There are only a few cases where Helium is an issue and they're all easy to work around. One example is writing a log file to your app private UserData directory and then opening Notepad on it. If you do it the 'naive' way then Notepad won't be able to find it, because you'll pass a redirected path which it can't see. The fix is simply to resolve the redirect before passing the argument to Notepad using a Win32 API call. I know we talked about Conveyor a few days ago so I'll note here that if you package a JVM app with it then the %LOCALAPPDATA% and %APPDATA% environment variables are rewritten to their target locations automatically, so as long as you use them to decide where to write app private files then their paths will be visible to other apps, avoiding the Notepad issue. This doesn't apply to native or Electron apps though, at least not at this time.
    - actionfromafar 4y ago
      Thanks, that's very useful info for me.
- helloooooooo 4y ago
  App silos are pretty neat, I also find it kind of shameful that server silos are locked down to server SKUs. I would figure there could be some significant benefit to using them in browser renderer processes.
  - mike_hearn 4y ago
    Chrome does use app containers for its kernel sandbox.

vladvasiliu 4y ago

> Windows does all of those, in addition to fine grained access controls. Aren't those still user-based? So, in the typical case of a single-user computer, a rogue app that I run with my account would be able to access my data. There's the protected folders thing (not sure about the name) since a few versions ago, which attempts to block random apps from accessing random folders. But it's opt-in (folders are not protected by default, you have to add them one by one). It's also all or nothing: either a given app is "untrusted" and it can't access any of the protected folders, or it's "trusted" and it can access all of them. I can't say I trust Photoshop to only touch my pictures folder, but not my .ssh folder.