6 ms·

> The only other alternative is turning your computer into a glorified phone (a.k.a. a locked-down media consumption device) There’s a third alternative: keep

by jolux 3y ago

> The only other alternative is turning your computer into a glorified phone (a.k.a. a locked-down media consumption device) There’s a third alternative: keep the platform powerful but increase the default isolation level for third-party software and let the user choose what permissions it has. macOS is headed in this direction. Qubes is a more radical example and I think probably the future of desktop computing: everything will run in its own virtual machine.

delfinom 3y ago
>There’s a third alternative: keep the platform powerful but increase the default isolation level for third-party software and let the user choose what permissions it has. That's the direction Windows is going as well with the MS-Store and appx/msix bundles. There's also Process Memory protection by using virtualization https://support.microsoft.com/en-us/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78 https://support.microsoft.com/en-us/windows/core-isolation-e...
FireInsight 3y ago
This is where Linux is going as well. I believe that in the future most peoples base systems will contain only necessary packages and other software will be run out of Flatpaks or a comparable technology separate from the host.
- nickstinemates 3y ago
  This is how I run everything outside of coreutils in Linux. Either with VM isolation or packed away in a container. Host is basically a hypervisor with external monitoring and logging.
- jchw 3y ago
  Flatpak right now isn't really a security boundary. That said, I don't think there's any particular reason it couldn't or shouldn't be in the future. The model seems amenable to it, and maybe it was at one point the intent even.
vorpalhex 3y ago
This is already painful though. The filesystem becomes a disjointed mess. Doing anything in an app becomes fighting permissions. Weird things break (eg I can drag and drop a screenshot from my downloads folder but not my screenshots folder into the discord flatpak). Then of course apps simply get sloppy in requesting permissions.. and in return malware pretends to do the same. The end result is now doing anything takes a half dozen prompts and isn't any more secure. It just sucks for me as a user.
- jolux 3y ago
  The restrictions are a starting point for improving system security, not an end point. I agree that the prompts are annoying, there need to be better ways to delegate permissions.
otikik 3y ago
MacOS phones home before running an unverified app. I understand why they do it, but I'd rather they didn't. And I definetly hope that Linux doesn't go that route. Windows ... well my expectation is low with regards to phoning home and security defaults.
- RunSet 3y ago
  > MacOS phones home before running an unverified app. I understand why they do it, but I'd rather they didn't. Considering Apple was brazen enough to name the software that phones home "Gatekeeper" it is all too clear why they do it. https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web https://support.apple.com/guide/security/gatekeeper-and-runt...
  - bamfly 3y ago
    ... because it supervises and scrutinizes "traffic" coming through the "gate" for security reasons, before letting it inside the "walls" where it might do harm? Like a gatekeeper does?
pdntspa 3y ago
I like the sandboxing model but virtual machines add way too much abstraction and overhead. Apple's approach is really good here IMO, as a user I need to be able to do things like select any file at any time, and it will under-the-hood add that selection to the sandbox
- jolux 3y ago
  VM technology currently adds a lot of conceptual and computational overhead in most cases but there are examples of it being integrated more seamlessly. WSL 2 is a good one.
- bob1029 3y ago
  I wonder how much overlap exists between the security fanatics and those who post the "why my OS laggy??" threads around here about once a month. The collective brain damage from a 500ms+ start menu has probably already placed us into a fatal death spiral. Not saying you can't make an OS secure AND fast, but it definitely seems challenging if you also want to keep support for applications written 20 years ago.
saagarjha 3y ago
This is difficult to do effectively.
- jolux 3y ago
  I agree, but I’m definitely curious what you see as the biggest challenges given your extensive experience with Apple OS internals.
  - saagarjha 3y ago
    Users are typically not in a good position to make decisions about permissions that are bolted onto a model that didn’t have them to begin with. Think of all the annoying permissions that macOS has currently that you mostly have to click through for a lot of stuff to work (“I want access to your desktop folder”, etc). Software that isn’t designed for a more limited model from the start often does not interact well with efforts to contain it.
