Live data from Hacker News

Flatpak – a security nightmare

flatkill.org

251–260 of 264 posts

Re: Flatpak – a security nightmare

#251
post #243
post #194

Earlier quoted context omitted.

The reason applications spew files all over the place is because that's how you hook into other systems. Want a man-page? There's a folder for that. Want to autostart? Folder for that. Want your program to be runnable without specifying the full path? Put it in path. The reason configuration sucks is because we use filesystems, which are necessarily hierarchical, when we should use a more general database. If we had…

> Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that. It's kind of amusing that on the Windows side, you have a vertical integration between the filesystem (NTFS) and the update mechanism, where any MSI package will actually be installed in a filesystem transaction , such that if you e.g. cut power in the middle of package installation, then your di…

Unfortunately, NTFS transactions have been deprecated.

https://docs.microsoft.com/en-us/windows/desktop/fileio/depr...

Re: Flatpak – a security nightmare

#252
post #157
post #13

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action c…

Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt. 2. documents consisting of many files are structured into project bundles; you open—and thus grant access to—the entire bundle at once. 3. the GUI is structured to orient activity around documents rather than around applications. You hardly ever launch an app and then open a file in it. Instead, you open the document and the…

Same thing for Win10 UWP apps.

Re: Flatpak – a security nightmare

#253
post #26

Earlier quoted context omitted.

This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers…

I'll just make a file link to .bashrc and call it /tmp/foo.png, what are you going to do? Not open links? Check if the file links to .bashrc? If an image manipulation software wants to open .bashrc, allow it. If it has permission to write to one, so be it. If .bashrc is such a security nightmare, then perhaps the issue is that programs can write to it. Remove the write permission. Perhaps a security model where resto…

> Check if the file links to .bashrc?

That would seem to be the obvious right choice. What's the problem with it?

Re: Flatpak – a security nightmare

#254
post #13

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action c…

Most use cases of VLC only open files, so giving it universal privileges to open files but a prompt on filesystem writes would be fine. Gimp could have universal read and the right to create new files, but overwriting files it didn't create itself restricted behind a permission prompt. Same for Inkscape and Audacity. If you want to push this further, you could imagine a permission system that can distuingish based on…

> but overwriting files it didn't create itself restricted behind a permission prompt

It's more nuanced than that. A user might not even have a .bashrc, but you still don't want to allow any random app to create one.

In general, it feels like the security model for the FS has to distinguish things that can be executed, and things that cannot. Which it already does on Unix with +x, but then you've got all the scripting languages that cheerfully ignore that, and all the apps that use executable configs etc. If you can fix all those such that +x is required for any source of executable code on the system, then you can just prohibit apps from creating +x files. But the cost of doing that in the existing ecosystem is enormous.

Re: Flatpak – a security nightmare

#255

Earlier quoted context omitted.

There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before. Programmers like to come up with clever wa…

> Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. That is not very good. Suppose you create an audio file with Audacity and a series of images with ImageMagick and GIMP, then use ffmpeg to combine them into a video and VLC to view it. They're all operating on the same files. What we need is to add an application list to filesystem ACLs and then have security groups like…

> What we need is to add an application list to filesystem ACLs and then have security groups like Video and Finances which contain apps. Because GIMP should be able to access your photos but not your accounting spreadsheet.

This isn't that hard in a technical sense. But I very much doubt you can get the casual users to actually do that. They'll just end up with one giant group, because it's the easiest and doesn't require understanding the concept of security boundaries.

Basically, it'd be Vista UAC prompts all over again.

Re: Flatpak – a security nightmare

#256
post #66
post #55

Earlier quoted context omitted.

But Flathub is flatpak. Also, does flatpak have the full support of redhat?

No. Flathub has nothing to do with flatpak technology itself. Flathub is just one server hosting some flatpack repos. It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many other you could add to get your apps

Isn't the whole point of Flatpak to prevent the same app from being packaged multiple times for different distros?

Re: Flatpak – a security nightmare

#257

Earlier quoted context omitted.

This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstra…

The situation is similar on Win10 (and the approach is also the same - sandbox apps have to use a certain API to invoke the file browser and get access to some files or folders). But apps that don't do that because they're too old, just don't get access to the Store... or at least they didn't use to. Now you can ship non-sandboxed Win32 apps through the Store, and it doesn't even seem particularly obvious which ones…

I don't see why it would be any different on Linux.

There will always be legacy applications that will stay on old toolkits and they cannot fully benefit from sandboxing.

However, a lot of widely-used Linux applications that are on older toolkits are currently working on upgrades. E.g. Inkscape and The Gimp will be Gtk+3 applications. There are often other carrots, such as proper support for scaling for HiDPI screens, etc.

Re: Flatpak – a security nightmare

#258
post #66

