5 ms·

I think this is a small step in the right direction. IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user

I think this is a small step in the right direction. IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. If you want to give that application access to everything your user has access to, that’s fine, but it shouldn’t be the default.

redprince 3y ago
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged. Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
- deleted 3y ago
  [deleted]
- rajamaka 3y ago
  I always find this take so weird. Do you audit every single line of code from OSS you use?
  - redprince 3y ago
    > Do you audit every single line of code from OSS you use? I audit some of it sometimes. I trust that other do the same. Many hands make light work.
    - pjmlp 3y ago
      Anyone that is mildly evolved with SecDevOps knows how much of theory that happens to be in practice.
      - htag 3y ago
        I'm unsure what your talking about. Surely SecDevOps would be mostly alerted when a vulnerability isn't caught by someone looking at OSS. Those vulnerabilities that are caught should be mostly invisible.
        pjmlp 3y ago
        Pentesting is also part of it.
  - matheusmoreira 3y ago
    I don't read every line of code but yeah. I think I spend more time reading code for curiosity's sake than actually using many programs. I absolutely read build system scripts, I won't run make until I know what's gonna happen. I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
    - supportlocal4h 3y ago
      So only people capable of auditing source code and build scripts deserve to be able to trust software? There should never be any other way to offer trustability?
      - oneshtein 3y ago
        So only people capable of auditing source code and build scripts are able to be maintainers of opensource packages for others.
        supportlocal4h 3y ago
        Perhaps you missed the part about not needing distro-specific packagers by providing a way to run third party apps without having to trust third party packagers. You can deny access to the camera or filesystem or network without ever auditing the source code and trust that the software cannot misbehave in that aspect. This isn't a knock on the value of package managers or maintainers. It's just an obvious step in better security. It seems silly to argue that integrity among package maintainers is the only safeguard we need. I personally like the little piece of plastic that my laptop has that slides across the built-in camera. It's not a software solution, or even an electronic safeguard. It's even better than the little DIP switch on my phone. I say, why not?
        matheusmoreira 3y ago
        We could have both though. They aren't mutually exclusive. Also important is the option to intercept system calls and return fake data to the software. Give it a silent audio, black video, a limited view of the file system. That lets us control proprietary software that gets pissy when permissions are denied.
- microtonal 3y ago
  This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. It is a program that reads unstrusted binary blobs (many document formats) using C++ deserialization code that has a history tracing back to the nineties and even eighties (through StarOffice). I sure as hell want such an application to be sandboxed and ask for elevated permissions. This is pretty normal on other platforms like macOS (Office and iWork from the Mac App Store run sandboxed), iOS, and Android. Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would. You need more than policies. E.g. if a program cannot read outside its sandbox, you need some way to mediate access to files/directories on the user's request, which are provided by e.g. Flatpak/XDG desktop portals.
  - redprince 3y ago
    > It is a program that reads unstrusted binary blobs When opening any office files from unknown or untrusted sources is something you feel you have to do, you're probably well off isolating that operation and thus limit the blast area. For people working exclusively on their own files or with trusted colleagues, that is pretty much a non issue.
    - tredre3 3y ago
      Why do you keep moving the goalposts? First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine? So I need to spend thousand of hours reading libreoffice's and its dependencies' code, and then I still need to run it in a virtual machine when I read untrusted files (in case there are bugs that could be exploited)? It makes zero sense to keep pushing that nonsense when the alternative is to sandbox apps to begin with. It makes EVERYBODY safe from backdoors and bugs, for FREE. Why do you fight it?
      - redprince 3y ago
        > First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine? Because of an intended functionality of many of those file formats, which makes them quite dangerous when coming from untrusted sources: Macros.
- kaba0 3y ago
  You don’t need malicious app to cause harm without a sandbox. Malicious data with a bug is enough. Sandboxes should be the must in this century and mobile OSs are much more ahead here.
- bzzzt 3y ago
  > This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged. Compressed source code archive is over 300Mb. That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
  - redprince 3y ago
    > Compressed source code archive is over 300Mb. Much of it not interesting security wise. > That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed. I settle for people thinking like attackers and going for the attack surfaces.
    - Gigachad 3y ago
      It's C++, the whole thing is interesting security wise.
  - dralley 3y ago
    I imagine that includes assets.
    - josefx 3y ago
      And includes none of the dependencies used.
