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

21–30 of 296 posts

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

#21

Post by littlestymaar »

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.

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 emails,or bitcoin wallet, etc) will never be leaked by a malicious VSCode extension.

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

#22

Post by diffeomorphism »

littlestymaar wrote: post #8
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?

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 ?

In practice this has the same effect as windows vista had. You train users to immediately click away the annoying popups without reading them.

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

#23

Post by eis »

nextlevelwizard wrote: post #17
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.

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 th…

Which is good as one should discuss the merits of the arguments brought forth when discussing the pros and cons of a technology rather than who who said it or what motives they might have.

Edit: when I wrote this comment only the first sentence of the parent existed.

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

#24

Post by dastx »

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted).

We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.

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

#25

Post by orf »

kelnos wrote: post #16
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 permissio…

> Well, ok, sure, that's definitely not "almost all", but that's still way too many.

And a couple of sentences after it goes on to explain that it’s not too many because most of those 23 need those permissions.

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

#26

Post by diffeomorphism »

oblio wrote: post #13
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.

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

Yes, the point is to have the package manager set sane defaults for every user.

Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all.

A much more sane approach would be to enable access to ~/videos and other reasonable places at install time and only ask for additional permission when needed.

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

#27

Post by hkt »

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.

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

#28

Post by gspr »

kelnos wrote: post #16
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 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.

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

#29

Post by foobar33333 »

dastx wrote: post #24

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when promp…

I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it.

The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.

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

#30

Post by foobar33333 »

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.

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 exposed as well as less permissions being given to packages.

Post reply on HN