6 ms·

The lack of per-application isolation with desktops is one of those ugly truths people try and sweep under the rug. I foresee two potential solutions to this.

The lack of per-application isolation with desktops is one of those ugly truths people try and sweep under the rug. I foresee two potential solutions to this. 1) Run everything in a VM like Qubes (essentially nerfs certain application like 3D acceleration without major R&D) 2) Utilize some container runtime to provide isolation for legacy applications and stub out features such as filesystem calls so they do not to be aware of its existence. Microsoft tried to produce a crippled application runtime for Windows (UWP) with more security, but considering its lack of backwards compatibility and lesser feature-set it is not that surprising that adoption has been an uphill battle.

slimsag 4y ago
UWP has also been deprecated[0] [0] https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp https://www.thurrott.com/dev/258377/microsoft-officially-dep...
walterbell 4y ago
Apple will likely launch Armv9 CPUs (iDevice A16 and MacBook M2) this year. If they don't enable CCA and memory tagging, then we have to wait for Armv9 support in QEMU and a future Qualcomm SoC, https://www.anandtech.com/show/16584/arm-announces-armv9-architecture https://www.anandtech.com/show/16584/arm-announces-armv9-arc... > CCA introduces a new concept of dynamically created “realms”, which can be viewed as secured containerised execution environments that are completely opaque to the OS or hypervisor. The hypervisor would still exist, but be solely responsible for scheduling and resource allocation. The realms instead, would be managed by a new entity called the “realm manager”, which is supposed to be a new piece of code roughly 1/10th the size of a hypervisor. > Applications within a realm would be able to “attest” a realm manager in order to determine that it can be trusted, which isn’t possible with say a traditional hypervisor. Arm didn’t go into more depth of what exactly creates this separation between the realms and the non-secure world of the OS and hypervisors, but it did sound like hardware backed address spaces which cannot interact with each other.
- KMag 4y ago
  That's great! The processor's hypervisor-like firmware should handle task switching, page table manipulation, etc, and the OS kernel should use upcalls to the firmware instead of needing to have various special-case paths for various minor hardware variants. Had the x86 BIOS been a bit better designed (and a bit more performant), we likely would have seen OS kernels leaning much harder on firmware that shipped with the processor instead of having to make as many assumptions about the hardware and special-case checks. Besides allowing for more easily isolated security domains, this allows things like (if properly designed) not needing to wait for kernel improvements to take advantage of more/wider vector registers or other changes that change the amount of processor state to serialize/deserialize when task switching. The DEC Alpha AXP worked somewhat like this with its PALCode firmware. The Tru64 UNIX (and Linux, *BSD, etc.) and VMS kernels actually were unable to execute the privileged CPU instructions. The OS kernel needed to make upcalls to the PALCode, which then could use privileged instructions and could see model-specific registers, etc. The PALCode version used for Tru64 emulated two protection rings, and the PALCode version used with VMS emulated more (I think 4) rings of protection by just keeping an extra integer around for each task, and using that to determine which tasks could currently make which upcalls. One could (and probably should) extend this ring emulation to a bit vector of per-task revokable capabilities that could be passed to child tasks/processes/threads. Hopefully we see something like this for RISC-V, using seL4 for the "realm manager". This would probably require an extra userspace driver process running to intermediate realm setup and manipulation, but wouldn't be in the critical path for system calls or other userspace drivers. We're already running hypervisors so many places that it makes sense to run a formally verified separation kernel everywhere, and run hypervisors and OS kernels as userspace daemons. This avoids the hypervisor needing to emulate hardware as an ad-hoc upcall mechanism and instead simplifies both the hypervisor and the OS kernel. The overhead of modern microkernels is so low that your cell phone's baseband processor is likely running an L4 microkernel. It's called paravirtualization when the OS kernel is modified to use upcalls to the hypervisor instead of trying to perform privileged operations that will be trapped (and then emulated) by the hypervisor. Paravirtualization improves VM performance and potentially sidesteps hypervisor emulation bugs, but it would simplify the kernel (and potentially make it easier to optimize) if OS kernels ran paravirtualized even when there is one guest OS per physical computerp Edit: Of course, there's a small performance hit in the single guest OS case, but if that's the common code path, presumably both hardware and the kernels could be better optimized. Also, if you're supporting OS-opaque realms, you're already paying this hypervisor cost all the time anyway.
