Flatpak – a security nightmare – 2 years later (2020) • Hacker News Board

Re: Flatpak – a security nightmare – 2 years later (2020)

#251

Post by cheph » Sun, Mar 21, 2021, 6:47 PM UTC

krick wrote: post #125

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, a…

> Linux starts falling behind both MacOS and Windows in this regard

Last I installed something with windows it had full write access to my home directory and pretty much everything the user it was running as had access to. Is this no longer the case?

Re: Flatpak – a security nightmare – 2 years later (2020)

#252

Post by mdoms » Sun, Mar 21, 2021, 6:50 PM UTC

higerordermap wrote: post #71

gspr wrote: post #28

Earlier quoted context omitted.

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.

Calling opinions you disagree with "exhausting" is exhausting. And obnoxious.

Re: Flatpak – a security nightmare – 2 years later (2020)

#253

Post by takluyver » Sun, Mar 21, 2021, 6:53 PM UTC

andagainagain wrote: post #203

One thing that gets me about the sandbox of flatpak is that it doesn't seem to be up to the user. If the developer of the app chooses the permissions, then there isn't a fundamental difference for security from having all permissions anyways. Ideally a user installs the app and they would know, without reading anything else about the app, that the app is separate from their system. If any app you install is NOT separ…

You're thinking about malicious apps, where the developer would just request all permissions they can. But sandboxing is also about limiting the impact of security issues in apps from honest, well meaning developers who (hopefully) won't request more permissions than they need.

E.g. if I make a chat app, and it has a bug that lets someone send you a malicious message and execute code in the app, then a sandbox is a really good thing.

The developer also sets the default permissions - in principle, the user can change these before running the app. Of course, not many users will do that, but there are still cases where it can make a difference.

Re: Flatpak – a security nightmare – 2 years later (2020)

#254

Post by ziftface » Sun, Mar 21, 2021, 7:07 PM UTC

AdmiralAsshat wrote: post #235

kelnos wrote: post #16

Earlier quoted context omitted.

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

>The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many. The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc. It'…

Couldn't it be possible to ask the user to allow certain directories or files? It might be kind of annoying but it would be safer.

Also, it could integrate with the open file dialog and only allow the application to access files selected by the user, and nothing else. That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care. But that would be ideal since it's safe but also not annoying.

Re: Flatpak – a security nightmare – 2 years later (2020)

#255

Post by ziftface » Sun, Mar 21, 2021, 7:16 PM UTC

vetinari wrote: post #184

lambda_obrien wrote: post #171

Earlier quoted context omitted.

Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.

And then have a barrage of users complaining that their app packaged in flatpak doesn't work.

Easy, show a pop-up informing the user that the application tried to access so and so file, and if this was intentional, please click allow and try again.

Re: Flatpak – a security nightmare – 2 years later (2020)

#256

Post by vorticalbox » Sun, Mar 21, 2021, 7:17 PM UTC

andagainagain wrote: post #211

vorticalbox wrote: post #188

> The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed. All of these require access to the users data to actually function. GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media these apps have the same "problem" in snap requiring --classic to allow ac…

Question then - does flatpak require an explicit flag when installing them to access those files? Or is it as I assumed just "flatpak install"

I actually believe it's set in the flatpack, though I am unsure.

Re: Flatpak – a security nightmare – 2 years later (2020)

#257

Post by oxylibrium » Sun, Mar 21, 2021, 7:42 PM UTC

tsimionescu wrote: post #215

oxylibrium wrote: post #148

Earlier quoted context omitted.

I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundred…

> It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem. This isn't entirely true - you need something like Administrator access (so at least a UAC prompt) to create a Windows Service, whereas all software you run on Linux will normally have access to write to your .bashrc. Of course, if we're tal…

Not in my experience - for instance, Discord on Windows when I last used it can register itself to run on user login without ever needing UAC to install itself (it installs to %APPDATA%). It's been months though, so my memory can be hazy.

Re: Flatpak – a security nightmare – 2 years later (2020)

#258

Post by __turbobrew__ » Sun, Mar 21, 2021, 7:45 PM UTC

Koliakis wrote: post #170

syockit wrote: post #135

Earlier quoted context omitted.

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

I've been experimenting with Qubes and it's the only OS I'm aware of that adequately addresses this issue. It's not usable for non-technical users though without a lot of learning/training and it can be a bit tedious to use sometimes. I have all my personal data in its own isolated VM (Qube). I do all my browsing in another VM, which has its own home folder and no access to my personal VM. All my sensitive stuff like…

How is this different than running FreeBSD with a jail per application?

Re: Flatpak – a security nightmare – 2 years later (2020)

#259

Post by necovek » Sun, Mar 21, 2021, 7:54 PM UTC

oxylibrium wrote: post #129

necovek wrote: post #70

Earlier quoted context omitted.

The thing is that messaging is the important bit here. If I have Debian apt archives in my sources.list, I understand the risks, just like a pure Windows user does: other than bugs, you might be affected if someone hacks Debian/Microsoft and that's it (or, of course, someone internal to them decides to do it). Flatpaks/snaps are designed to be built by less-trusted parties and promise things they know they can't deli…

I decided to look at the messaging - the websites of both Flatpak[0] and Snap[1] make no claims about security, or about being "designed to be built by less-trusted parties". Both of them focus more heavily on the convenience of distribution than any user-facing benefits such as sandboxing. If you're referring to the GNOME Software "Sandboxed" badge, it still indicates that there are some universal properties of the…

"Convenience of distribution" is, by nature, targeted at application distributors which are not the end-users I (or the OP) claimed to be affected by the messaging.

So yes, I think the messaging in GNOME Software should be improved (hard for me to check on Ubuntu because it does not come with Flatpak support on by default).

Note that ".bashrc and similar" is a huge amount of files (just off the top of my head, .profile, .zshrc, .cshrc, .Xsession, .xinitrc, .ssh/config [for eg. ProxyCommand]... you get the gist).

Re: Flatpak – a security nightmare – 2 years later (2020)

#260

Post by Groxx » Sun, Mar 21, 2021, 8:05 PM UTC

foobar33333 wrote: post #89

Groxx wrote: post #73

Earlier quoted context omitted.

So the tradeoff is "weak sandboxing, or up-to-date security patches". TBH I don't know which I prefer. But I suspect the lack of security patches will continue to get worse and worse as time goes on.

The sandboxing is not always weak. On most apps its almost fully locked down and has access to only your downloads folder. Its only things like vscode which need everything. You can also manually set permissions using flatseal to lock it down as much as you want.

Putting a blue shield on "sandboxed" when allowing (write!) access to my home directory falls on the extreme side of "weak" to me.

Sure, they are capable of locking it down better. But they haven't in 2+ years. It shows where their priorities are.

Flatseal I'll have to look into though, thanks! A user-controllable method is always a plus, and I do love sandboxes. Most apps need very little access, and locking them down prevents a LOT of kinds of misbehavior, intentional or accidental.