Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak – a security nightmare

flatkill.org

Post reply on HN
Print view View original

171–180 of 264 posts

Re: Flatpak – a security nightmare

#171

Post by djsumdog »

Ugh. This trade off again. Linux package management means you update a library once, and fix that security problem everywhere for all the apps that use that library .. except for Firefox, Libreoffice, Chrome and others which insist on packaging their own versions of libjpeg, libpng and everything under the sun for stability.

A docker container contains all its own dependencies too. You gain stability .. but you could have a bedbug nest of security problems down there.

I don't get the move to Flatpack and Snap for desktop apps. Desktop apps need to interact with the base OS, the display system (X11 or Wayland) the shared toolkit libraries (GTK/QT). I've screenshots of native vs Flatpack vs Snap and they tend to have different window borders, some get the GTK themes matched up while others don't.

Not to mention the wasted space when every single application has its own version of everything. What, did you think electron apps each packaging their own 80MB web browser was a good idea too?

This just seems like the wrong direction to move in for Linux. We're not MacOS! We don't have hacked together shit like Android apks. We need to be better than that!

Re: Flatpak – a security nightmare

#172

Post by danilocesar »

yellowapple wrote: post #147
michaelmrose wrote: post #118

Earlier quoted context omitted.

Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion. In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed. In a flatpak not designed to be properly sandboxed y…

In flatpak you are worse off, though, since - as the article indicates - they lag behind on security updates. If they get compromised by unpatched exploits, that sandbox is a valuable line of defense.

The writer tries to blame Flatpak for app maintainers mistakes. That isn't fair.

If an app doesn't get an security fix whoever maintains that package should be the one to blame.

Disclaimer: I don't like flatpak either, I'm just trying to be fair here...

Re: Flatpak – a security nightmare

#173

Post by AnIdiotOnTheNet »

Ecco wrote: post #19
TeMPOraL wrote: post #7

Earlier quoted context omitted.

Domains are cheap. Often free for one year.

Well they’re “free” if you buy them alongside hosting. Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc...

> Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc..

I am among the laziest people I know and even I'm raising an eyebrow at this statement.

Re: Flatpak – a security nightmare

#174

Post by Reelin »

AnthonyMouse wrote: post #149
altfredd wrote: post #104

Earlier quoted context omitted.

There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before. Programmers like to come up with clever wa…

> Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. That is not very good. Suppose you create an audio file with Audacity and a series of images with ImageMagick and GIMP, then use ffmpeg to combine them into a video and VLC to view it. They're all operating on the same files. What we need is to add an application list to filesystem ACLs and then have security groups like…

Very much this. Something resembling an arbitrary number of groups per file (essentially a set of tags) and an analogous (arbitrarily numerous) set of tags applied to a process which match the launched binary. Bonus points if file format or other characteristics can somehow be worked in to automate things a bit while still maintaining security. A simple tagged group membership approach like this seems like it would be reasonably easy to use without getting in your way.

Does anything remotely resembling this already exist?

Edit: Before anyone says that SELinux resembles this, as far as I'm aware SELinux policies are anything but simple to set up and use correctly. However, SELinux types are inherited from parent directories and do look an awful lot like this. The main thing missing would seem to be that I can't find how to apply multiple contexts or types to a single file, but perhaps I'm just failing to navigate the manual?

Re: Flatpak – a security nightmare

#175

Post by m45t3r »

yzmtf2008 wrote: post #109
untog wrote: post #103

Earlier quoted context omitted.

It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.

macOS does this via the open dialog — opening a directory gives an application full access to that directory

And you can have the same issue the author said in the article by requesting access to home directory and running the exactly the same command as the author wrote.

Re: Flatpak – a security nightmare

#176

Post by jonstewart »

derefr wrote: post #148
jessaustin wrote: post #78

Earlier quoted context omitted.

The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.

It's a sandbox like Android has a sandbox: each app lists a set of capabilities; the user gets a dialogue on installation where they have to grant those capabilities (or else cancel the install); and then for anything the app tries to do that's not in that set of capabilities, it fails. A sandbox doesn't mean "you can never do [foo]." A sandbox means "you can never doo [foo] unless the user lets you." Even web browse…

Is it also like Android's "sandbox" in that every application asks for every permission and the only choice is between "no security" and "can't install anything useful" and inures the user to just click "accept" on everything?

Re: Flatpak – a security nightmare

#177

Post by TeMPOraL »

ReverseCold wrote: post #41
TeMPOraL wrote: post #22

Earlier quoted context omitted.

Do you open your files in PyCharm or VSCode through a file picker?

You open the parent project directory, right? That's how the file access controls work in MacOS. Sandboxed apps can't read files outside their sandbox until the user opens the directory/file in the file picker at least once. (Or something similar, I can't seem to find a source on that...)

Ah, ok. Makes more sense this way.

Re: Flatpak – a security nightmare

#178

Post by TeMPOraL »

Ecco wrote: post #36
TeMPOraL wrote: post #27

Earlier quoted context omitted.

> Well they’re “free” if you buy them alongside hosting. Depends on hosting company. I've "bought" domains for free many times, without hosting, just to run joke sites for few months.

Ha, interesting! I always assumed a .org was at least a dollar. Mind sharing a link?

Don't have a free "org" source; maybe they never was. Free domains I got were under national TLD.

Re: Flatpak – a security nightmare

#179

Post by DCKing »

vanderZwan wrote: post #6

> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security. Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion l…

The article is really over the top hostile. 'Flatkill', 'Fakepak', 'Red Hat does not care about security'. What intentions could the author possibly have?

Re: Flatpak – a security nightmare

#180

Post by gmueckl »

TheDong wrote: post #65
gmueckl wrote: post #15

Earlier quoted context omitted.

Most of the issues that are expicitly mentioned are fixable bugs and not fundamental design errors. In the end it seems to come down to poor package repository maintenance, which many repositories for Linux distros suffer from. While I do not like the idea of flatpak very much myself, this criticism seems too harsh to me.

The fact that many desktop applications need access to $HOME and that $HOME also conveniently provides arbitrary code execution via .bashrc/.profile/etc is kinda fundamentally at odds with doing filesystem sandboxing of desktop apps. Sure, flatpak isn't making things worse by not being able to fix the fact that desktop users expect to open $HOME/screenshot.png in gimp, but it's also not going to easily fix that. This…

Forcing applications to use a separately defined and maintained file dialog is impractical in my opinion. There are lots of ways in which file access can be presented in a user interface.

The problem is rather caused by filesystem layout conventions. I think that a better solution would be to split user home directories into two classes of files: data (that is, files that the user typically wants to see and work with as part of the normal workflow) and "user profile" kind of stuff (.bashrc, configuration files, etc...) that should be "privileged" and require special access rights. These might require interactive confirmation before write access is granted (similar to the split user accounts in Windows with UAC). However, I wonder if these sets of files can be separated cleanly. Marking files as "privileged" should be doable using extended attributes, though.

Post reply on HN