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

241–250 of 296 posts

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

#241

Post by syrrim »

Iolaum wrote: post #37
foobar33333 wrote: post #29

Earlier quoted context omitted.

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

> This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.

That's what he's saying

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

#242

Post by owaislone »

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.

Sandboxing does not mean no interaction. It means supervised interaction between apps where the user is in control of what to allow and what not. I'm not sure how well Flatpack does it (never used it) or Snap does it (used quite a bit but never tested how well it sandboxes) but there are other platforms that handle sandboxing pretty well and then provide APIs on top to allow interaction with the system and other apps (iOS, Android, Meego for example).

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

#243

Post by fao_ »

higerordermap wrote: post #71
gspr wrote: post #28

Earlier quoted context omitted.

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.

The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.

Except Multics, which predates UNIX, already had a lot of these features but better.

https://www.acsac.org/2002/papers/classic-multics.pdf

I don't understand how you can honestly, truly say it's "technological ludditism" when it's clear that nobody in this thread is opposing the features that Flatpack and Snap claim to have, which in many forms predate UNIX and predate Flatpack/Snap -- they are just opposing the half-baked implementation that Flatpack/Snap have created.

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

#244

Post by takluyver »

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…

In some cases it does request permissions when you try to do things. E.g. sandboxed apps without full filesystem access can open & save files through a 'portal' - the system presents the user with an open/save dialog, and the app gets access to the file or folder they select. Things like screen sharing can work similarly - the system asks the user to approve access for the app.

But, as other people have said, this involves new APIs. In the open/save case, the app has to request that the system display a file chooser instead of drawing its own. GTK & Qt can hide this change so apps built on those toolkits benefit automatically. But beyond really self-contained things (like games) most apps that haven't been developed with a sandbox need some adjustment to play nicely within a sandbox. And making changes depends on building a consensus that it's worth doing.

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

#245

Post by GekkePrutser »

Spivak wrote: post #178
necovek wrote: post #169

Earlier quoted context omitted.

Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc."). Suddenly, it's now on app developer to support the packaging system and not the other way around.

I mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog? macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.

And also because macOS has only one desktop environment :)

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

#246

Post by GekkePrutser »

pdimitar wrote: post #142
syockit wrote: post #135

Earlier quoted context omitted.

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

People have praised Qubes OS for its security in the past but I've never tried it.

I have. It's very secure but too much towards security on the security Vs usability scale for my liking.

I use it for specific purposes like possibly hostile browsing environments but I'd never consider it for a mainstream system to work on.

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

#247

Post by GekkePrutser »

superkuh wrote: post #195

Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically co…

Indeed, very good point. Those is why I moved to freebsd for my desktop. Too many corporate interests hijacking Linux right now.

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

#248

Post by orra »

Spivak wrote: post #202
orra wrote: post #197

Earlier quoted context omitted.

TBF you could put support into the two common GUI toolkits, to defer to a Flatpak portal.

But that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.

Well, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck.

It wouldn't surprise me however if sandboxing is only a good model for GUI not console app.

IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.

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

#249

Post by takluyver »

necovek wrote: post #185
oxylibrium wrote: post #109

Earlier quoted context omitted.

Created an account just to reply to this - there is no "proprietary" API for actions like opening files. Both Flatpak[0] and Snap[1] use the same xdg-desktop-portal spec[2], which covers stuff like opening files, taking screenshots, sharing screen, and sending e-mails, among other things. The only major difference in the two sandboxing approaches (noted in [1]) is the ability to execute arbitrary code outside the san…

Thanks for a detailed reply and correction on the extent "proprietary APIs" apply (I hope my use of proprietary as in not-an-open-standard does not rub you the wrong way — perhaps "custom APIs" is better): I am happy to hear that it's at least a shared implementation between both for some, very limited things. Even if I want to ignore the "exec()" differences, you are still limited to standard OS file selector (for i…

The upside of having the system draw file dialogs is that file dialogs from different apps look consistent, rather than getting out-of-place dialogs depending on what toolkit the app used. It might sound silly, but it's a real annoyance, and there are plenty of apps that don't implement any custom preview.

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

#250

Post by takluyver »

foobar33333 wrote: post #106
josefx wrote: post #96

Earlier quoted context omitted.

> Flatpak apps can not access root owned files. I think I didn't make my point clear. I used that as an example of "needs to access files" not meaning "needs to access all files, including but not limited to configuration files". > Flatpak only offers the ability for extra security. With a permission model that apparently can't keep an image editing application from silently editing .bashrc .

>With a permission model that apparently can't keep an image editing application from silently editing .bashrc . It can, you can cut off all filesystem access or select certain areas. The problem is that programs often need special attention to make sure they work properly using flatpak portals. Currently not many devs are interested in doing this work since flatpak is pretty small right now. So for now we must assum…

Yup, it's a classic catch 22. Sandboxing doesn't really work without developer cooperation. But there's little incentive for developers to work on it in apps that are easy to get outside the sandbox - or when it's easy to get extra permissions in a Flatpak.
Post reply on HN