bonzini 3y ago
> I think this is a small step in the right direction Yeah, I am obviously biased because I am a Red Hat employee but the truth is the Flatpak model makes a lot of sense for large desktop applications (LibreOffice, OBS, etc.) that anyway do Windows releases and therefore have to track vulnerabilities in their dependencies and release updates. It may take a while to get used to it, but Red Hat has done a lot of infrastructure work to make this sandboxing possible (in RPM ostree, Flatpak, GTK+/GLib, PipeWire and many more places) and it's not a bad thing if they decide that the work is mature enough for them to reap the benefits.
hulitu 3y ago
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. Why would LibreOffice need access to microfone or location ? Asking for a friend.
- jolux 3y ago
  It shouldn’t, that’s the point.
- bombcar 3y ago
  PowerPoint let’s you record audio and video for slide presentations- I could see libreoffice having something similar.
hakfoo 3y ago
That tends to wave away the responsibilities of the distributor. The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) If you just hand everything off to external self-contained images, you lose a lot of that. I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps. Taken to an extreme, a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.
- bonzini 3y ago
  > a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. No, it looks a lot like Android or iOS, where the OS vouches for what the app can and cannot do instead of the distributor and there are no privileged scripts running at installation time. You can try it already with Fedora Silverblue. > be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) That's true, this is potentially something that is lost for interested people.
  - hakfoo 3y ago
    The point was less about the permissions themselves, and more that you're replacing a centralized "everything you want is in one ISO" model to having to retrieve a bunch of packages from third parties after the end of "the main install".
blablabla123 3y ago
It's all open-source and auditable, so any odd application behaviour should be prevented in the first place. Sandboxing is great but cgroups are not a sandbox. I think the post shows also that the main problem is amount of maintenance for many distributions. Maybe better package tooling would help - in the end Flatpaks are just a middleway between completely integrated packages and distributing everything as a self-contained tarball.
- Gigachad 3y ago
  Multiple layers of security. Yes in theory I could audit millions of lines of C++ code to see that LO does not access the microphone, but I also like that the sandboxing layer prevents it from happening entirely. I'd rather audit a permissions list than an entire codebase.
WhyNotHugo 3y ago
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. But Flatpak doesn't ask the user to confirm any permissions, it silently grants any permissions that the application manifest might specifies. OTOH, you don't need to change the packaging system to add sandboxing. It's perfectly feasible to sandbox with firejail or even just plain bubblewrap.
JohnFen 3y ago
> Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. I think I understand this stance, but really, I would consider this to be a terrible outcome. If that's the direction things are going, I really need to stop procrastinating my move away from Linux entirely.

redprince 3y ago

> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged. Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.

deleted 3y ago
[deleted]
rajamaka 3y ago
I always find this take so weird. Do you audit every single line of code from OSS you use?
- redprince 3y ago
  > Do you audit every single line of code from OSS you use? I audit some of it sometimes. I trust that other do the same. Many hands make light work.
  - pjmlp 3y ago
    Anyone that is mildly evolved with SecDevOps knows how much of theory that happens to be in practice.
    - htag 3y ago
      I'm unsure what your talking about. Surely SecDevOps would be mostly alerted when a vulnerability isn't caught by someone looking at OSS. Those vulnerabilities that are caught should be mostly invisible.
      - pjmlp 3y ago
        Pentesting is also part of it.
- matheusmoreira 3y ago
  I don't read every line of code but yeah. I think I spend more time reading code for curiosity's sake than actually using many programs. I absolutely read build system scripts, I won't run make until I know what's gonna happen. I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
  - supportlocal4h 3y ago
    So only people capable of auditing source code and build scripts deserve to be able to trust software? There should never be any other way to offer trustability?
    - oneshtein 3y ago
      So only people capable of auditing source code and build scripts are able to be maintainers of opensource packages for others.
      - supportlocal4h 3y ago
        Perhaps you missed the part about not needing distro-specific packagers by providing a way to run third party apps without having to trust third party packagers. You can deny access to the camera or filesystem or network without ever auditing the source code and trust that the software cannot misbehave in that aspect. This isn't a knock on the value of package managers or maintainers. It's just an obvious step in better security. It seems silly to argue that integrity among package maintainers is the only safeguard we need. I personally like the little piece of plastic that my laptop has that slides across the built-in camera. It's not a software solution, or even an electronic safeguard. It's even better than the little DIP switch on my phone. I say, why not?
        matheusmoreira 3y ago
        We could have both though. They aren't mutually exclusive. Also important is the option to intercept system calls and return fake data to the software. Give it a silent audio, black video, a limited view of the file system. That lets us control proprietary software that gets pissy when permissions are denied.
