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

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

flatkill.org

Post reply on HN
Print view View original

61–70 of 296 posts

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

#61

Post by eeZah7Ux »

gspr wrote: post #28
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…

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.

> Soon they'll reinvent the classical Linux distro

Spot on. Distros exists for good reasons: you need someone to configure things to work well together and manage security for you.

Including sandboxing: it's being already done with system daemons by systemd and for applications by firejail and similar.

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

#62

Post by jcelerier »

cl3misch wrote: post #45
orf wrote: post #31

Earlier quoted context omitted.

The “classical Linux disto” got us into this mess, so I doubt it.

No, I think what got us into this mess is Ubuntu being a server distro with a standard release cycle (as opposed to rolling release) getting incredibly popular on desktops. Desktop users want the newest version of their UI apps and don't care so much about stability. Ideally, the developers of e.g. Inkscape would offer the newest version on each Ubuntu version via apt, but that does not seem to be feasible. I am no A…

> I don't have the feeling most people use Snap/Flatpack for their sandbox, but much rather for getting a new version of some software.

That's the case for everyone I know (though they mostly use appimages)

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

#63

Post by eeZah7Ux »

foobar33333 wrote: post #30
ekianjo wrote: post #12

Earlier quoted context omitted.

note that the response partially agrees with the points raised, it looks like a constructive discussion overall.

The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets e…

> If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo

True, and the same is true for flatpak given that the author of the package controls the sandboxing.

The only solution is to have 1 or 2 trusted packagers to review the package, including its code - which is what some Linux distributions do.

Furthermore, Debian does a long release freeze for the stable release and a lot of users test it. A malicious package might well be spotted.

Contrast it with the very lightweight vetting that is done by others.

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

#64

Post by jcelerier »

alpaca128 wrote: post #42
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…

From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying. I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to cop…

If that can make you feel better, it is exactly as annoying for mac os apps on the mac app store. I don't know anyone using Mac professionally (for e.g. design, etc...) who uses AppStore apps because of that

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

#65

Post by jcelerier »

littlestymaar wrote: post #21
santoshalper wrote: post #11

Earlier quoted context omitted.

It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.

Look at how the Web standbox is designed: of course some websites must access to your camera (Zoom, Jitsi, MS Teams, etc.) yet you still have to give them the permission! And it's a fine-grained permission (don't want to share your microphone, Ok just don't). I want to be able to give programs exactly access to I want it to access, and just when I want to give it that access. This way I'm sure my SSH keys (or private…

But the web sandbox is terrible and an exercise in frustration when compared to using desktop apps ?

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

#67

Post by yellowapple »

santoshalper wrote: post #11
littlestymaar wrote: post #9

Earlier quoted context omitted.

Interesting part: > It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful. […] They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portal…

It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.

> Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem.

The overwhelmingly vast majority of them would do just fine without having access to my entire home directory.

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

#68

Post by eeZah7Ux »

hnedeotes wrote: post #14
mavhc wrote: post #10

Earlier quoted context omitted.

Passing responsibility of not distributing evil software from the gatekeepers to the user. Ignores half the point of having a distribution that has a package manager, curated software.

Why can't they be complementary?

Because distributions don't need flatpak. There are already methods to do sandboxing like systemd and firejail.

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

#69

Post by eeZah7Ux »

hkt wrote: post #27

Is there a security comparison somewhere of all the new fangled ways of getting up to date desktop software on Linux? snaps etc too? I suppose the real answer may always have been backports on debian distros - which is to say, trusted sources over technical solutions.

Spot on.

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

#70

Post by necovek »

foobar33333 wrote: post #30
ekianjo wrote: post #12

Earlier quoted context omitted.

note that the response partially agrees with the points raised, it looks like a constructive discussion overall.

The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets e…

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 deliver on. Now I am suddenly asked to trust these external developers that they will be as adamant with security fixes, be non-malicious, etc. And flatpak/snap are trying to convince me how that's a non-issue "because sandboxing".

Sure, we here understand the underlying technologies so we can make our own educated guesses, but majority of the people who this is aimed at don't.

Since you also mentioned "add a new repo", there are some repos you can trust even if they are not the official ones. PPAs on Launchpad build from source packages, so you can always get the source first ("apt-get source package" after adding the repo). If someone is just bundling binaries and the build is a no-op, you can drop the repo right away. Sure, it requires some effort and you won't be checking every repo, but for sufficiently popular repos, somebody would be doing that.

It'd be ideal if apr grew support for limiting packages that can come out of a repo, so you'd have to whitelist when something new pops up ("hey, this repo has now introduced libc version X, and your libc is coming from repo main: do you want to allow upgrades from non-main repo to libc? [only once] [yes] [no]").

Post reply on HN