- deleted 3y ago
  [deleted]
- didntcheck 3y ago
  How do you mean? Phone OSes prove the model works, at least for ordinary "productivity apps". Linux kernel features to enforce it exist and are well tested, and are used by Docker and Flatpak. Microsoft implemented the technology, but had trouble getting developers to actually commit to it (which is rational, why choose a harder option if there's no incentive?). And MacOS seems to be doing a good job of balancing increased default restrictions with maintaining escape hatches where needed
  - saagarjha 3y ago
    There’s a lot of software that doesn’t fit into the phone OS model that people generally find it useful to have available. macOS has tried to bring some of this to the desktop but beyond straight ports of mobile apps their efforts to allow for apps to progressively do more powerful things have largely been failures.
wongarsu 3y ago
Windows tried that with MSIX which brought sandboxing and a permission/capability system. They even made using that system a requirement for getting on the Microsoft Store. Developers nearly universally rejected dealing with that. Now there's the Windows Sandbox, which tries to provide a strong security boundary through virtualization while still having the kernels cooperate on performance-critical matters (memory, CPU time and graphics). Over time someone (maybe even Microsoft) could expand that to a Windows-based QubesOS-light. Having the user segment applications into containers (with temporary containers for sketchy stuff) but allowing all applications to show windows in the same Window manager might be a viable tradeoff that fills most security needs without breaking compatibility with any software.
- didntcheck 3y ago
  We already have proof the model works both technically and commercially: phones. This is how Android and iOS have been working basically since the start. I imagine the reason most developers rejected MSIX was rational (there was no incentive for them to take a harder option when the older option was still there), but they could have done if it they were forced to. Exceptions are programs which actually do need high privileges, or those which require a degree of interaction with other programs that the safe interfaces do not allow (though Android anticipated this problem with the "intents" system from the start, which solves a lot of use cases)
  - ripley12 3y ago
    The MSIX/AppContainer story is... long, sigh. IMO developers mostly rejected those technologies for reasons unrelated to permissions+capabilities: - MS tried to use it to force developers to distribute their apps through the Store - Eventually they gave up and let people use it outside the Store, but didn't invest enough in bug fixes and backporting the fixes, so it's impractical to use outside the Store - It requires code signing outside the Store which is a huge pain
    - mike_hearn 3y ago
      MSIX gets conflated with UWP but these days they are separate. For a while, Microsoft tried to insist that Store apps were UWP apps, but UWP was basically a new OS platform and not really backwards compatible at all. By then though most Windows code had been written and wasn't being rewritten due to new development, so this attempt to get people off Win32 failed. Devs just rejected the store instead. Project Reunion tried to fix this by bringing together the UWP and Win32 worlds. As part of that MSIX did indeed become available outside the app store and for Win32 apps which run as "full trust" i.e. with all permissions, and it was indeed unfortunately quite buggy. However, some bugs are fixed and others can be worked around. Conveyor [1] is a packaging tool (disclosure: made by my company) that can make and sign MSIX files from any platform, and it works around those bugs so you get a reliable install experience and of course, all the nice MSIX features that motivated the technology in the first place like Windows keeping your app up to date in the background, delta upgrades, sharing of files between different apps, clean uninstalls, being installable without admin privs and so on. You don't have to code sign apps, btw. If you're OK with requiring admin escalation then Conveyor will self-sign your MSIX and install the relevant cert using a small stub EXE that the user invokes. This lets you get the MSIX feature set without paying for certificates. It's not really recommended though for anything except open source apps, as virus scanners will molest your processes in various ways. That said, getting into the MS Store costs $19 for an individual and then MS code signs it for you, so it's cheap and easy. Conveyor can also release through that, including from Linux/macOS, after you get approved, but the approval process is more of a handwave these days than anything else. So that's the current state of play. Win32 apps, unsandboxed, distributed either in or out of the store using MSIX, signed or unsigned. Now Microsoft is working on bringing sandboxing and permissions to the Win32 world, not just for UWP apps. However it'll still only work for MSIXs. [1] https://hydraulic.dev/ https://hydraulic.dev/

by jolux 3y ago

delfinom 3y ago

>There’s a third alternative: keep the platform powerful but increase the default isolation level for third-party software and let the user choose what permissions it has. That's the direction Windows is going as well with the MS-Store and appx/msix bundles. There's also Process Memory protection by using virtualization https://support.microsoft.com/en-us/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78 https://support.microsoft.com/en-us/windows/core-isolation-e...

FireInsight 3y ago

This is where Linux is going as well. I believe that in the future most peoples base systems will contain only necessary packages and other software will be run out of Flatpaks or a comparable technology separate from the host.

nickstinemates 3y ago
This is how I run everything outside of coreutils in Linux. Either with VM isolation or packed away in a container. Host is basically a hypervisor with external monitoring and logging.
jchw 3y ago
Flatpak right now isn't really a security boundary. That said, I don't think there's any particular reason it couldn't or shouldn't be in the future. The model seems amenable to it, and maybe it was at one point the intent even.

vorpalhex 3y ago

This is already painful though. The filesystem becomes a disjointed mess. Doing anything in an app becomes fighting permissions. Weird things break (eg I can drag and drop a screenshot from my downloads folder but not my screenshots folder into the discord flatpak). Then of course apps simply get sloppy in requesting permissions.. and in return malware pretends to do the same. The end result is now doing anything takes a half dozen prompts and isn't any more secure. It just sucks for me as a user.

jolux 3y ago
The restrictions are a starting point for improving system security, not an end point. I agree that the prompts are annoying, there need to be better ways to delegate permissions.

otikik 3y ago

MacOS phones home before running an unverified app. I understand why they do it, but I'd rather they didn't. And I definetly hope that Linux doesn't go that route. Windows ... well my expectation is low with regards to phoning home and security defaults.

RunSet 3y ago
> MacOS phones home before running an unverified app. I understand why they do it, but I'd rather they didn't. Considering Apple was brazen enough to name the software that phones home "Gatekeeper" it is all too clear why they do it. https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web https://support.apple.com/guide/security/gatekeeper-and-runt...
- bamfly 3y ago
  ... because it supervises and scrutinizes "traffic" coming through the "gate" for security reasons, before letting it inside the "walls" where it might do harm? Like a gatekeeper does?

pdntspa 3y ago

I like the sandboxing model but virtual machines add way too much abstraction and overhead. Apple's approach is really good here IMO, as a user I need to be able to do things like select any file at any time, and it will under-the-hood add that selection to the sandbox

jolux 3y ago
VM technology currently adds a lot of conceptual and computational overhead in most cases but there are examples of it being integrated more seamlessly. WSL 2 is a good one.
bob1029 3y ago
I wonder how much overlap exists between the security fanatics and those who post the "why my OS laggy??" threads around here about once a month. The collective brain damage from a 500ms+ start menu has probably already placed us into a fatal death spiral. Not saying you can't make an OS secure AND fast, but it definitely seems challenging if you also want to keep support for applications written 20 years ago.

saagarjha 3y ago

This is difficult to do effectively.

jolux 3y ago
I agree, but I’m definitely curious what you see as the biggest challenges given your extensive experience with Apple OS internals.
- saagarjha 3y ago
  Users are typically not in a good position to make decisions about permissions that are bolted onto a model that didn’t have them to begin with. Think of all the annoying permissions that macOS has currently that you mostly have to click through for a lot of stuff to work (“I want access to your desktop folder”, etc). Software that isn’t designed for a more limited model from the start often does not interact well with efforts to contain it.
deleted 3y ago
[deleted]
didntcheck 3y ago
How do you mean? Phone OSes prove the model works, at least for ordinary "productivity apps". Linux kernel features to enforce it exist and are well tested, and are used by Docker and Flatpak. Microsoft implemented the technology, but had trouble getting developers to actually commit to it (which is rational, why choose a harder option if there's no incentive?). And MacOS seems to be doing a good job of balancing increased default restrictions with maintaining escape hatches where needed
- saagarjha 3y ago
  There’s a lot of software that doesn’t fit into the phone OS model that people generally find it useful to have available. macOS has tried to bring some of this to the desktop but beyond straight ports of mobile apps their efforts to allow for apps to progressively do more powerful things have largely been failures.

wongarsu 3y ago

Windows tried that with MSIX which brought sandboxing and a permission/capability system. They even made using that system a requirement for getting on the Microsoft Store. Developers nearly universally rejected dealing with that. Now there's the Windows Sandbox, which tries to provide a strong security boundary through virtualization while still having the kernels cooperate on performance-critical matters (memory, CPU time and graphics). Over time someone (maybe even Microsoft) could expand that to a Windows-based QubesOS-light. Having the user segment applications into containers (with temporary containers for sketchy stuff) but allowing all applications to show windows in the same Window manager might be a viable tradeoff that fills most security needs without breaking compatibility with any software.

didntcheck 3y ago
We already have proof the model works both technically and commercially: phones. This is how Android and iOS have been working basically since the start. I imagine the reason most developers rejected MSIX was rational (there was no incentive for them to take a harder option when the older option was still there), but they could have done if it they were forced to. Exceptions are programs which actually do need high privileges, or those which require a degree of interaction with other programs that the safe interfaces do not allow (though Android anticipated this problem with the "intents" system from the start, which solves a lot of use cases)
- ripley12 3y ago
  The MSIX/AppContainer story is... long, sigh. IMO developers mostly rejected those technologies for reasons unrelated to permissions+capabilities: - MS tried to use it to force developers to distribute their apps through the Store - Eventually they gave up and let people use it outside the Store, but didn't invest enough in bug fixes and backporting the fixes, so it's impractical to use outside the Store - It requires code signing outside the Store which is a huge pain
  - mike_hearn 3y ago
    MSIX gets conflated with UWP but these days they are separate. For a while, Microsoft tried to insist that Store apps were UWP apps, but UWP was basically a new OS platform and not really backwards compatible at all. By then though most Windows code had been written and wasn't being rewritten due to new development, so this attempt to get people off Win32 failed. Devs just rejected the store instead. Project Reunion tried to fix this by bringing together the UWP and Win32 worlds. As part of that MSIX did indeed become available outside the app store and for Win32 apps which run as "full trust" i.e. with all permissions, and it was indeed unfortunately quite buggy. However, some bugs are fixed and others can be worked around. Conveyor [1] is a packaging tool (disclosure: made by my company) that can make and sign MSIX files from any platform, and it works around those bugs so you get a reliable install experience and of course, all the nice MSIX features that motivated the technology in the first place like Windows keeping your app up to date in the background, delta upgrades, sharing of files between different apps, clean uninstalls, being installable without admin privs and so on. You don't have to code sign apps, btw. If you're OK with requiring admin escalation then Conveyor will self-sign your MSIX and install the relevant cert using a small stub EXE that the user invokes. This lets you get the MSIX feature set without paying for certificates. It's not really recommended though for anything except open source apps, as virus scanners will molest your processes in various ways. That said, getting into the MS Store costs $19 for an individual and then MS code signs it for you, so it's cheap and easy. Conveyor can also release through that, including from Linux/macOS, after you get approved, but the approval process is more of a handwave these days than anything else. So that's the current state of play. Win32 apps, unsandboxed, distributed either in or out of the store using MSIX, signed or unsigned. Now Microsoft is working on bringing sandboxing and permissions to the Win32 world, not just for UWP apps. However it'll still only work for MSIXs. [1] https://hydraulic.dev/ https://hydraulic.dev/