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