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

231–240 of 264 posts

Re: Flatpak – a security nightmare

#231

Post by MayeulC »

gmueckl wrote: post #26
dralley wrote: post #13

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action c…

This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers…

Mmm... This is a random idea, but maybe this could be supported trough filtering files by mimetype.

Gimp would only get access to image/* (not sure it needs something else? Adapt in the case it does). Of course, this requires adjusting the current development workflow (maintain a list of filetypes needed, for example).

Re: Flatpak – a security nightmare

#232

Post by MayeulC »

wbond wrote: post #211
nickik wrote: post #202

Earlier quoted context omitted.

If many distros and people want to use a flatpak to install software even with these drawbacks that would be a good indication that it would be worth doing upstream.

We currently provide a full complement of Linux package manager repositories, along with tarballs: https://www.sublimetext.com/docs/3/linux_repositories.html .

I try to respect a self-imposed policy of not installing proprietary software that's not properly sandboxed, as I have little control over it (think about the Remote Code Execution hive that Steam games must be).

I do not use Sublime Text personally, but if I ever want to try it, I'd do it trough a flatpak. Yes, sandboxing permissions might not be perfect yet, but a little sandboxing is always better than none...

Re: Flatpak – a security nightmare

#233

Post by vetinari »

pcwalton wrote: post #126
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.

Same way it works on the web: Use a broker process that grants access via a file select dialog.

The point is, that for vscode picking a file is not enough. It would cause lot of fun opening multi-root workspaces you just checked out...

There are many more applications, not just IDEs, where picking a file or folder is not sufficient: for example, apps like Rapid Photo Downloader or Darktable would be significantly crippled.

Re: Flatpak – a security nightmare

#234

Post by AnIdiotOnTheNet »

derefr wrote: post #190
AnIdiotOnTheNet wrote: post #170

Earlier quoted context omitted.

Hmm... it's almost like maybe applications shouldn't spew their files all over in the first place, then you wouldn't have to worry about putting them in the wrong places...

If you can tell me what a self-contained equivalent to, say, the libpam package would be, I’m all ears. Oh, also, a subset of case 2 is: packages that contain servers need to register the server as a service with the OS’s init system, and every OS has its own init system that expects a service definition file in its own distinct format and location.

libpam should be part of the base system, obviously. Like the widget library, ssl, and the display server. It's only really in UNIX world that this separation between "system" and "application" doesn't exist.

Re: Flatpak – a security nightmare

#235

Post by vetinari »

wbond wrote: post #211
nickik wrote: post #202

Earlier quoted context omitted.

If many distros and people want to use a flatpak to install software even with these drawbacks that would be a good indication that it would be worth doing upstream.

We currently provide a full complement of Linux package manager repositories, along with tarballs: https://www.sublimetext.com/docs/3/linux_repositories.html .

Have a look into flatpak too, otherwise in the not-so-distant future the users could have a problem.

For Fedora, they are planning switching to Silverblue around Fedora 30 (atomic system, rpms still supported, but jumping around the hoops).

Re: Flatpak – a security nightmare

#236

Post by patal »

> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue.

The flatpak release notes talk of a "minor security update", where "minor" surely means "of small size", not "of little importance" as OP would have it. Though the text could add a little importance.

Re: Flatpak – a security nightmare

#237

Post by wbond »

vetinari wrote: post #235
wbond wrote: post #211

Earlier quoted context omitted.

We currently provide a full complement of Linux package manager repositories, along with tarballs: https://www.sublimetext.com/docs/3/linux_repositories.html .

Have a look into flatpak too, otherwise in the not-so-distant future the users could have a problem. For Fedora, they are planning switching to Silverblue around Fedora 30 (atomic system, rpms still supported, but jumping around the hoops).

It will be interesting to see if Flatpak, Snap or AppImage ends up being the predominant force in the new wave of Linux packaging. Knowing Linux, users will probably expect projects to support all three. :-)

Re: Flatpak – a security nightmare

#238

Post by JdeBP »

jwildeboer wrote: post #199

Disclaimer: I work for Red Hat I strongly oppose these kind of attacks by people hiding their identity. No matter how valid the criticism might be, this goes against all the ethics of Open Source. Just like the Devuan folks that vigorously attacked systemd and Lennart. This must not be tolerated. Yes, I’m very upset.

That is not like the Devuan folks, who do not hide their identities.

* https://devuan.org/os/team/

Re: Flatpak – a security nightmare

#239

Post by zeroname »

linuxftw wrote: post #227
zeroname wrote: post #207

Earlier quoted context omitted.

> ...then I just won't use it. So far, that seems like a very reasonable compromise for both of us. > Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them. I don't see your point. If it's about Microsoft's data collection, that's orthogonal to how software distribution works. Otherwise,…

> Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably. What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner. > It doesn't stop at PPA, to really support all the other picky Linux guys with their distribu…

> What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner.

Fedora and especially Arch are big offenders. Debian is so "stable" that I can't install newer software through the provided packages anyway, so that's trading off one failure over another.

> Get your package into Debian and Fedora...

If you stay inside the FOSS bubble, of course maybe some maintainer will eventually spend their precious time packaging some version of your application in some (sometimes broken) fashion. I don't think that's a good solution even for FOSS, but for non-FOSS it's not even on the table.

Re: Flatpak – a security nightmare

#240

Post by pdonis »

zeroname wrote: post #207
pdonis wrote: post #150

Earlier quoted context omitted.

> I, as a developer, am not sure I care. I'm not saying you have to care. If your software is so good that I need to have it, then either my distro will have it, or you'll have set up some kind of distribution infrastructure that I can use securely, or, if I have to, I'll download your source code and build it myself. OTOH, if I don't need your software, and it's not easily available to me securely through my distro,…

> ...then I just won't use it. So far, that seems like a very reasonable compromise for both of us. > Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them. I don't see your point. If it's about Microsoft's data collection, that's orthogonal to how software distribution works. Otherwise,…

> there's no reason to trust the competence of Canonical or RedHat employees (or even volunteers for other distros) over those of Apple or Microsoft.

Yes, there is: Apple and Microsoft have broken people's systems, and leaked their data, multiple times. Microsoft has even shipped virus infected CD-ROMs to customers. RedHat and Canonical have not done those things. So their track record is much better.

> It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to...

You only need to do all that stuff if you insist on providing your own binaries. But the whole point of each distro having its own packaging system is that the distro builds the binaries and packages them. You, the upstream developer, just provide your open source code.

> Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably.

I've never had this problem, so we apparently have had very different experiences.

Post reply on HN