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

91–100 of 296 posts

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

#91

Post by cardanome »

I don't need the security. I don't need automatic updates.

As a Linux user, most of my software will be installed with my native package manger and receive the appropriate security updates.

Flatpak/Snap/Appimage are just for when the former option is not possible because the software is not available or not in the right version I need.

I am making a conscious decision here to seek out that software and can be expected to check for trustworthiness.

The Windows world survived decades with running random .exe files from the internet. Some people got hurt but that is fine. Sometimes convenience and productivity can be more important than security.

I already have a good sandboxed environment, it is called a web browser.

So really for me the only thing I need is some easy way to run an application with just a single click on any Linux system. Appimage works fine for me. All the other features, I don't need them.

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

#92

Post by Jouvence »

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.

Sandboxing is fine, but it sounds like Snaps/Flatpaks don't actually do it because that would be too hard - so what's the point?

I get that some packages do actually have sandboxing, but unless it is mandatory and enforced I feel like I'm better off avoiding the ecosystem entirely and dealing with app isolation myself, using containers or VMs.

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

#94

Post by its-summertime »

harporoeder wrote: post #50
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…

There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox. 1. https://docs.flatpak.org/en/latest/portal-api-reference.html

specifically, anything that uses the generic GTK/Qt way of accessing files via the file chooser will automagically use the portal

Anything that tweaks on that, most notably Electron, will not use the portal

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

#96

Post by josefx »

foobar33333 wrote: post #34
josefx wrote: post #15

Earlier quoted context omitted.

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

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

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

#97

Post by akvadrako »

its-summertime wrote: post #94
harporoeder wrote: post #50

Earlier quoted context omitted.

There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox. 1. https://docs.flatpak.org/en/latest/portal-api-reference.html

specifically, anything that uses the generic GTK/Qt way of accessing files via the file chooser will automagically use the portal Anything that tweaks on that, most notably Electron, will not use the portal

That's a choice of Electron - it could and should use portals.

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

#99

Post by blablabla123 »

KronisLV wrote: post #56
fulafel wrote: post #36

Earlier quoted context omitted.

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

Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual need…

Isn't this something that was addressed already years ago by SELinux, even before Android? Personally I prefer to not use it since I don't find it very user friendly but Fedora seems to have it activated by default.

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

#100

Post by microtonal »

xvector wrote: post #84
jeppesen-io wrote: post #57

Shall I plug NixOS?

What is Nix and why is it a better alternative?

There is some overlap and there are a lot of differences. One point of overlap is that Nix makes it easy to install packages that are newer than your os. For example, you could run NixOS 20.09 or Ubuntu 16.04 and have the latest Handbrake or youtube-dl.

A large difference it that Flatpak also attempts to sandbox applications, which Nix doesn't (it only sandboxes builds). Though it might be easier to sandbox applications using Nix than traditional package managers, since all dependencies are made explicit.

Post reply on HN