Mobile security, proof-of-concept.
Tom Zander
tom at flowee.org
Thu May 20 21:42:04 BST 2021
After some feedback on Matrix, here the FAQ;
# Can't you just use Flatpak for this?
Flatpak is aimed to be a packaging method, its meant to allow an
entire app to be packaged including its dependencies.
This is mostly about bubblewrap that run deployed flatpak apps.
Bubblewrap is not in conflict with the security-manager, you can
use them at the same time or more likely get the security manager
to do it automatically.
The ideas in the proof of concept are about how to automate
running software from a simple dbus call, flatpak doesn't do that.
Also, many apps are not flatpak packaged.
# Shared user files.
Starting applications user-separated by default means they can't
read your photos, configs etc.
This means that a specific application needs to be given
permission to access shared files or to access the removable
memory or session data. This is how it works on most phones
today.
I consider this extra step a feature, and its pretty easy to have
a shared dir that all allowed apps mount as "public".
# session info.
I tested different approaches with the proof of concept and ended
up with the idea that the security manager is started by the
normal user, and thus has uid and gid that is identical to the
normal user. Also has the normal env-vars.
The started applications will inherit the gid and groups as well,
with only the uid (and euid) being changed to get the isolation.
This effectively means that it is now easy to allow access to
session data based on some file-system permissions. Things like
dbus, obviously the GUI and other parts accessible from
/run/user/1000/ can be made available to the using app.
# Why a different user, isn't containers enough?
Containers actually use large number of features from Linux,
among others isolation based on user-id.
I don't see much use in most features here, though. Not for
running one application at a time isolating it from others. If
you know any, let me know.
So, simply said, this proof of concept is the minimum amount you
need to get security. Containers are not simple, at all.
# Compatibility
Applications written for other mobile operating systems have
never been told to use things like the XDG standard or the .config
directory for config files.
They indeed get a 'homedir' of their own and can just assume they
are the only ones using that directory.
So an app that downloads some cached data just drops that in its
entirely-private homedir.
This idea is 1 to 1 compatible with the security manager proof of
concept app that I wrote, and I hope that we can start seeing
this as the main way to start apps on Plasma Mobile.
# What about system settings?
It probably is easiest to just run that one (much like the file-
explorer) as the normal user. Defaults for known apps can be
deployed in a config file to avoid bothering the user with this.
More information about the Plasma-mobile
mailing list