
Portals: Using GTK+ in a Flatpak - alexlarsson
https://blogs.gnome.org/mclasen/2016/07/08/portals-using-gtk-in-a-flatpak/
======
616c
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.

~~~
digi_owl
Well the scheme seems comparable to Android app permissions.

And as best i understand, most malware on Android comes from modified APKs
downloaded from questionable sites.

~~~
616c
Well, that is my problem.

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/](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

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

~~~
616c
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.

------
oDot
I often see Flatpak and Snappy compared, but is there a comparison between
them, Nix, Guix, and even GoboLinux?

~~~
espadrine
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.)

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

~~~
oDot
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?

