undefined | Better HN

0 pointsdanShumway4y ago0 comments

Unless you're running something like Firejail on your system, yes they are.

There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. We know that isolation/sandboxing (and in particular filesystem isolation) is going to be an important part of security moving forward.

And if you're comparing this to Android/iOS, it's not even a contest, Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all; and repositories like FDroid allow you to set upstream maintainers the same way that you would in desktop Linux environments.

If you compare this to the web, it becomes even more obvious that resource/runtime isolation between sites improves security. Increasingly we're looking at not even sharing browser caches between domains, which is even more strict than Flatpak's shared runtimes. Isolation is a failsafe -- it means if something breaks or gets infected, it can't affect everything. It means that remote code injection into a properly sandboxed app can only compromise one app, and not overwrite your bashrc and insert random keyloggers into everything you do.

Improvements still to be made, I would not today assume that Flatpak is secure or battle-tested, and it definitely can't do much about X11. But we fix these things piece by piece, and the basic idea itself is still sound.

0 comments

goodpoint4y ago

> Unless you're running something like Firejail on your system, yes they are.

Which I am, but this is besides the point.

> There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire.

Please don't spread FUD. Perfection does not exist in this world but Linux is used in most security critical environments in the world, from banks to military applications to security devices like firewalls.

> But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get.

Sandboxing and installation tools like apt-get are completely orthogonal topics. Flatpak blurs the line and people get confused.

Furthermore, sandboxing can be effective only if the whole UX is designed and tested centrally.

Applications need access files in ways that are compatible with each other and useful for the end users.

Policies need to be written and reviewed by a trusted organization.

You can't rely or random upstream authors to configure sandboxes for different applications independently from each other.

Sample the sandbox settings on some flatpak applications and you'll find they range from too strict to completely lax.

> Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all

And yet the phones are full of spyware/telemetries antifeatures.

> I would not today assume that Flatpak is secure or battle-tested

It's not.

danShumwayOP4y ago

> Please don't spread FUD.

Oh this isn't FUD, the fact that Linux is used in secure environments does not mean that Linux's default security model for user applications is good -- it's not, this is a well-recognized problem in the security industry and it's been discussed to death already. I say this as a person who runs Linux on literally every single computer that I own, I say this as someone who literally does not have a Windows install on my entire network outside of a VM.

I'm not discouraging people from running Linux, quite the opposite. Even though Linux's security model is a dumpster fire, it's still currently better for most users to run Linux. And I don't just run Linux, I main Linux on practically everything I own, I'm desperately hoping that within the next few years I'll be running Arch on my phone. But that doesn't change anything about Linux security, we all know that X11 is insecure. We all know that the /home directory paradigm most distros use is a disaster. This stuff isn't FUD, it's well-established truth, and at this point anyone who's trying to claim that sharing /home access with every app is acceptable security design has their head stuck in the sand.

And frankly, part of the reason why Linux has security problems is because of these ridiculous articles that suggest that good security is a binary all-or-nothing approach to trusting applications, rather than a partial trust model where applications are granted the least number of privileges possible for them to run, and where we build security in depth by progressively layering restrictions on top of applications.

----

> sandboxing and installation tools like apt-get are completely orthogonal topics.

On some level I agree, which is why it's frustrating to me that people treat bundling/sandboxing tools like Flatpak as if they're somehow a paradigm shift in maintainer roles that are disrupting app distribution, when they're not.

But on another level, they are related -- you're here arguing that upstream is better equipped to handle moderation and patching than users are, and more likely to fix vulnerabilities than individual software developers. From that perspective, of course those maintainers should have mechanisms to set sandboxing rules for the software they include in their distros. It makes perfect sense to have ways for upstream packagers to set default sandboxing rules.

For better or worse, installation in Linux requires placing files on the filesystem. Because of how tools like OverlayFS work, it becomes important to care about where those files get placed. You actually mention this yourself later on when you bring up that "sandboxing can only be effective if the whole UX is designed and tested centrally." There are a lot of features in application sandboxing/management (file access, installation rollback, distro policies about security manifests, etc) that are much easier to build if we think about them from the beginning with installation, if "the whole UX is designed and tested centrally."

----

> [X] need [X]

