Mobile security, proof-of-concept.

[Tom Zander]

When I run PlasmaMobile on my pinephone I take advantage of the 
security by logging in using a PIN. This protects against several 
obvious attacks, and thats great.

We, however, still follow a design where all apps installed on 
the phone can freely read the data any other app wrote. As we by 
definition only have one user on a phone platform.
The effect is that your chat app can upload your passwords your 
browser remembers for you.
Your money is stored in files that can be deleted by a unintended 
file-browser option. And so on.
Or, not really security related, an app that stores its downloads 
in your homedir will look really annoying to most other apps and 
the user.

This is mostly Ok for pre-installed and for well-vetted open 
source software, but from experience phones will be going to run 
other software as well.
It would wise to do what all the popular mobile platforms do as 
well, provide strong separation for most end-user apps.


The basic and most powerful method of doing this is to run each 
application by default in its own homedir, as its own user. 
Unreadable for any other app.
Applications like the file-browser would be exceptions to this 
rule in order to stay useful.
This strategy is what I've seen used on most other platforms (I 
first used this when I worked for Blackberry, so many years ago). 
It works. It effectively separates files and it isolates RPC 
(pipes, sharedmem etc).


I would like to kickstart this in a way that we can get this 
incorporated into the plasma mobile default setup. I ask your 
help and guidance on this.

I wrote a proof of concept, which is fully functional but has the 
bare minimum number of features.
See; https://gitlab.com/tomzander/securitymanager/-/tree/master


Starting this tool will now allow one to
- use dbus (user session) to request the running of an executable 
(try /usr/bin/id for fun)
- the tool creates assigns a userId and creates
  a dir in like /data/1100
- a tiny privileged part changes ownerhip of that dir
  to the chosen userId.
- it also runs the executable in that dir with this uid.

The effect is that no applications or users (without root)
can read the private files from those apps and they can't
read them from each other.

Running them as different users additionally means all the
standard protections apply and RPC is private between
components of one app.
For instance useful if you have a neochat daemon that listens to 
the network while the main app may or may not be running. All 
using the same UID naturally.

To play with it;
create dir /data and change ownership to the same user that is 
logged in on the GUI.
compile the app, change ownership to root and do a chmod +s file.
Start the app from a konsole or so.

Start your dbus tool and find 'org.tom.securityManager' and on 
that one find the 'run' method. Pass in the '/usr/bin/id' 
executable.
Notice output on the security-manager cli.

-----

To make this work for Plasma Mobile with GUI apps there is only 
one requirement: the XDG_RUNTIME_DIR dir needs to be made 
readable for your group-id and the `wayland-0` and 
`wayland-0.lock` need to be made read/write for group in that 
same dir.
The tool could do that on startup, if this is deemed the right 
approach.

The 'securitymanager' as I called the proof of concept, would be 
started at the start of the user session and the launcher would 
stop running apps itself but use the session bus to instead ask 
the security manager to start those apps for her.


What do people think, is this the way to go with regards to the 
next level of security for mobile ?