@strypey They seem to set up a straw man to back up a trojan sudo script and PATH having . in it as a vuln. That seems like a dubious position to take when one is specifically talking about the os as a whole.

@strypey I think it's a matter of relativity. Yes, there're quite a few shortcomings of the Linux model for desktop regarding sandboxing. The problem, of course, is that the same (and much worse) can be said for all the more widely-used desktops out there. Added security results in added complexity and reduced usability. I'd argue that most of the attack vectors described are low risk for the typical scenario of a computer that is almost exclusively used by an individual + a few trusted people.

@lightweight I agree with you on this. Other operating systems such as Windows, MacOS, and BSDs all have these flaws too to varying degrees. I don't know of a single, production-ready, general purpose OS that isn't written in C.

Also, with Wayland on the way, that whole Flatpak/X11 issue is also quickly becoming a non-issue for many users.


@jbauer @strypey here's hoping. I want to give Wayland a proper spin, but haven't done so yet...

@lightweight @strypey true, making a desktop secure through the required implementation of policies would make certain things inconvenient. I see one of the points the author making is that desktops will be left insecure most of the time. For example, all it takes is installing some userland software (be it flatpak) which is vulnerable or itself malicious.

@strypey These are legit concerns. About 10 years ago I wrote a blog about how alias could be used to steal your sudo password, in my POC I was able to send credentials off to a pastebin and retrieve it later. This still works. Alias can be used to essentially implement a rootkit without root. Once you get root, you can kind of do whatever you want on linux. The kernel is already super bloated, so the only real answer is to add more bloat. Almost makes starting over sound appealing.

@strypey A lot of these vulns require already gaining access, which isn't exactly a trivial matter on many systems so assuming you can get in, then there is a lot of really bad stuff you can do... It's a big if and I think the risk for most users is blown out of proportion. With good sandboxing a lot of the damage an attacker could do could be mitigated significantly. Also things like tripwire help a lot, but there are ways out of sandboxes and you can alias tripwire.

@curufuin @strypey one of the main points was about installing user apps (flatpak) which aren't sufficiently security restrained. There's your local access right there.

@tomosaigon if Flatpak is packaged by Debian, then by Ubuntu, then checked for nonfree bits by Trisquel, I'm pretty confident the version of Flatpak distributed through the Trisquel repos has had more independent auditing than any part of Windows, or any nonfree part of MacOS. Now, if the sandboxing Flatpak applies to apps installed using it is flawed, it's still better than none (eg AppImage).


@tomosaigon there are all sorts of security concepts (Object Capabilities, Reproducible Builds etc) that will improve the whole situation as devs learn to apply them. But security is and will always be about managing risks, with different levels of predictability. The most vulnerable component in a computer system is usually the human user. It's never a purely technical discussion.


@strypey That's interesting but I don't see anything about Debian (nor Ubuntu) conducting any sort of security audit on all Flatpaks. Is there really such an initiative? @curufuin

@tomosaigon of course not ;) The whole point of tools like Flatpak, AppImage, and Snappy, is to route around the auditing done by distros, so desktop (and maybe now mobile) GNU/Linux users can have the latest versions of apps, right now. If they built in sandboxing that's effective in protecting users' systems from the devs of app (and especially the devs of app dependencies), and if that sandboxing is audited by distro package maintainers, that would be a good compro.

@tomosaigon @strypey right where? just because a vulnerability exists, doesn't mean it has or even can be successfully exploited to gain access, as I learned with buffer overflows, you are just as likely to crash a program as you are to get a shell in a lot of cases and I'm sure that applies to lots of other classes of vulnerabilities as well. Anyway, I know its possible obviously, just don't tend to work myself up about , you'll always miss something with security. flatpacks seem like a plus.

@curufuin I'm not even talking about actual buffer overflow-style vulnerabilities. It's really about lax/lacking policy. Is it still true that flathhub distributes apps which have open write permission to ~user ? And can just write any random commands into the user's login script (.bashrc, etc)? @strypey

@bob that was pretty much my first reaction. But my knowledge of security is limited and I wanted to check my biases. Got a range of intriguing of responses to that post.

It's not a problem, as long as you are award of it. Just don't run untrusted code as your main user.

Also, looks like the autgor has an all-or-nothing approach to security, and is unaware of the concept of threat models. The insistance on verified boot is one example of that.

Sign in to participate in the conversation
Mastodon - NZOSS

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!