Most of this is stuff that Flatpak explicitly is designed to help with, so I don't really understand what your problem is with the direction we're going. The stuff you're complaining about are problems with the existing Linux security model where people try to use crud like separate users to control file access, you should be happy that the Linux community is trying to address these problems.

Flatpak portals are an attempt to get rid of many of the manifest controls. It's designed to integrate with central UXes like Gnome/KDE (ironically, the original article somehow brings this up as a criticism, that Flatpaks aren't self-contained enough, even though it makes no sense to have user-facing controls be managed by Flatpak itself rather than the Desktop Environment).

And "you can't rely on random upstream authors" is exactly what I'm talking about with the middleperson maintainers like Debian or users themselves having control over what the manifest files are, and is (despite the article's objections) exactly why it's so important that Flatpak permissions not require code changes from the applications being bundled[0].

There's nothing that prevents Debian maintainers from building their own Flatpak manifests. See above about correlating upstream/distro management and a bundling/sandboxing tool, these are orthogonal concepts.

----

> And yet the phones are full of spyware/telemetries antifeatures.

So many of the problems with Linux security can be summed up with this line. Linux gets a lot of benefit from being an environment with proper developer incentives. The majority of the software is Open Source, and the majority of software is developed with both heavy community involvement and without strong incentives towards spyware/malware. There is a strong anti-commercial, even anti-Capitalist bent from a nontrivial percentage of Linux software authors and distributors, and an even stronger shared philosophy about user freedom that makes the entire ecosystem hostile to common exploitative software practices. Additionally, low consumer adoption and a high level of technical skill from the average user make it even harder for malicious programs to thrive.

All of that is orthogonal to secure architecture, it's the equivalent of moving into an upscale neighborhood with friendly neighbors and claiming that your unlocked patio door is now more secure than a window with bars on it.

There's a real (in my mind) anti-security mindset in the Linux community that stems from "if the neighborhood stays nice, we don't need to think about security." And I reject that entire philosophy; from an architectural perspective Android is unambiguously more secure than most desktop Linux distros by default. It has to be, because people actually write malware for Android, and nontechnical users use it. This is the same situation that pops up on the web: native developers for desktop complain about the Internet "enabling" spyware. But the web doesn't enable spyware; the web does a really stinking good job at mitigating privacy violations. The truth is rather that native doesn't have to mitigate spyware to the same degree, because nobody wants to embed a malicious tracker in your Open Source CLI tool, they want to embed those trackers into Farmville.

As Linux gains more mainstream adoption as a consumer-grade desktop OS (and Linux genuinely is progressively getting better and better, and even more attractive/competitive as a consumer-grade desktop OS), it will become more important for the community to care about architectural security and not just keeping the community nice.

Having a good community is not the same thing as having good security. Consumer-grade, general desktop Linux has a fantastic community, and in practice you will be less likely to encounter malware on a Linux system. But consumer-grade, general desktop Linux does not have strong security fundamentals outside of the server (or perhaps more accurately, it does have some strong security fundamentals, but requires tools like Flatpak/Firejail/Wayland to start enforcing them and to start moving concepts like OverlayFS and process isolation out of of technical kernel tools and into general user-facing tools for the non-technical Gnome user).

----

> It's not.

It is reasonable to have criticisms that Flatpak as it stands today still has security holes and issues. As I mentioned above, Linux security is in general a dumpster fire. Just as one exapmle, Flatpak is useless if you're not running Wayland. It will benefit from some of the additional sandboxing capabilities that are being built into the kernel now[1]. And we need to get stricter about actually using the file access controls built into Flatpak.

All of this is a separate criticism from the direction Flatpak is going. There is a difference between saying that Flatpak as a technology is the wrong direction for Linux, and saying that it needs better portal controls.

The latter criticism is completely accurate. The former is based on an incorrect assumption that Flatpak somehow destroys the entire Linux app distribution model and puts the entire Debian team out of a job, even though Flatpak as a technology has nothing to do with where users ultimately get their software or whether upstream maintainers can patch software and add custom security rules to that software.

----

[0]: I go into this in more detail at https://news.ycombinator.com/item?id=29321150

[1]: Incidentally, so will Firejail. There's not that much wild conceptual difference between Bubblewrap and Firejail other than UX and a commitment from Bubblewrap not to ever ask the for root access while creating containers.

j / k navigate · click thread line to collapse