answered
2019-05-16 17:36:01 +0300
Sailfish OS does not sandbox its apps nor puts them in "separated secure execution environments", as far as I understand.
Not exactly.
First keep in mind that Sailfish is a too small ecosystem and no bank will deem necessary to develop a special app targetting Sailfish. You're most likely going to run an Android application on Sailfish's Alien-dalvik Android Application compatibility layer.
Now...
Android isolation
On modern Sailfish X (with Baseport 8) as used on the Xperia XA2, the Alien-dalvik Android Application compatibility layer works by running an AOSP (opensource Android) 8.1 Oreo inside an LXC (a type of Linux Container) which will result in the android being kept separate from the rest of Sailfish X.
(And on older Sailfish as used on Xperia X, Jolla 1, etc. : Those devices use AOSP 4.4 Kitkat and by design these older versions of Android run inside some kind-of Java VM. They are already in a VM, they already run separated from the rest of the OS, by virtue of running bytecode in the Dalvik JVM).
So the whole Android is already sandboxed to begin with, on Sailfish.
Android APPs isolation
Because Sailfish runs the "real-deal" AOSP (either in LXC or inside a JVM), you will automatically get all the application isolation that is automatically provided by Android.
e.g.: If you explore the content of /home/.android/ you'll notice that, just like on real Android smartphone, each application is installed under a different UID and GID.
So if one app get hacked, it will not be able to access the data of another app without need first to do privilege escalation (and hack the whole system becoming root).
So, from the point of view of banking APP, running them on Sailfish OS looks just like running on a real Android smartphone
The problem won't be due to the application environment but for the services
Google Proprietary Service
Like lots of other android applications, some of the banking applications are addicted to the APIs provided by the "Google Play Service" (proprietary blobs of Google, not part of the opensource AOSP).
You have two solutions to get this working in Alien Dalvik:
install the actual Google Play Service from Google
(Note: I haven't tried it personnally)
install MicroG (an opensource program which re-implements the same APIs)
it provides most of the APIs, including the SafetyNet features (see DroidGuard Helper).
In my experience MicroG is plenty enough to keep my Bank's 2FA happy.
Note: some applications, like mine, might complain also when they don't see the "Google Play Store" (com.android.vending) present. If you don't have it, e.g.: because you use FDroid, Yalp Store and/or the Aptoid provided in Jolla's Store, you'll need to install the dummy package FakeStore from MicroG, to keep them happy.
Note: some other application, according to discussion on this forum, require SafetyNet. Install DroidGuard Helper from MicroG and enable the feature in MicroG's Settings.
Root
There's no su inside Alien-Dalvik to begin with. (On Sailfish OS usually we do most of the admin stuff from within the full GNU/Linux).
Your banking app shouldn't complain about that. If it is complaining about "root" or "SU", usually it's because one of the other tests mentionned above fails. You might need to install FakeStore, or to enable SafetyNet.
Browser
You'll have an entirely different problem here:
The native Sailfish OS Web browser is still based on a very ancient version of Gecko.
(Though according to the latest official blog from Jolla Devs, they are working on this so progressively the situation should get better over the next couple of upgrades).
So you're not going to be able to browse to your bank's website. That's not because they're boycotting Sailfish for not being compliant (in fact, it will be better sand boxed than other, simply because the main OS and Android are sand boxed from each other through LXC), but simply because the browser is too old and probably won't work.
You can temporarily get around that by install Mozilla Firefox for Android (e.g.: from the Aptoid Store) or Bromite from the FDroid store (a mod of Chromium with AdBlocking as an extra).
Even if you're not leveraging the OS-level sand boxing (LXC), you're still benefiting from the in-Android normal app sand boxing, so your Bank should be happy.
I'd certainly consider the SIM card that authenticates the user to the network over which he or she receives the verification SMS to be separated and secure. The actual delivery of that information may not be entirely so, but does/should that actually matter?
attah ( 2019-05-16 00:13:35 +0300 )editI'm just interpreting the directive and IANAL, but in my view (1) the whole point is to ensure a secure "delivery of that information" (2) the spirit of the rule is: how many distinct attacks do you have to successfully perform to get my money? In case of Android/Ios it's 2; in case of a rooted Android or Sailfish it's 1. Point 3b in Article 9 (cited in my last link) seems to refer to rooted Androids, but it's not entirely clear to me what it entails.
Federico ( 2019-05-16 00:55:37 +0300 )edit@Federico: Thank you for your valuable reminder and excellent text. Well done! I have filed a task for our R&D to investigate what should be done.
jovirkku ( 2019-05-16 09:05:39 +0300 )edit@jovirkku Thank you and Jolla for giving attention to this issue!
Federico ( 2019-05-16 10:07:03 +0300 )edit