What I am really excited and curious about with regards to this technology is how it will be used in malware.
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.
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.
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.
Installing in the users homedirectory is not a new feature added by these systems though, its always been possible. If you want to avoid that you have to e.g. mount /tmp and /home noexec, or use e.g. selinux policies to do the same. This will stop flatpak/snappy as well as any other approach for per-user apps.
I do not dispute this. However, it adds all dependenices and dynamic loaded libraries (or static?) in most cases. So bundling applications to dupe users is increasingly easy.
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.
For starters, nix and guix have the same security model, and it is remarkably similar to the old Unix security model. You can put your installed apps either in root-owned or in user-owned repository, so that might be an improvement over root-only package systems. (Nix also experiments with containers, but it's not perfectly isolated yet, and I believe it is targeted at docker-style management, not GUI apps.)
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.)
Flatpak also has atomic transactional updates (and automatic deduplication similar to nix) via ostree.
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.
Thank you both for answering. One question I have is about "targeting GUI apps". Why wouldn't developers be able to distribute non-GUI apps using Flatpak and AppImage?
9 comments
[ 4.3 ms ] story [ 28.9 ms ] threadAs 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.