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

31–40 of 296 posts

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

#31

Post by orf »

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.

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

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

#32

Post by foobar33333 »

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

>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.

Flatpak has this already. They call it portals and it covers more than just file pickers. The problem I have seen is that shoving existing software in to flatpaks and making them use portals ends up buggy for unknown reasons. I think the app devs themselves need to make at least some conscious effort to make sure it works and not directly access files.

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

#33

Post by foobar33333 »

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.

Flatpak is a package manager which supports repos exactly like traditional package managers. The biggest repo is flathub and there is also one for fedora which is a little more vetted but contains less software.

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

#34

Post by foobar33333 »

josefx wrote: post #15
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 exhaustiv…

Flatpak apps can not access root owned files. They run as the user and the typical linux permissions apply. They can only gain access to root if they have filesystem access so they can load malware in to bashrc. The thing is this is exactly the same as traditional packaged linux software. Flatpak only offers the ability for extra security.

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

#35

Post by saagarjha »

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

(This is how Powerbox on macOS works.)

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

#36

Post by fulafel »

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…

This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.

Maybe some antivirus etc products manage to seemingly do things like this on Windows platforms, but they have generous support from the platform developed over decades, are executing custom 3rd party kernel drivers, are unhindered by opinionated kernel developers blocking the feature due to their distaste for these hacks, and the resulting system is still unsound and rife with stuff like TOCTOU vulnerabilities, and the prompts are not intelligible to nontechnical users.

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

#37

Post by Iolaum »

foobar33333 wrote: post #29
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 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.

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

#38

Post by akvadrako »

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…

You can control the permissions with flatpak, it just doesn't ask you about each one by default.

But if that's what you're asking for it isn't a major change. It could even be done by using a simple shell script for installation.

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

#39

Post by akvadrako »

andrey_utkin wrote: post #18
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.

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

What kind of rule are you talking about? Flatpak is pretty flexible.
Post reply on HN