Earlier quoted context omitted.

No. Flathub has nothing to do with flatpak technology itself. Flathub is just one server hosting some flatpack repos. It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many other you could add to get your apps

Isn't the whole point of Flatpak to prevent the same app from being packaged multiple times for different distros?

Ideally , Firefox would be downloaded from official Mozilla Flatpak repo, Blender from Blender Flatpak repo on Blender server, etc... And we would have this list of those repo on our distro.

However because the official adoption is slow (very few software have official flatpak repo), flathub allowed the community to build packages themselves. But this is clearly not how it should be.

The second (more legit) reason of flathub is that small developer might not want to pay a server to host their app and flathub proposes to host their repo.

Re: Flatpak – a security nightmare

#259
post #249

Earlier quoted context omitted.

"If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it." You're ignoring a huge amount of business software that is created for, and runs on, Windows. That's like judging Android or iOS based upon the consumer crapware that gets sold/given away in their app stores, as opposed to the many bu…

> You're ignoring a huge amount of business software that is created for, and runs on, Windows. That's like judging Android or iOS based upon the consumer crapware that gets sold/given away in their app stores, as opposed to the many business apps that are used to automate and improve all sorts of tasks on mobile devices. Thanks for this. Indeed I was responding a bit flippantly to the whole "real" desktop software,…

Thanks for the thoughtful comments, they are very much appreciated.

The thing that a lot of Linux developers don't seem to get about Windows is that its binary distribution model is an opportunity/productivity multiplier, and it all hinges on three major points:

1) Backward-compatibility is real, and, contrary to what most people say about MS/Windows, this is very pro-consumer. Just chucking code at people and saying "but, you can just re-compile it" ignores a lot of realities, including the fact that even developers don't want to be forced to recompile binaries that they are not, themselves, working on as their actual work.

2) You can deploy 32-bit binaries on 64-bit systems and they work just fine. It really made the switch to 64-bit versions of Windows a non-event, whereas this is another issue that developers need to worry about when targeting Linux. And, there are a lot of applications that simply don't benefit from being 64-bit because they don't need, or can't use, the increased address space, so forcing developers to specifically target 64-bit is just another unnecessary hurdle.

3) You can actually create binaries for Windows that don't require any dependencies other than what is available in the OS. This means that you can create binaries that work on tablets, laptops, desktops, and servers without recompilation. This also ties in to your comment about the installers, but the reality is that you really only need admin access for an installer to put things into the "Program Files" folder tree, or to install services. Apart from that, most professional software doesn't touch anything other than the user-specific folders (if Windows doesn't delete them first ;-) ).

I don't think that this point can be overstated: if you create a neutral OS platform where desktop developers can deploy their software with minimal fuss and no gatekeepers, you will win the desktop space, period. More than anything else, desktop developers want to make money, and an open OS that does its thing and stays out of the way is the ticket to that money. But, in order to do this, a lot of current Linux developers will need to get used to sharing Linux with commercial vendors and proprietary software, and I think that's still a hard sell. And, unfortunately, a large part of that mindset is wedded to this bizarre idea that desktop developers like Windows because of Windows. Desktop developers like Windows because a) that's where the users are, and b) they can make money without being forced or required to expose their source code. If the same can be done with Linux, then Linux will have no problem taking the OS space away from MS completely.

Linux is stuck in "server/appliance mode" right now, and it's a shame because if there was ever a time for Linux to take over the desktop, it's now. As you say, web applications are just not a suitable replacement for all desktop applications. MS keeps trying to lock down how development is done on Windows and, if they succeed, then everything that I stated above will go away and there will be a lot of developers looking for a new home. Any OS that starts out with "you can only use our development tools/languages, and no others", is going to whither away and die. It happened to Apple once, it appears to be happening to Apple again, and MS has apparently decided that it should emulate Apple. The whole reason why Windows became popular in the first place was because there were a ton of development tools/compilers/languages that could be used to produce binaries for Windows, and Windows gave zero preference to any of them. This was carried over from MS-DOS. And, none of this precluded any vendor from going ahead and providing/selling their source code along with the product. Linux developers have just got to let go of trying to control how people use the OS, and just try to make it as amenable to as many usage/deployment scenarios as possible.

Re: Flatpak – a security nightmare

#260
post #31

> VLC [...] filesystem=host See my comment on why it's not easy to fully sandbox software like VLC: https://news.ycombinator.com/item?id=14409234 The author is correct, in the fact that flatpak-vlc is not a secure sandbox.

Thanks for sharing the info. I'm just curious - how would splitting VLC into multi processes solve the permission issue, since the sub-processes will still need access anyway?

Each subprocess would only get one permission, the one that it actually need. The critical parts (audio decoders, video decoders, parsers) would not get access to $HOME or network, for example.
Post reply on HN