Good news, the xtables-enabled Docker Snap is now available in the edge channel. I've updated the How to section with the new install commands. If you want to refresh: sudo snap refresh docker --edge --devmode

@fair For the Fairphone 5 I've implemented something which should help you, it's available in latest daily channels. The change is here: https://gitlab.com/ubports/porting/reference-device-ports/android11/fairphone-5/fairphone-fp5/-/commit/13884b434abf95f643f41f04c62b22e73be9fe1c

What it does is keep the device awake once Waydroid starts. That means it won't opportunistically autosuspend anymore while Waydroid is running.

For those wanting to try clickable with the new docker snap, or wanting to build other images on your devices, I noticed a serious performance hit in creating clickable images with the new Docker 29.0.0 which is due to the containerd-snapshotter feature. You can disable it easily though, restoring snapshot creation to a previous codepath. You'll just have to edit your /var/snap/docker/current/config/daemon.json configuration:

$ cat /var/snap/docker/current/config/daemon.json
{
    "log-level":        "error",
    "features": {
        "containerd-snapshotter": false
    }
}

Make sure to restart your Docker daemon afterwards: sudo snap restart docker

@projectmoon overlayfs not being available is a kernel problem, for which you should contact your device maintainer.

Hello again.

Some things happened since I posted the original post above. I've gone ahead and added automatic detection for xtables vs nftables to the Docker Snap, which was received quite positively by the maintainers. Here's the PR for those who are interested: https://github.com/canonical/docker-snap/pull/329

You can install the Snap via:

sudo snap install docker --channel=edge/pr-329

If you've already installed the test package from the Downloads link above, you will have to instead run:

sudo snap refresh docker --channel=edge/pr-329 --amend

When this lands it will first land in the edge channel before promotion to a more "stable" channel, so keep that in mind once you see the PR merged.

@nparafe That device's kernel is too old for using cgroupv2 and eBPF to mediate device access, it's advised in the port to set the kernel cmdline systemd.unified_cgroup_hierarchy=0 and recompile the kernel image. Please tell your device maintainer about this.

@uxes IIRC with fscrypt in place, just replacing shadow breaks the protectors of fscrypt, leaving the system with a broken state. Also that's the dog biting it's tail: decrypting based on the password while the file containing the password is locked, that doesn't work.

Regarding bluez data: that would break bluetooth at the greeter, which might be required for some usecases.

@ikoz Encrypting apps would prevent tampering with executables and replacing them with malicious ones by evil actors.

I want to start a discussion about encrypting more data stored in the /userdata partition, for extra security/paranoia.

Right now we have /home/phablet encrypted when done so via system-settings, but there's room for improvement. I would like to also encrypt:

• Wifi settings
• Apps
• Potentially more which I don't see yet

For apps I have created a script which does the encryption in an easy-to-follow manner. This will require a device with policy version 2 support. It's available here: https://gist.github.com/fredldotme/696ab1e22bec4ed296caee471aa89a87

ATTENTION: Don't try to force the script to run on a system which only supports v1 policies, this will break app installation and uninstallation.

The script keeps the unencrypted original in /userdata/system-data/opt/click.ubuntu.com-bak which you will have to remove manually after rebooting.

Encrypting data which is usually accessed by non-phablet users will require v2 policy suppport, so keep that in mind when coming up with ideas.

Any input?

I've updated the kernel to 4.19.242 now locally, will test further and merge this ASAP.

Some hours, 4 cans of XL energy drink, and some patience later and I upgraded the kernel to 4.19.198. That's 41 patch versions fresher than before!

I will do these updates in stages. First I'll update until I feel comfortable with it, test it for a day, then merge it into the release branch. Also I've been able to catch some discrepancies I wouldn't have been able to catch otherwise if I just merged the latest upstream git into our kernel. Leaves me some peace of mind.

Hello there!

I am using the Fairphone 4 as my daily driver at the moment, and I want to ensure good security of the device. Henceforth I am updating the kernel from 4.19.157 to the last stable release 4.19.325 from December 2024. While no major update this will ensure added patches to known CVEs.

Please be aware that this is a tedious process, taking incremental patches from upstream kernel.org, applying them, checking conflicts, building them and testing them on the device. It will take some time until we reach 4.19.325, so please be patient.

If you think that's a worthwhile thing to do, please leave a donation (I could really need it). Links below in my signature.

@gpatel-fr I agree your approach using overlayfs is better, puts the file in the same place we would regularly put our customizations.

@pparent a technical explanation as to why this app will always be slow with Xwayland:

X11 historically uses GLX for passing buffers from the client to the server, and GLX inherently is tied to Desktop OpenGL. Desktop OpenGL and OpenGL ES as used on Ubuntu Touch devices are different. The only way forward would be EGL and that would require changes to Xwayland to handle the Android driver's/libhybris EGL implementation.