greesil 4y ago
Does chrome OS do this?
- est31 4y ago
  Chrome OS has sandboxed developer environments, which is pretty neat: https://www.youtube.com/watch?v=pRlh8LX4kQI https://www.youtube.com/watch?v=pRlh8LX4kQI
- hda111 4y ago
  For using normal Linux applications, Chrome OS uses Linux Containers (LXD) running inside a VM.
mhoad 4y ago
Fuschia from Google also looks to have a very good solution to this problem but is probably still a couple of years away.
- FabHK 4y ago
  They should really pick a name that's easier to spell... https://en.wikipedia.org/wiki/Fuchsia_(operating_system) https://en.wikipedia.org/wiki/Fuchsia_(operating_system)
  - mhoad 4y ago
    I should stop posting while drinking wine too it seems :)
  - saagarjha 4y ago
    I just spell it the rude word it shares the first three letters with, swap out the k with an h, and then add "sia" to the end.
sva_ 4y ago
FireJail does at least some isolation
megous 4y ago
Per-application isolation sounds completely unworkable for a developer. Maybe per-customer isolation, or per-usecase isolation. Isolating customer work (or use case like "production deployment") into separate UNIX user accounts works fairly reasonably.
Ameo 4y ago
I think that the browser is going to eat the desktop/OS and that most apps will eventually be browser-based. PWAs are the initial movement in that direction. As browser APIs expand and support more use-cases through WebAssembly, WebGPU, native filesystem APIs, etc. more and more apps that were primarily or only available as native can be supported in the browser. I know that many people hate web apps because they're often slow, clunky, bloated, etc. but a lot of that is changing as the frontend ecosystem embraces new and more efficient frameworks and technologies. The browser provides everything one needs to build fast and responsive applications - It's an issue with incentives and culture more than anything to do with the fundamental tech.
- nyanpasu64 4y ago
  Will JavaScript-based web apps ever run as smoothly as FamiTracker (and to some degree Telegram Desktop) on a Core 2 Duo machine, or take up negligible memory (so you won't have to close some apps to start others) on today's 4-8GB machines? But then again, modern native apps are dog slow on old hardware; Visual Studio 2022 would hang for over 10 seconds at a time, but it's arguably excusable since it doesn't support running on Windows 7 which I was doing.
- hedora 4y ago
  This puts 100% of the trust on shared, high value server farms controlled by organizations that have a financial incentive to misuse people's data. Edit: I guess that meshes with the article title; assume other people's servers are compromised too.
chasil 4y ago
I do all my monetary transactions on an OpenBSD desktop with their Chrome port. This version of Chrome is a bit old (v93) but it is built with pledge(). I am running it on an older Core 2 Quad Q9550 where I have been able to completely remove the Intel ME malware (I posted the wiped bios elsewhere). I hope that this is enough.
hedora 4y ago
Does per-application isolation actually stop local privilege isolation in practice on any popular operating system? Even hypervisors routinely have security issues. How often does qubes sandbox get broken by a zero day?
- fsflover 4y ago
  > How often does qubes sandbox get broken by a zero day? Last time the hardware virtualization (which Qubes uses) was broken was in 2006, and it was done by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software). See also: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/.
eternityforest 4y ago
Or, just don't install viruses. On Linux I'm sure some AppArmor or flatpak whatever will be the norm one day, once all the kinks are worked out... but for now it seems to work surprisingly well to just not install stuff that isn't popular and trusted.
- Hackbraten 4y ago
  Maintainers of popular, trusted projects can get compromised. Hackers steal their publishing tokens and then publish a new, malicious version.
  - hedora 4y ago
    When did this last happen with Debian or Ubuntu? (which actively vet contributors, at least compared to pip and npm)
  - hanniabu 4y ago
    That's why I never update anything taps brain
  - eternityforest 4y ago
    It's not perfect, but it's still pretty good. Plus, if you update manually every few days and read tech news all the time, most malware will probably be discovered before you get it.
