3 ms·

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain

by necovek 8mo ago

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks. But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical. As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you will be running untrusted applications as one: on the contrary, if you assume an administrator role and run an untrusted application, naturally, all bets are off. But even as a power user, I'd love to be able to safely run programs I do not necessarily trust, feeding it only data it needs and no more. Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.

microtonal 8mo ago
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks. What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc. Sandboxing also protects against external attacks. Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software. Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them. The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).
- palata 8mo ago
  Agreed. I want to "own my device" as in "being able to install the system I want on it". Not as in "I want it to behave exactly like Desktop Linux", or whatever it is that people complain about AOSP. On my Desktop I love Linux. But on my smartphone, I want AOSP.
  - microtonal 8mo ago
    Largely agreed, though I think on the desktop I’d also want AOSP in desktop mode with a traditional Linux distribution in a VM pretty much like Android 16’s Linux VM. But then on desktop/laptop-class hardware, since the thermal constraints are different and it’s nice to have extensible storage and RAM. Of course, all this on the phone is also nice for when you only have your phone with you. Then one could use fully sandboxed apps for banks, instant messaging, etc. and the VM for development. AOSP is getting pretty close to this ideal.
    - palata 8mo ago
      > AOSP is getting pretty close to this ideal. Yes I can totally imagine that in a few years, most people will only need a smartphone and a dock station. At home, they will plug their phone (iOS, Android, whatever) to their dock station and it will behave as a Desktop. And it will be good enough for everything they do.
- iggldiggl 8mo ago
  > What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.) So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…? Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.

by necovek 8mo ago

microtonal 8mo ago

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks. What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc. Sandboxing also protects against external attacks. Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software. Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them. The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).

palata 8mo ago
Agreed. I want to "own my device" as in "being able to install the system I want on it". Not as in "I want it to behave exactly like Desktop Linux", or whatever it is that people complain about AOSP. On my Desktop I love Linux. But on my smartphone, I want AOSP.
- microtonal 8mo ago
  Largely agreed, though I think on the desktop I’d also want AOSP in desktop mode with a traditional Linux distribution in a VM pretty much like Android 16’s Linux VM. But then on desktop/laptop-class hardware, since the thermal constraints are different and it’s nice to have extensible storage and RAM. Of course, all this on the phone is also nice for when you only have your phone with you. Then one could use fully sandboxed apps for banks, instant messaging, etc. and the VM for development. AOSP is getting pretty close to this ideal.
  - palata 8mo ago
    > AOSP is getting pretty close to this ideal. Yes I can totally imagine that in a few years, most people will only need a smartphone and a dock station. At home, they will plug their phone (iOS, Android, whatever) to their dock station and it will behave as a Desktop. And it will be good enough for everything they do.
iggldiggl 8mo ago
> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.) So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…? Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.