Can not run android apps that use realm (e.g. Element) after updating to 4.5

[nekron]

So here are the results:

• you can copy the RealmDB files from 4.4 to 4.5 BUT
• need to re-create the pipes (fifo files) manually

The RCA of crashing RealmDBs is that Realm creates *.note and *.cv pipes used for IPC.
At initialization time of the database files - in a working system like 4.4 - the pipe files are created okay.
Appsupport 4.5 however has an issue creating the pipes and it can be resolved by manually creating them using mkfifo *.note|*.cv. You have to change pipe permissions afterwards matching your applications folders user and group.

However this trick is sadly not working for Element. After manually fixing the initial fifo’s you’re able to launch Elements authentication screen where inside the ./files folder a new random hexvalue subdir is created dynamically that is containing crypto, disk and auth databases. These folder and the DBs will be created just-in-time so you sadly have no chance of “mkfifo …” the missing pipes afterwards.

Pipes:

Pipes:

Dynamically created crypto databases (these can’t be fixed as they are created when the authentication against the homeserver is started):

For the kotlin-example from the realm-java github repository this was working fine to get the application running on 4.5 after a fresh APK installation and fixing the missing pipes.

In the end the File or Directory Not Found message from logcat means in reality “I’m not able to create the pipe”.

UPDATE: You can “see” this issue when you appsupport-attach into the Android runtime, change to your Element or any other installed application at /data/data/<package> and try to create a fifo! The mkfifo command will not complain with an error but nonetheless the named pipe is not created. On the other hand if you create the fifo file from the host OS devel-su and cd /home/.android/data/<package>; mkfifo this_is_not_lost.test it will be created.

[nekron]

And last but not least @thigg @jovirkku @zepher @str4el @nas @vige @kaulian and others who joined this club here is the final solution to get RealmDB-based applications working on 4.5 again

• become root (devel-su)
• make a backup of /etc/aas-seccomp-profile (cp /etc/aas-seccomp-profile ~/)
• modify the /etc/aas-seccomp-profile and remove the following two lines
  • mknodat errno 0
  • mknod errno 0

Original aas-seccomp-profile:

2
blacklist
ioprio_set errno 0
sched_setscheduler errno 0
setpriority errno 0
[arm64]
syslog errno 0
mknodat errno 0
mknod errno 0
reboot errno 0
swapon errno 0
swapoff errno 0

Modified aas-seccomp-profile:

[root@Xperia10II-DualSIM de.spiritcroc.riotx]# cat /etc/aas-seccomp-profile
2
blacklist
ioprio_set errno 0
sched_setscheduler errno 0
setpriority errno 0
[arm64]
syslog errno 0
reboot errno 0
swapon errno 0
swapoff errno 0

• restart the Android application support layer from SailfishOS settings

Now Element and all other applications using RealmDB (or creating some named pipes) will work inside the container.

Please note that removing mknod and mknodat can be used to compromise the lxc container. On the other hand without allowing this syscall many RealmDB based applications will break on setup where the named pipes will be created.

[thigg]

impressive! how did you figure this out?

[Ahtisilli]

Cool!

Fixes Argenta Bank, too.

[remote]

so I suppose on 4.4 seccomp profile didn’t have mknod* restrictions and they were added in 4.5?

[direc85]

This also fixed Deezer not being able to save its cache on the SD card (the internal memory still works either way).

[nas]

thank you for your effort @nekron ! Amazing investigation and result!

After I run Element with success, made even video call I had the idea what will happen if I reverse the changes in /etc/aas-seccomp-profile file. I stopped Android support and undid the changes. I started Elements and it it still works just fine!

The only flaw I found but I don’t think it has anything to do with this bug was that I couldn’t join jitsi in the rooms.

[nekron]

@thigg: Well, I’m doing DevOp stuff as an IT professional and containers are everywhere so I remember that many container runtimes can filter specific dangerous syscalls (Google e.g. wrote the gVisor proxy for containers as a kind of syscall emu that firewalls your container between container and kernel for security reasons to prevent that any kernel bugs inside syscalls can be exploited to break out of the container jail). I did some research for lxc and had a look how the appsupport image was integrated into SailfishOS. The rest of the story is history…

@remote: I guess that the seccomp settings didn’t blacklist the mknod* syscalls, but didn’t investigate any further.

@nas: Yes, once the named pipes are created and if your application has no need to re-create databases it’s just fine to revert the change to have more protection inside the container. As for Element the problem is once you unassign the device from e.g. Element web your crypto/auth whatever database will be removed and re-created once you re-authenticate the client (which will break because of the mknod syscall filter).

I personally can live with the risk of mknod syscall pass-through to the devices kernel as old 4.4 aliendalvik did the same and my device didn’t get hacked by some Android application