yjftsjthsd-h 4y ago
I don't think it's so much "ugly truths people try and sweep under the rug" as "we do not yet appear to have a practical way to actually do anything about it without vastly reducing the usefulness of the system". There are ways to improve things a bit with your choice of sandboxing tech, but those are frequently either ineffective (oh good, an attacker who compromises can only get to my bank account, but not my SSH keys), high-friction (flatpak portals are cool so long as you don't mind manually approving all file access), or both.
- ryukafalz 4y ago
  > flatpak portals are cool so long as you don't mind manually approving all file access And by “manually approving all file access” you mean “opening the file in the file picker like normal”, right? There are some apps where using a file picker at all is awkward, but I’d argue in most applications it’s basically what you’d do anyway. Certainly most applications that non-developers would use. The bigger problem is that lots of Flatpak applications still don’t use portals.
  - taeric 4y ago
    I remember my first time using a photo application in a flatpak, I had no idea how to get images it saved to a place I could then upload with my browser. It was rather frustrating.
    - kirbyfan64sos 4y ago
      Worth noting that Chromium upstream has support for the portals now, so this should be mostly fixed for that specific scenario.
elesiuta 4y ago
Something like fsverity could be a decent half solution. https://fedoraproject.org/wiki/Changes/FsVerityRPM https://fedoraproject.org/wiki/Changes/FsVerityRPM Of course you won't have that layer of isolation if something becomes compromised, but it should make it harder for malicious code to persist on your system without you knowing.
tetha 4y ago
> 2) Utilize some container runtime to provide isolation for legacy applications and stub out features such as filesystem calls so they do not to be aware of its existence. I've been thinking about doing this on my laptop at work. With a bit of thought, it shouldn't be too hard to run for example software compilation or in fact most CLI/TUI tools using a minimal disk and network namespace using systemd or a container runtime. Practically, this would allow me to put e.g. ever beloved NPM into a disk namespace where a ~/.ssh or even the .git of the repo it is in just doesn't exist and a network namespace in which the company VPN doesn't exist (or it just has a route for the NPM repository host). This can also be used to label the process using SELinux or apparmor as a second line of defense against and possibly after an escape of something bad. However, time hasn't been available for this so far. And no, it wouldn't be end-user-friendly.

slimsag 4y ago

UWP has also been deprecated[0] [0] https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp https://www.thurrott.com/dev/258377/microsoft-officially-dep...

walterbell 4y ago

Apple will likely launch Armv9 CPUs (iDevice A16 and MacBook M2) this year. If they don't enable CCA and memory tagging, then we have to wait for Armv9 support in QEMU and a future Qualcomm SoC, https://www.anandtech.com/show/16584/arm-announces-armv9-architecture https://www.anandtech.com/show/16584/arm-announces-armv9-arc... > CCA introduces a new concept of dynamically created “realms”, which can be viewed as secured containerised execution environments that are completely opaque to the OS or hypervisor. The hypervisor would still exist, but be solely responsible for scheduling and resource allocation. The realms instead, would be managed by a new entity called the “realm manager”, which is supposed to be a new piece of code roughly 1/10th the size of a hypervisor. > Applications within a realm would be able to “attest” a realm manager in order to determine that it can be trusted, which isn’t possible with say a traditional hypervisor. Arm didn’t go into more depth of what exactly creates this separation between the realms and the non-secure world of the OS and hypervisors, but it did sound like hardware backed address spaces which cannot interact with each other.