I tried bringing hardware acceleration to Xwayland once and it resulted in only one device (the JingPad) being remotely capable of doing it, with render artifacts. Since then we run Xwayland in shm mode which guarantees software rendering in all cases. So whatever you perceived as hardware accelerated before must have been a placebo.

@nielsbasjes you can use systemd mount units for this, we allow writes to /etc/systemd/system:

• Copy your modified NetworkManager.conf to /etc/writable as a safe spot
• Create a file /etc/systemd/system/etc-NetworkManager-NetworkManager.conf.mount with the following contents:

[Mount]
What=/etc/writable/NetworkManager.conf
Where=/etc/NetworkManager/NetworkManager.conf
Type=none
Options=bind

[Install]
WantedBy=local-fs.target

• Enable the mount unit: sudo systemctl daemon-reload && sudo systemctl enable etc-NetworkManager-NetworkManager.conf.mount

Let me know if it works for you, a quick reboot with this applied on my FP4 resulted in the same IP assigned as before.

@Thomas I presume your choice between a de-Googled Android and Ubuntu Touch should revolve around whether you want Ubuntu as your Operating System on the phone or not. We take security seriously and we're slowly catching up, see encryption of your data being a thing on 24.04.

@arubislander Regarding containers not having access to the internet: It might be the device is using "Paranoid Android Networking" in the kernel, stemming from Android, which limits use of sockets to a special group ID.

To device maintainers wanting to support LXD, you will want to check whether CONFIG_ANDROID_PARANOID_NETWORK is in your kernel tree (simply grep recursively for it) and if so, set CONFIG_ANDROID_PARANOID_NETWORK=n in your defconfig. I've since fixed this on the FP4 and verified working networking on the FP5.

And here a little success story on combining the Clickable Snap & the Docker Snap, allowing to build AND test a click package directly on the device (in this case a JingPad). Photo courtesy of Sander:

Hello again!

I've been working on bringing Docker to Ubuntu Touch, with success! Although not completely finished, I'd like to share what is possible today.

This requires a device with snapd installed, so either Ubuntu Touch 20.04 with Snapz0r (untested) or Ubuntu Touch 24.04-1.0 and up.

This required changes to the Docker Snap, with a PR on GitHub that has received two heart reactions by the maintainers, so the chances of this PR landing upstream are high. For those interested in what was necessary: https://github.com/canonical/docker-snap/pull/327

I've shared a preliminary build of this Docker Snap on Google Drive and my private NextCloud instance, until the PR is merged upstream. Download links are below.

A Pull Request with automatic firewall detection has been merged upstream, so I have removed links to my private builds. Instead follow the instructions in How to to get a working Snap on your device.

For this Snap to work on all devices, one will currently have to install it in "devmode", a mode which disables confinement for this particular Snap. This effectively means that it will run with the same privileges as an apt-installed Docker package. For confinement to work this will require additional work in snapd which I'm currently waiting for input on: https://forum.snapcraft.io/t/getting-docker-snap-to-run-on-ubuntu-touch-with-k4-19-5-4/49243

Kernel support

For Docker to work your device's kernel requires a certain set of features enabled. I've tried to list them here: https://gist.github.com/fredldotme/5dffc8bfa410cfa8f541276407154494

Also, if the device uses CONFIG_ANDROID_PARANOID_NETWORK in it's configuration, it might be beneficial to disable that also since otherwise containers won't be able to connect to the internet.

How to

1. Install the Snap on your device: sudo snap install docker --edge --devmode

2. Test whether Docker works: sudo docker run hello-world

3. For running Docker without sudo, set up your user appropriately:

sudo addgroup --extrausers docker
sudo adduser $USER docker
newgrp docker
sudo snap disable docker
sudo snap enable docker

4. You're done!

If you feel really adventurous you can now even install the Clickable Snap (sudo snap install clickable) and develop your Ubuntu Touch apps directly on your Ubuntu Touch device. How awesome is that?

Hello all!

I've created a little script to aid in the recovery of data, should one choose to enable encryption on their device.

It's available here: https://gist.github.com/fredldotme/7bc4e5aee515d8b74a7b091599e67382
Save the script as chroot-into-system on your PC.

The guide assumes you have adb installed on your PC. The steps are as followed:

1. Boot your device into recovery mode
2. Mount your system partition by going to "Advanced" -> "Mount/unmount system"
3. Open a terminal on your PC and switch to the directory you saved the script in
4. Push the script to your device: adb push chroot-into-system /tmp/
5. Run an adb shell
6. Execute the script: sh /tmp/chroot-into-system
7. Now it's time to unlock the home directory: fscrypt unlock /home/phablet
8. Enter your PIN or password and hit enter
9. The home directory contents should now be decrypted and visible

Please try it on your device and let me know of any issues.