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