1. 13

  2. 12

    Flatpack and snap are both security nightmares, fundamentally flawed and poorly implemented.

    This quote links to “flatkill.org”, a page that’s always posted when flatpak is discussed. It’s usually taken as a ultimate argument against flatpak, but at least according to some sources the criticism seem out of date. I’ve started using flatpak when quarantine required me to use certain propitiatory apps (mainly Zoom), and it seems to be doing the sandbox job quite well. So I’d say that this kind of containerisation is an improvement that should be regarded as such.

    Then the (so-called) Linux desktop also has the edge that most/as much as possible of the software is Free, making it easier for distributions to implement reproducible builds systems, that also aid security.

    1. 9

      This article seems hallow and and poorly researched, frankly.

      Also a friendly reminder that Debian is always behind on CVEs, and I’m sure that most distros don’t fare any better.

      Yes, but Debian is a volunteer effort. CVEs are a massive mess and hard to track. Of course they are behind on CVEs, but then no volunteer distribution fares better then Debian either.

      It’s also a bit telling that they haven’t paid attention to the recent developments of reproducible builds, which is very important for free-software distributions.

      1. 10

        I think the most glaring error it makes is trying to lump all Linux distros together, and then pointing out only the worst parts of that big lumpy mess. Nothing about selinux in there, for instance. Nothing about Wayland. Nothing even about Gentoo or other security-focused distros… etc, etc. And that leads to imputing false trade-offs.

        Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. – Benjamin Franklin

        1. 3

          I agree. I was quite disappointed with the article itself. The link to Daniel Micay’s thoughts was worth it though. If you’re interested in Android security too, there are some more informative comments from him up-thread.

        2. 9

          The last thing Linux userspace has done is ASLR/PIE and stack canaries: this hasen’t changed for years. Windows and MacOS enforce signature checking on all binaries. glibc’s allocator is primitive compared to LLVM’s Scudo allocator, which mitigates use-after-frees and heap overflows.

          This is such an odd paragraph. Signing is something from a completely different area than binary hardening. Windows and macOS only enforce signature checking if you use walled garden app stores exclusively, everyone else relaxes the checking in settings.

          No mainstream OS uses these security-focused allocators, because most people love performance too much. Fun fact about allocators though, jemalloc (used by FreeBSD) is not vulnerable to stupid linked list exploits, and even phkmalloc wasn’t :)

          Windows signs heap pages to ensure they’re immutable, in addition to hardware-enforced control flow protection

          Don’t get too excited about the hardware enforced thing (Intel CET): it’s only available starting with the upcoming Tiger Lake. And AMD is better in general anyway :P

          The only good sandoxing API provided by the Linux kernel is seccomp-bpf, and the only program that uses it is Google Chrome/Chromium

          seccomp-bpf is a nightmare tbh, but Firefox also uses it of course.

          1. 4

            Linux distros have no concept of sandboxing, or any meaningful application security model. Any app running under Xorg can see the contents of any other app runing under Xorg.

            In practice, I find this isn’t really that much of a problem. How many people have fallen victim to a malicious app snooping on their screen or clipboard? Part of the reason for this is that 1) most Linux users tend to “power users”, and more or less know what they’re doing, and 2) tend to install software from packaging instead of random adverts, Google results, or whatnot.

            Not that sandboxing applications is a bad idea as such, but for user-facing software (i.e. stuff that isn’t a daemon) the UX problems are real and non-trivial to solve. The classic of example of this is the “screenshot problem” under Wayland, which seems to be partly solved but with a rather complex mechanism which doesn’t work everywhere.

            1. 2

              I think Android has actually shown us that sandboxing applications is a bad idea, at least if taken too far. Android’s over-zealous sandboxing is one of the main reasons people have to resort to exploiting security holes, gaining root on their own device, just so syncthing can backup a folder from the SD card. And similar terribleness. The fact that every app by default has a tiny folder it puts its data in and nothing else can see that folder is just a nightmare. This is one of the reasons I have avoided Android like the plague, and why people are flocking to things like the PinePhone.