KMag 4y ago
That's great! The processor's hypervisor-like firmware should handle task switching, page table manipulation, etc, and the OS kernel should use upcalls to the firmware instead of needing to have various special-case paths for various minor hardware variants. Had the x86 BIOS been a bit better designed (and a bit more performant), we likely would have seen OS kernels leaning much harder on firmware that shipped with the processor instead of having to make as many assumptions about the hardware and special-case checks. Besides allowing for more easily isolated security domains, this allows things like (if properly designed) not needing to wait for kernel improvements to take advantage of more/wider vector registers or other changes that change the amount of processor state to serialize/deserialize when task switching. The DEC Alpha AXP worked somewhat like this with its PALCode firmware. The Tru64 UNIX (and Linux, *BSD, etc.) and VMS kernels actually were unable to execute the privileged CPU instructions. The OS kernel needed to make upcalls to the PALCode, which then could use privileged instructions and could see model-specific registers, etc. The PALCode version used for Tru64 emulated two protection rings, and the PALCode version used with VMS emulated more (I think 4) rings of protection by just keeping an extra integer around for each task, and using that to determine which tasks could currently make which upcalls. One could (and probably should) extend this ring emulation to a bit vector of per-task revokable capabilities that could be passed to child tasks/processes/threads. Hopefully we see something like this for RISC-V, using seL4 for the "realm manager". This would probably require an extra userspace driver process running to intermediate realm setup and manipulation, but wouldn't be in the critical path for system calls or other userspace drivers. We're already running hypervisors so many places that it makes sense to run a formally verified separation kernel everywhere, and run hypervisors and OS kernels as userspace daemons. This avoids the hypervisor needing to emulate hardware as an ad-hoc upcall mechanism and instead simplifies both the hypervisor and the OS kernel. The overhead of modern microkernels is so low that your cell phone's baseband processor is likely running an L4 microkernel. It's called paravirtualization when the OS kernel is modified to use upcalls to the hypervisor instead of trying to perform privileged operations that will be trapped (and then emulated) by the hypervisor. Paravirtualization improves VM performance and potentially sidesteps hypervisor emulation bugs, but it would simplify the kernel (and potentially make it easier to optimize) if OS kernels ran paravirtualized even when there is one guest OS per physical computerp Edit: Of course, there's a small performance hit in the single guest OS case, but if that's the common code path, presumably both hardware and the kernels could be better optimized. Also, if you're supporting OS-opaque realms, you're already paying this hypervisor cost all the time anyway.

greesil 4y ago

Does chrome OS do this?

est31 4y ago
Chrome OS has sandboxed developer environments, which is pretty neat: https://www.youtube.com/watch?v=pRlh8LX4kQI https://www.youtube.com/watch?v=pRlh8LX4kQI
hda111 4y ago
For using normal Linux applications, Chrome OS uses Linux Containers (LXD) running inside a VM.

mhoad 4y ago

Fuschia from Google also looks to have a very good solution to this problem but is probably still a couple of years away.

FabHK 4y ago
They should really pick a name that's easier to spell... https://en.wikipedia.org/wiki/Fuchsia_(operating_system) https://en.wikipedia.org/wiki/Fuchsia_(operating_system)
- mhoad 4y ago
  I should stop posting while drinking wine too it seems :)
- saagarjha 4y ago
  I just spell it the rude word it shares the first three letters with, swap out the k with an h, and then add "sia" to the end.

sva_ 4y ago

FireJail does at least some isolation

megous 4y ago

Per-application isolation sounds completely unworkable for a developer. Maybe per-customer isolation, or per-usecase isolation. Isolating customer work (or use case like "production deployment") into separate UNIX user accounts works fairly reasonably.

Ameo 4y ago

I think that the browser is going to eat the desktop/OS and that most apps will eventually be browser-based. PWAs are the initial movement in that direction. As browser APIs expand and support more use-cases through WebAssembly, WebGPU, native filesystem APIs, etc. more and more apps that were primarily or only available as native can be supported in the browser. I know that many people hate web apps because they're often slow, clunky, bloated, etc. but a lot of that is changing as the frontend ecosystem embraces new and more efficient frameworks and technologies. The browser provides everything one needs to build fast and responsive applications - It's an issue with incentives and culture more than anything to do with the fundamental tech.