microtonal 3y ago
This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. It is a program that reads unstrusted binary blobs (many document formats) using C++ deserialization code that has a history tracing back to the nineties and even eighties (through StarOffice). I sure as hell want such an application to be sandboxed and ask for elevated permissions. This is pretty normal on other platforms like macOS (Office and iWork from the Mac App Store run sandboxed), iOS, and Android. Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would. You need more than policies. E.g. if a program cannot read outside its sandbox, you need some way to mediate access to files/directories on the user's request, which are provided by e.g. Flatpak/XDG desktop portals.
- redprince 3y ago
  > It is a program that reads unstrusted binary blobs When opening any office files from unknown or untrusted sources is something you feel you have to do, you're probably well off isolating that operation and thus limit the blast area. For people working exclusively on their own files or with trusted colleagues, that is pretty much a non issue.
  - tredre3 3y ago
    Why do you keep moving the goalposts? First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine? So I need to spend thousand of hours reading libreoffice's and its dependencies' code, and then I still need to run it in a virtual machine when I read untrusted files (in case there are bugs that could be exploited)? It makes zero sense to keep pushing that nonsense when the alternative is to sandbox apps to begin with. It makes EVERYBODY safe from backdoors and bugs, for FREE. Why do you fight it?
    - redprince 3y ago
      > First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine? Because of an intended functionality of many of those file formats, which makes them quite dangerous when coming from untrusted sources: Macros.
kaba0 3y ago
You don’t need malicious app to cause harm without a sandbox. Malicious data with a bug is enough. Sandboxes should be the must in this century and mobile OSs are much more ahead here.
bzzzt 3y ago
> This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged. Compressed source code archive is over 300Mb. That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
- redprince 3y ago
  > Compressed source code archive is over 300Mb. Much of it not interesting security wise. > That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed. I settle for people thinking like attackers and going for the attack surfaces.
  - Gigachad 3y ago
    It's C++, the whole thing is interesting security wise.
- dralley 3y ago
  I imagine that includes assets.
  - josefx 3y ago
    And includes none of the dependencies used.

bonzini 3y ago

> I think this is a small step in the right direction Yeah, I am obviously biased because I am a Red Hat employee but the truth is the Flatpak model makes a lot of sense for large desktop applications (LibreOffice, OBS, etc.) that anyway do Windows releases and therefore have to track vulnerabilities in their dependencies and release updates. It may take a while to get used to it, but Red Hat has done a lot of infrastructure work to make this sandboxing possible (in RPM ostree, Flatpak, GTK+/GLib, PipeWire and many more places) and it's not a bad thing if they decide that the work is mature enough for them to reap the benefits.

hulitu 3y ago

> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. Why would LibreOffice need access to microfone or location ? Asking for a friend.

jolux 3y ago
It shouldn’t, that’s the point.
bombcar 3y ago
PowerPoint let’s you record audio and video for slide presentations- I could see libreoffice having something similar.

hakfoo 3y ago

That tends to wave away the responsibilities of the distributor. The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) If you just hand everything off to external self-contained images, you lose a lot of that. I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps. Taken to an extreme, a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.

bonzini 3y ago
> a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. No, it looks a lot like Android or iOS, where the OS vouches for what the app can and cannot do instead of the distributor and there are no privileged scripts running at installation time. You can try it already with Fedora Silverblue. > be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) That's true, this is potentially something that is lost for interested people.
- hakfoo 3y ago
  The point was less about the permissions themselves, and more that you're replacing a centralized "everything you want is in one ISO" model to having to retrieve a bunch of packages from third parties after the end of "the main install".

blablabla123 3y ago

It's all open-source and auditable, so any odd application behaviour should be prevented in the first place. Sandboxing is great but cgroups are not a sandbox. I think the post shows also that the main problem is amount of maintenance for many distributions. Maybe better package tooling would help - in the end Flatpaks are just a middleway between completely integrated packages and distributing everything as a self-contained tarball.

Gigachad 3y ago
Multiple layers of security. Yes in theory I could audit millions of lines of C++ code to see that LO does not access the microphone, but I also like that the sandboxing layer prevents it from happening entirely. I'd rather audit a permissions list than an entire codebase.

WhyNotHugo 3y ago

> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. But Flatpak doesn't ask the user to confirm any permissions, it silently grants any permissions that the application manifest might specifies. OTOH, you don't need to change the packaging system to add sandboxing. It's perfectly feasible to sandbox with firejail or even just plain bubblewrap.

JohnFen 3y ago

> Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. I think I understand this stance, but really, I would consider this to be a terrible outcome. If that's the direction things are going, I really need to stop procrastinating my move away from Linux entirely.