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

11–20 of 296 posts

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

#11

Post by santoshalper »

littlestymaar wrote: post #9
microtonal wrote: post #5

Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flat...

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.

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

#12

Post by ekianjo »

mands wrote: post #7

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.

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

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

#13

Post by oblio »

mavhc wrote: post #10
littlestymaar wrote: post #8

Earlier quoted context omitted.

Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?

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.

So the solution is to have the package manager decide things for every user?

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

#14

Post by hnedeotes »

mavhc wrote: post #10
littlestymaar wrote: post #8

Earlier quoted context omitted.

Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?

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?

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

#15

Post by josefx »

nodja wrote: post #4

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

> All of the examples are apps where the main use is manipulating files on the system.

So do users, still can't overwrite system wide settings without first getting root. Decent sand boxing has to be granular enough to cover partial access. Of course the hard part on Linux would be locking access to files like ~/.bashrc without completely blocking access to the home directory, that probably would require an exhaustive list of all config files that are directly stored in home instead of a specialized sub folder.

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

#16

Post by kelnos »

mands wrote: post #7

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.

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 permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.

I haven't used Flatpak (or Snap) before, but my impression of the technology was that it isolates apps and strongly sandboxes things so if you accidentally run something malicious, you're covered. But that doesn't seem to be the case, really. I get that this is a hard problem, and some things aren't even possible to do on X11, but then don't leave people with the belief that you can do all these things.

The response also says:

> Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape.

That is just an awful approach to security. You need to deny by default and selectively allow, not allow by default and selectively deny. Applications do not need explicit permissions to get r/w access to blocked directories; they can simply append to ~/.bashrc or whatever, and bam, they have "permission".

I'd heard some bad things about Snap, but looks like I'll be staying away from Flatpak as well.

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

#17

Post by nextlevelwizard »

ekianjo wrote: post #12
mands wrote: post #7

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.

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

It is hard to guess at motives when author is unknown.

Or when neither of the CVE links go anywhere.

Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages.

With ffmpeg I don't know if things like Chromium are actually using the flatpak ffmpeg or if they ship with their own libs.

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

#18

Post by andrey_utkin »

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.

It must not be all or nothing. In firewalls we have rules. In SELinux etc we have rules, and distros package them for you.

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

#19

Post by tim333 »

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.

I'd be fairly happy for an IDE to stick to the /dev folder where I have that kind of stuff.

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

#20

Post by kelnos »

nodja wrote: post #4

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user.

This does mean that some apps potentially do have worse UX; any app that implements a custom file picker will just stop working properly. Arguably in that case you just simply cannot sandbox that kind of app, and you shouldn't try, because it gives people a false sense of security in using it.

For apps that want to do custom things you essentially have to make them not need to do custom things by building their custom behavior into the sandbox-owned file picker (or whatever), and allow them to make use of it in a safe way. But that's a lot of work, and it doesn't seem like the Flatpak folks really work with the toolkit authors.

Post reply on HN