nyanpasu64 4y ago
Will JavaScript-based web apps ever run as smoothly as FamiTracker (and to some degree Telegram Desktop) on a Core 2 Duo machine, or take up negligible memory (so you won't have to close some apps to start others) on today's 4-8GB machines? But then again, modern native apps are dog slow on old hardware; Visual Studio 2022 would hang for over 10 seconds at a time, but it's arguably excusable since it doesn't support running on Windows 7 which I was doing.
hedora 4y ago
This puts 100% of the trust on shared, high value server farms controlled by organizations that have a financial incentive to misuse people's data. Edit: I guess that meshes with the article title; assume other people's servers are compromised too.

chasil 4y ago

I do all my monetary transactions on an OpenBSD desktop with their Chrome port. This version of Chrome is a bit old (v93) but it is built with pledge(). I am running it on an older Core 2 Quad Q9550 where I have been able to completely remove the Intel ME malware (I posted the wiped bios elsewhere). I hope that this is enough.

hedora 4y ago

Does per-application isolation actually stop local privilege isolation in practice on any popular operating system? Even hypervisors routinely have security issues. How often does qubes sandbox get broken by a zero day?

fsflover 4y ago
> How often does qubes sandbox get broken by a zero day? Last time the hardware virtualization (which Qubes uses) was broken was in 2006, and it was done by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software). See also: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/.

eternityforest 4y ago

Or, just don't install viruses. On Linux I'm sure some AppArmor or flatpak whatever will be the norm one day, once all the kinks are worked out... but for now it seems to work surprisingly well to just not install stuff that isn't popular and trusted.

Hackbraten 4y ago
Maintainers of popular, trusted projects can get compromised. Hackers steal their publishing tokens and then publish a new, malicious version.
- hedora 4y ago
  When did this last happen with Debian or Ubuntu? (which actively vet contributors, at least compared to pip and npm)
- hanniabu 4y ago
  That's why I never update anything taps brain
- eternityforest 4y ago
  It's not perfect, but it's still pretty good. Plus, if you update manually every few days and read tech news all the time, most malware will probably be discovered before you get it.

yjftsjthsd-h 4y ago

I don't think it's so much "ugly truths people try and sweep under the rug" as "we do not yet appear to have a practical way to actually do anything about it without vastly reducing the usefulness of the system". There are ways to improve things a bit with your choice of sandboxing tech, but those are frequently either ineffective (oh good, an attacker who compromises can only get to my bank account, but not my SSH keys), high-friction (flatpak portals are cool so long as you don't mind manually approving all file access), or both.

ryukafalz 4y ago
> flatpak portals are cool so long as you don't mind manually approving all file access And by “manually approving all file access” you mean “opening the file in the file picker like normal”, right? There are some apps where using a file picker at all is awkward, but I’d argue in most applications it’s basically what you’d do anyway. Certainly most applications that non-developers would use. The bigger problem is that lots of Flatpak applications still don’t use portals.
- taeric 4y ago
  I remember my first time using a photo application in a flatpak, I had no idea how to get images it saved to a place I could then upload with my browser. It was rather frustrating.
  - kirbyfan64sos 4y ago
    Worth noting that Chromium upstream has support for the portals now, so this should be mostly fixed for that specific scenario.

elesiuta 4y ago

Something like fsverity could be a decent half solution. https://fedoraproject.org/wiki/Changes/FsVerityRPM https://fedoraproject.org/wiki/Changes/FsVerityRPM Of course you won't have that layer of isolation if something becomes compromised, but it should make it harder for malicious code to persist on your system without you knowing.

tetha 4y ago

> 2) Utilize some container runtime to provide isolation for legacy applications and stub out features such as filesystem calls so they do not to be aware of its existence. I've been thinking about doing this on my laptop at work. With a bit of thought, it shouldn't be too hard to run for example software compilation or in fact most CLI/TUI tools using a minimal disk and network namespace using systemd or a container runtime. Practically, this would allow me to put e.g. ever beloved NPM into a disk namespace where a ~/.ssh or even the .git of the repo it is in just doesn't exist and a network namespace in which the company VPN doesn't exist (or it just has a route for the NPM repository host). This can also be used to label the process using SELinux or apparmor as a second line of defense against and possibly after an escape of something bad. However, time hasn't been available for this so far. And no, it wouldn't be end-user-friendly.