Portals: Using GTK+ in a Flatpak
blogs.gnome.org
blogs.gnome.org
As Linux increases in usage (year of the desktop jokes aside), I think this will be clever to host an application or stack the user has experience with, but is in fact ghosting malware underneath. I have not seen a lot of information on how system administrators can control it.
I am not saying such mechanisms do not exist, but with such non-admin install tools (Flatpak is but one), I see little mention of security controls and the development pace is faced.
I would not be surprised to see limited (and that's not meant to be a snipe or criticism, I understand there are limits to what is possible as a large mooch consumer of F/LOSS tools), but that worries me.
It will be so useful to exploit; I brought it up at security training with far more experienced people than I and many infosec people are completely unaware of these very recent developments and when white hats and black hats catch, I expect the wonderment of the reinvented wheel to greet us always on HN.
And as best i understand, most malware on Android comes from modified APKs downloaded from questionable sites.
I want such things to exist, but I am not sure how they are controlled. The emphasis is on my lack of knowledge, not lack of tooling. Many of them are rapidly iterating and docs are so-so, despite xdg-app (nee Flatpack) being around for a while. This one is a reincarnation, if memory serves.
http://flatpak.org/ (They refer to xdg-app IRC and ML addresses)
So this is my main concern.
It is amazing most system administrators equate formal installation and ability to execute as 1:1 on Windows,OSX, and Unix environments. In most cases, I can extract executables from MSIs and use them from an admin install. Only more experienced people pick up on this (believe me, I am still new to this and it was years of sysadmining with skilled people to have this click in my mind when I started).
So why do I care? Software Restriction Policies and AppLocker and such are a pain. Executable signing and the infrastructure around it in OS X are a pain, and MAC systems in Linux are a pain. This brings real benefits to users, local non-privileged app installs on these systems, and these mitigation countermeasures mean more work for sys-admins, many who will never know in distros like Ubuntu it is on by default with kiosk machines.
Some of us developed Linux only kiosk machines for a reason: I could whittle that attack surface down real nice. Sadly, on every system that gets attention, it's a battle we lose, to get philosophical.
As a
I guess it just appearances. Perhaps it has always been this easy. But I predict with Ubuntu and more "user-friendly" distributions will make this a store.
Returning to the AppPlay debacle, this means that analogy will lead us to the "Google Play Store is increasingly filled with malware" scenario we fear.
Linux distros had secure distribution so right for so long. I see this as a step in the wrong direction.
They don't have the same goals as Flatpak (aka xdg-app) / snap / AppImage. Those are targeted at GUI apps, with sandboxing guarantees (except for AppImage), and ease of installation (read: you don't have separate instructions for each Linux distribution).
Flatpak focuses on granular control through permission prompts à la Web apps. Snap focuses on automatic transactional updates. Sandbox-wise, they both use cgroups and namespaces. AppImage doesn't: it is simply a format to produce cross-distribution standalone executables.
(Note that snap doesn't just target GUI apps, unlike Flatpak / AppImage. It also targets OS- and kernel-level packages.)
Also, Snap doesn't use namespaces, they install each app in a separate prefix which the app finds via various environment variables. Then it uses apparmour to make the /usr, etc unreadable to the app.