6 ms·

> 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

> 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.

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.