S1m

5 years of UnifiedPush

2025-12-31T00:00:00+00:00

It has already been 5 years since UnifiedPush started! It also means I don't have any Play Services, the official or microG reimplementation, for 5 years now. It is a good moment to do a recap, and think about what can be UnifiedPush in 5 years.

It turns out I don't remember in details how all started, I need to read some historical pull requests and chats.

Why do I need push notifications?</h1>
I think I've installed my first alternative ROM, LineageOS</a>, around 2013, and never went back to stock ROMs since then. At this time, I didn't really care about the apps I was installing, it was mainly to take control of my devices and get rid of the bloatwares.
I understood that I needed the Play Services, or a reimplementation, for some applications to properly work, and I was vaguely knowing why. So, every time I updated my phone, I had to boot into the custom recovery (TWRP), to flash a zip, to get microG. It was, well .. not the best user experience.
Then, I tried to stay without the Play Services, it was even worse, messages weren't reliable, the battery drained and there were many foreground notifications, which I understood were required to keep a service running.
So I decided to go with a fork of LineageOS that includes microG by default, and distributed by microG team: LineageOS for microG</a>.
Even after using this new system, the experience was nearly the same. Why? Because most of my apps were from F-Droid. Push notifications with Google (via microG) require the use of a proprietary library , which comes with telemetry, unless explicitly configured to exclude them. F-Droid deny this library, which is fair given that their purpose is to promote free software.
That's actually possible to use FCM (Google notifs) without Google lib, but I didn't know that at this moment. Cf. UnifiedPush blog post about push notifications for decentralized applications</a>, or Molly issue regarding FOSS FCM implementation</a>.
Gotify (2020)</h1>
So, we're in 2020, and I finally want to look why I can't use microG with Fedilab and Element from F-Droid, and if we can replace microG with another notification app.
It turns out among others notification applications, F-Droid distributes Gotify</a>. It isn't able to forward notifications to other apps, but there is an issue opened for that feature</a>, and jmattheis, the developer seems open to the idea.
I didn't touch any Android dev at this moment, but I tried to hack something. Fortunately, jmattheis review helped a lot to make things less hacky. So here came gotify-connector.
It looks like from the pull request history that "connector" comes from jmattheis, for which I added "distributor" later.
At this moment, the feature has picked the interest of some persons, including sorunome, karmanyaahm and sparchatus. Sorunome, contributor to FluffyChat, told me that the feature may interest people in OpenPush</a> matrix room.
First UnifiedPush version (2020)</h1>
Late 2020, looking at some p2p projects, I thought it would be cool having a p2p based solution too. So came the questions about ecosystem lock-in of a gotify only solution, adoption, and fragmentation. If we have multiple applications able to provide push notifications, we should have a library that is compatible with all of them. When a new application providing push notifications is published, then all existing applications supporting the thing would be directly compatible. Going that way, we needed to specify how it should work first.
I shared the idea in OpenPush room, and it picked the interest of someone in particular, sparchatus, who helped me to write the specifications. We discussed many edge cases to see how things could be.
I published a first version of the specifications, a library, and a fork of gotify until the support was merged .*
Sorunome was interested in implementing the support in Fluffychat. It required a flutter lib, karmanyaahm wrote a lib porting the already published library to the framework. We also needed something to translate matrix push protocol, and make gotify server compatible: karmanyaahm wrote common-proxies for this.
* Which actually never happened 🤷
FluffyChat, Fedilab, and more (2021)</h1> Early 2021, FluffyChat</a> was supporting UnifiedPush. And soon came Fedilab</a> too, as the dev, Thomas, was directly interested.
Starting with these 2 applications was a chance for the project: we had support for matrix, and many other chats using matrix bridges, and for the fediverse. This covered enough applications for some FOSS enthusiasts. Retrospectively, UnifiedPush may never have started without these 2 applications.
After that, some applications started to implement the feature, such as a Tox application</a>, or FMD</a>, a FOSS solution to find your device.
Mid 2021, I implemented UnifiedPush support for Element</a>, which was soon merged by SchildiChat</a>, a fork. I think the experience from SchildiChat helped for it being merged into Element mid 2022.
UnifiedPush for Linux (mid 2021)</h1>
At this moment, vurpo came to UnifiedPush matrix room to talk about push notifications for Linux devices. So we had UnifiedPush for Linux by mirroring the specifications for Android to D-Bus IPC.
ntfy, NextPush (2021)</h1>
During 2021, a new project appeared on the Internet: ntfy</a>. A project like Gotify, that can work without any account, with a public server. The app is extremely easy to use, as you have nothing to set up. And the developer, binwiederhier, was directly interested in supporting UnifiedPush, to make ntfy a distributor.
Merged early 2022, it was an important step for UnifiedPush: we have a distributor to recommend by default.
I have also implemented NextPush</a> at the same period, giving an easy opportunity to self-host a push server, if you already host a Nextcloud server
In the same time, Gotify developer informed us that they finally prefer not to merge the support, as they don't use it and prefer to avoid adding maintenance to their project, which is perfectly understandable. With this new position, the official support of UnifiedPush by ntfy, and the new NextPush app, I preferred to discontinued Gotify forks as well.
KUnifiedPush (mid 2022)</h1>
Mid 2022, the KDE</a> team, and particularly vkrause, published KUnifiedPush</a>: a distributor for Linux, compatible with different push server, like ntfy or NextPush. Until then, we only had POC implementations of distributors for Linux. KUnifiedPush also provide libraries for KDE applications.
This allowed Linux applications to finally support the protocol.
Full-time on UnifiedPush (2024 - 2025)</h1>
At the end of 2023, we have more than 20 applications supporting UnifiedPush, and another distributor: Conversations</a>. Element being probably the one with the larger user base at this moment. Someone advised me to apply for a grant with NLnet</a>, as it would boost development of the project.
During the application process with NLnet, COVESA</a> reached me because they wanted to support the project, but needed a few features that weren't present, to get a more robust authorization mechanism and avoid registration spamming.
UnifiedPush has always been compatible with web push (RFC8030 and RFC8291 but RFC8292, aka VAPID, wasn't). Embracing the standard to require web push was a potential step to take. The specifications needed to be updated in that direction, to require encryption (RFC8291) and to handle authorizations with VAPID (RFC8292). Relying on standard will hopefully help for the adoption, as the server side implementation may be used for web applications in the same time.
At the end of 2024, I've started working full-time on UnifiedPush.
Working with COVESA also allowed to get Sunup</a>, a distributor using Mozilla's push server, autopush</a>, and to add a self-hostable backend for autopush. This feature is currently being merged.
NLnet gave the opportunity to polish many things that were pending, to add a migration feature to the protocol, which can be used to get a fallback service when your self-hosted server is down, to implement the actual web push specifications on Mastodon, and to add web push/UnifiedPush to some applications. It includes Fennec/IronFox, forks of Firefox, so we can now get push notifications with web applications. It also includes SimpleX (being merged), Nextcloud (being merged), DeltaChat (TODO), and flatline (TODO), a self-hostable version of Signal server, hopefully upstreamed to Signal servers.
The idea is to increase the network effect: the more applications support UnifiedPush, the more UnifiedPush can be relevant for users, and the more users will use UnifiedPush. If the number of UnifiedPush users increases, it pushes applications' developers to support the protocol. At the end, we can use our phone with the push service we want, to get an expected user experience even without the Play Services.
Retrospective</h1>
It was by chance that I started UnifiedPush and the project would never have existed without other projects like F-Droid, gotify, matrix, Fluffychat or Fedilab, and many more, without the help of many people.
I think it shows how the FOSS ecosystem can be beneficial for everyone. I develop Sunup, but often contribute to ntfy. The projects could be seen as "concurrent", but aren't: the applications answer different needs. We don't have anything to win or lose if a user chose one app over the other. But we all win if a user chose to use one, no matter which, as it increases the network effect.
If UnifiedPush wasn't started 5 years ago, I'm sure an equivalent project would have started since then. This is something that was awaited in the mobile FOSS community, and there were already some research work on the subject.
I wasn't aware how many things were implied with push notifications. It is understandable that giving a single entity the capacity to provide such an important feature give them incredible power. This is concerning when their solution doesn't follow least-privilege policies, come with system rights, has access to the full system, and with "features" we don't want, such as advertisement and telemetry.
I now understand why push servers may be a tool for mass surveillance and how an open solution is important for resilience. Some networks exist outside the Internet, some regions in the world suffer from services block, some users may be banned from these services. When a service is controlled by a single entity, nothing can be done when they consider your device too old to be supported. Offering an open alternative is a response to all these problems.
The idea is not to move everyone to an open solution, but to give the freedom to. Supporting these alternatives also reduces risks of power abuse from Google. If you develop an application, ask yourself how fast could you recover from being banned by Google?
Working full-time on UnifiedPush is incredible. I'm extremely happy a foundation like NLnet exists. I hope my work is beneficial for the project and for most of the users. When it all started, I didn't imagine a second I could work on this, I just wanted my matrix and mastodon notifications without the Play Services.
I would love to continue working daily on UnifiedPush, and there are probably tons of things to do, specially for Linux devices, and many apps to port the feature to. But NLnet funds aren’t unlimited, our main goals are reached - improving the protocol, improving the existing code and documentation, boosting the network effect on Android -, and I don’t want to take the potential place of another project.
Among other things, we still need to improve libraries for UnifiedPush on Linux, and it’d be great to have a UI for KUnifiedPush to publish it on Flatpak. There are some important applications, such as Mozilla sync service, that use an allow-list of authorized push servers, defeating the purpose of self-hosting: it would be great implementing a better anti-SSRF mechanism. We will probably have to build these blocks and others together. If you want to contribute, do not hesitate to PM on Mastodon</a> or join UnifiedPush matrix room</a>.
UnifiedPush in 5 years</h1>
The best thing that could happen to UnifiedPush on Android in 5 years would be for it to no longer exist.
If Android gives us a system API to let the user define their push service we wouldn't need UnifedPush anymore. Passkeys (API to login without passwords), used to be provided by the Play Services only. Today, probably to increase the adoption, Android has migrated to a system API (Credential Provider</a>), to allow any password manager to provide the service. With a Push Service API, UnifiedPush would have kind of been integrated into the OS. The applications would receive push endpoints like we do, and they would send web push requests, following standards, like web applications does, like UnifiedPush does. Migration from UnifiedPush would be minimal.
If we manage to have such a Push Service API, we can expect many more apps supporting the feature. And we will finally be able to choose the services we want to trust.
Hopefully, working on UnifiedPush can push in that direction by increasing the demand, and highlighting the need.
On Linux, I think the adoption depends a lot on how the mobile Linux ecosystem evolves. I personally think and wishes that it goes in the right direction. And I think a lot of things can happen in 5 years on the matter.

About Signal PIN

2025-11-29T00:00:00+00:00

Edit 2025-12-26</h4>
Correction of the risk analysis: compromission of the PIN infrastructure in combinaison of a weak PIN can lead to metadata leak, including the social graph. I had wrongly assumed that the IKs were restored with the masterkey, but they are restored only with the backups or with a device transfert. This resulted in a higher risk in case of compromission. </blockquote>
Signal threat model is well defined: your communications are protected even from a rogue server. It follows the Kerckhoff's principle</a>, a crypto system should be secure if everything, except the keys, is public knowledge.
This is why jurisdiction is nearly irrelevant to the security of encrypted messaging apps</a>
The only security property the server should be able to impact is availability, which is why the jurisdiction actually matters a bit, specially when the said jurisdiction imposes embargoes to your region. A good encrypted messaging app is one you can use.
With such a threat model, there is no need for a Trusted Execution Environment (TEE) like SGX</a>, which is supposed to ensure the storage is accessible to attested programs only. So, why Signal does need a TEE?

TL;DR</h1>
Signal uses your PIN to encrypt and upload your keys; set a high-entropy PIN (+20 random alphanums) to protect your metadata including your social graph, and stay resistant to brute force and dictionary attacks if the PIN infrastructure is ever compromised. </blockquote>
Account and identities</h1>
When you register on Signal, you get 2 different identities: one for your phone number, the PNI, and another for you account, the ACI.
Details about the PNI and ACI</summary>

The PNI is your phone number and the ACI a random id. When you change your phone number, you get a new PNI. And your ACI never change for your account.
When you configure the phone number visibility , who can see my phone number and who can find me from my phone, you change the possibility from someone to find the PNI from the ACI and vice versa.
If someone register with your old phone number, they get your old PNI.
The contact discovery is a registry that link the username and account URL to user account. From a username you can get the account id, but not the other way around. </blockquote> </details>
The application generates 2 identity keys (IK) during the registration, one for each identity. And these keys are the root of all the session keys encrypting and protecting your communications.
The safety number you can use to verify a contact is generated from your and your contact IK.
After generating the identity keys, the mobile application generates prekeys that are signed by the IK and stored on signal server. These prekeys are used by other users for a first contact, to calculate a shared secret. These prekeys are what allows you to be contacted when you're not online. When the session keys with a contact are desynchronized, your contact picks new prekeys and calculate a new shared secret.
Keeping these IK secret is mandatory to avoid Adversary-In-The-Middle. If the server has access to the IK, it can send your contact prekeys it has generated. Doing it allows the server to decrypt incoming messages, and forward them re-encrypted with a legit prekey you have generated.
Registration lock</h1> The registration lock</a> is a feature that prevent someone to re-register to Signal with your phone number.
If someone re-register with your phone number, and you didn't enable registration lock, a new account is created for them, with your old PNI.
They will use a new ACI and new IKs. So your contacts who haven't updated your phone number will see that the account with your (old) phone number has a new identity.

Your safety number with S1m has changed. </blockquote>
This warning is a solution good enough to warn about something suspicious. Or it may be expected when your contact has yet again lose their phone (👀).
But most people don't really look at the safety number: taking over a phone number may be enough to impersonate the person.
This is concerning because SMS aren't secure:
they are vulnerable to SCAM like SIM swap</a></li>
they aren't encrypted and can be read using an IMSI catcher</a>, or by your ISP (Don't use SMS as a 2FA).</li> </ol>
To protect against SMS attacks, Signal gives the registration lock: you set a PIN to protect your account, and Signal will require this PIN to use the registered phone number.
As people may change their phone number, the registration lock expires if someone re-register with the phone number and the account has been inactive for 7 days.
Account recovery</h1>
So, what happen when you are restoring your account on a new device? You enter your phone number, receive an SMS, resolve a couple of captchas and? You verify your Signal PIN.
For this, the application will interact with the Secure Value Recovery (SVR), part of the Signal server. To prove the knowledge of the PIN, the application hashes the PIN with the argon2i</a> algorithm (salted</a> with the ACI, and the enclave id), and split the result in 2 different keys: the SVR access key, and the SVR encryption key.
The access key is used to request the SVR to download the encrypted masterkey. Which is the masterkey, encrypted with the SVR encryption key.
Details about the masterkey</summary>
The masterkey (derived from the Account Entropy Pool) is one of the main key from which other secrets are derived, like the recovery password</a> and the registration lock token</a>. </blockquote> </details>
The masterkey is decrypted, and the recovery password is calculated from it. If registration lock is enabled, the registration lock token is calculated too. Then the application request the Signal server to finish the registration using the recovery password and the registration lock token.
The application download the encrypted account data</a> stored on the storage server. The data includes the encrypted profile key (used for the profile name and picture), and your social graph. Then the app decrypts them with a key derived from the masterkey.
You can now talk to your peers, and, if you haven't restored your data from a backup, your safety numbers has changed.

Note: This previously contained an error: without a backup, or a device transfert, all the safety numbers change. </blockquote>
Trusted Execution Environment ?</h1>
The SVR is one of the components using the SGX (Intel Trusted Execution Environment). Why? Because as we've seen above, the masterkey is stored there encrypted using a potentially very weak secret: the Signal PIN.
Using a TEE is an answer to this use of the PIN. It allows the client to verify that the code running on the enclave is the one expected, and the TEE should prevent any code outside the enclave to access its data. The certified code limits how many times you can request the service, so it should be impossible to guess the access token (and the PIN).
But, this is a shift in the threat model. Remember? Your data must be protected even from a rogue server. It should be secure if everything, except the keys, is public knowledge. Now, if you use a weak PIN, your metadata including your social graph relies on the security of the SGX.
If an attacker can bypass SGX security: they can download your encrypted masterkey, and guess your PIN: Argon2id is pretty slow, but the PIN requirement is only 4 digits, making brute force attacks possible. Then it is possible to download and recover the account data, including the social graph.

Note: it is impossible to get the identity keys from the masterkey alone, they are stored in the backups only. If your backup file is compromised, and a rogue server get access to your IKs, it could upload its own prekeys and start an Adversary-In-The-Middle attack. </blockquote>
And of course, SGX isn't immune to vulnerabilities (just random links):

https://sgx.fail/</a></li>
https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html</a></li>
https://nvd.nist.gov/vuln/detail/CVE-2025-38334</a></li> </ul>
Weak PIN requirement</h1>
The registration lock is older than the account recovery. (cf. the migration to PIN v2</a>)
When the PIN was only about the registration lock, it was OK to use a 4 digit PIN, as its purpose was to protect against an external attacker trying to take over a phone number identity (but not over the ACI and the IK). At this time, the PIN was sent unencrypted</a>, and was probably stored hashed on the server, as we usually do with passwords.
When the PINv2 and the account recovery were introduced, the requirements were changed: new PIN needed to be 6 digits and more</a>.
The old PIN (which were sent unencrypted to the server) were directly used for the new recovery system</a>, they were used to encrypt and send the master key to the SVR.
But then, the PIN code was cleaned up, and the new requirement was dropped</a> and stayed 4 digits until then.
Recommendations</h1>
I am sure some users have a weak PIN thinking it is only about SMS attacks.
I think users are used to set "long" alphanum passwords everywhere, and it wouldn't be a friction to users if Signal were increasing their requirements, especially when the PIN isn't required.
With the introduction of the new cloud backup, Signal asks the user to write down the root of other secrets (the AEP) which is probably going to replace any use of the PIN. So, it looks like Signal is already working to totally get rid of this.
As you likely have a password safe, generate a high-entropy PIN (+20 random alphanums) and you're good.

systemd-homed: not enough space to start or free up space

2025-10-19T00:00:00+00:00

TL;DR</h1>
If you're using systemd-homed, it may be a good idea to store a file in the home partition that can be deleted when your disk is full, so that you can mount your home to free up space.
dd bs=1M count=1024 if=/dev/random of=/home/EMERGENCY</code> </blockquote>
Yesterday, I spent my evening at my first install party, debugging different setups and finding solutions for obscure bugs. To take it easy, I start doing a little routine development today, until my laptop freezes, shuts down, and refuses to restart. Debugging weird bugs is actually not over.
It directly reminds me this problem I had when my disk was full on a previous Arch install. And I know my disk was nearly full, and this last ISO I've downloaded yesterday may have filed the remaining space.
Rescue</h1> The strategy is simple: I boot on a live system, decrypt and mount my user partition, remove some files, and reboot. I don't even need to boot on a Live USB as Particle OS gives a Live system UKI entry (it boots on a temporary system populated by the unencrypted and read only usr partition) But, I get some errors when trying to mount my user home: # losetup -fP --show /home/user.home loop0 # cryptsetup open /dev/loop0p1 user # mount /dev/mapper/user /user/home No such file /dev/mapper/user # Reproduced from memory </code></pre> The error was something like this, I'm not 100% sure. And it came with Kernel log: BTRFS: device label user devid 1 transid 141091 /dev/mapper/home-user (253:3) scanned by systemd-homewor (69355) BTRFS info (device dm-3): first mount of filesystem 9d30717d-d824-47bf-be84-14018eaed1e4 BTRFS info (device dm-3): using crc32c (crc32c-lib) checksum algorithm BTRFS info (device dm-3): start tree-log replay critical space allocation error, dev loop0, sector 12110384 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 critical space allocation error, dev loop0, sector 12110416 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 critical space allocation error, dev loop0, sector 17177536 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 critical space allocation error, dev loop0, sector 17177568 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 critical space allocation error, dev loop0, sector 12110448 op 0x1:(WRITE) flags 0x1800 phys_seg 2 prio class 2 critical space allocation error, dev loop0, sector 17177600 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 critical space allocation error, dev loop0, sector 12110512 op 0x1:(WRITE) flags 0x1800 phys_seg 3 prio class 2 critical space allocation error, dev loop0, sector 17177632 op 0x1:(WRITE) flags 0x1800 phys_seg 4 prio class 2 critical space allocation error, dev loop0, sector 12110608 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 critical space allocation error, dev loop0, sector 12110640 op 0x1:(WRITE) flags 0x1800 phys_seg 1 prio class 2 BTRFS: error (device dm-3) in btrfs_commit_transaction:2538: errno=-5 IO failure (Error while writing out transaction) BTRFS warning (device dm-3 state E): Skipping commit of aborted transaction. BTRFS error (device dm-3 state EA): Transaction aborted (error -5) BTRFS: error (device dm-3 state EA) in cleanup_transaction:2023: errno=-5 IO failure BTRFS: error (device dm-3 state EA) in btrfs_replay_log:2091: errno=-5 IO failure (Failed to recover log tree) BTRFS error (device dm-3 state EA): open_ctree failed: -5 </code></pre> So, if the issue is the disk being full, it means I can't mount my partition, to free some space, because ... it is full. As a btrfs check</code> gives nothing, it is time to backup my current home before doing anything. Fortunately, I've my external drive here, so let's copy my 150G user.home</code> image on this drive 🥲 A few cups of coffee later, when the copy is finally finished, I try to mount (losetup</code>+cryptsetup</code>+mount</code>) this image from the external drive, and it works. That's great, all my data is back up, and it means I couldn't boot or mount my home because my laptop drive was indeed full. So I just have to remove some files from this local copy, unmount it (umount</code>+losetup -d</code>), copy the new user.home</code> to my laptop, drink a few more cups and we're done. For the next time</h1> I was lucky being at home this time. How could I have rescued my laptop if I hadn't my external hard drive? And how can I avoid these (excessively) long copies? => Simply with a file that I can delete in an emergency if I fill up my disk again. # dd bs=1M count=1024 if=/dev/random of=/home/EMERGENCY </code></pre> And with a blog post to remember why I have this EMERGENCY file in my /home. Edit: The root cause of the problem is that I configured my home with homectl update --disk-size=max</code> while I have 2 users on the system.
Isolation for terminal environments 2025-05-25T00:00:00+00:00 TL;DR</h1> I've tinkered with a solution based on systemd user-services: https://codeberg.org/s1m/termenv</a>. It works as expected but I wish there was a stable solution for this. </blockquote> For long time, isolations on operating systems has been about isolations between users only. It was accepted that applications of a same user were able to access the same files, and interact with each other. They all have the same rights. Mobile OS (Android, iOS) has introduced isolation of applications. Two applications can't be trusted the same way, and they don't need to access the same data. Applications are still allowed to interact with each other, only through dedicated interfaces. They have their own storage for their data and their config. If they need to access other directories, the user have to agree to. The applications may use the device settings but, except dedicated applications, they aren't allowed to edit the settings. As for mobile devices, we need a way to isolate applications on desktop. On Linux, a well known solution is flatpak</a>. Flatpaks are build with a manifest that defines the permissions of the application. They can mount some user directories if they need to read them, access devices, sockets, etc. Portals exist to grant permissions to some resources during runtime. Most graphical applications available on Linux are also distributed with flatpak. CLI applications and services are usually isolated using containers, and systemd services. Isolation for terminal environments</h1> In addition to graphical applications, I wish to have different environments on my terminals, isolated from each other. On terminals, per environment isolation is relevant, as we usually use many different applications in a single session. I need an environment as restricted as possible responsible to update my configs and my user packages. The config and the user packages must be read-only for other environments. And I need to be able to restrict access to directories of other environment if I want to. It avoids the easy bashrc backdoor, having tens of new hidden directories created with different dev tools, messing with virtual environments and user packages, and so on. To define my needs: In the environments, the host system must not be modifiable</li> A single environment dedicated to update user packages must be allowed to do it, and everything else must be inaccessible</li> A single environment dedicated to update my config, must be allowed to do it, and everything else must be inaccessible</li> My configs must be readable to all other environments</li> The different environments must be able to override some config/directories, for themselves - this should not include sensitive directories, like the exec directories, the auto-executed scripts, or where the environment is defined.</li> In the environments it must not be possible to trivially escape the sandbox.</li> </ul> Many solutions to get different working environments exist: toolbx</a>, based on podman, allows to run different system with access to the user directories. It doesn't support isolations of the user home and runtime directories out of the box.</li> distribox</a> is similar to toolbx, but I haven't looked into it</li> systemd-homed areas</a>, introduced in v258 but it only provides the ability to change the home directory to get different configs (yet?).</li> </ul> Nothing fit my needs out of the box, so I had to tinker with something. I was previously using something based on toolbx: I used to generate containers to change the home directory and mount read-only some directories. My current solution</h1> With my recent move to ParticleOS</a>, an experimental image-based distribution with a deep integration of systemd, I've decided to edit my terminal environment scripts to use user managed systemd services. There are 2 executable scripts: termlaunchmenu</code> that starts a menu to select an environment to run the 2nd scripts, te</code> that applies the configuration of the said environment, and starts my configured command in a transient service. termlaunchmenu</code> is not very configurable at this moment, and may need to be edited. It's supposed to be started with a system keyboard shortcut, and it depends on wofi. te</code> is much more configurable. The main config file is located at $HOME/.config/te/conf</code> and it defines the command executed by the transient unit, the different group of directories, and the default inaccessible, read-only and read-writable directories. To avoid the sandbox being trivially escaped</a>, $XDG_RUNTIME_DIR/bus</code> is inaccessible to all the environments. Then the different environment config are defined in $HOME/.config/te/sessions/env_name</code>. For example, the environment dedicated to update cargo packages is defined as follow: $HOME/.config/te/sessions/cargo: NO_PATHS+=( ${DEV_PATHS[@]} ${DOC_PATHS[@]} ) RW_PATHS+=( ${CARGO[@]} ) </code></pre> The source is available on Codeberg: https://codeberg.org/s1m/termenv</a>. Results</h1> So far, the solution works well. A few things can be improved (like denying access to runtime directories by default, and write an allow-list). I honestly would prefer to have a stable solution for this. It would be fantastic if systemd-homed areas could be improved to allow to: Restrict access to the system</li> Restrict access to the root home (/home/myuser/</code>) and to the other areas</li> Restrict access to the user and areas runtime directories</li> Bind the content of the root home (inaccessible, RO, or RW)</li> Define group of directories and configure how areas mount them (RO/RW) or not</li> </ul> Sandboxing and sandbox escape with systemd 2025-05-12T00:00:00+00:00 Today, the most popular Linux service manager is systemd. Services are defined in units located in defined directories. Package units are in /usr/lib/systemd/system</code> and administrators add their units to /etc/systemd/system</code>. In addition to the system service manager, systemd provides a user service manager, for user services. User units are in other directories, including in the user's home directory. System and user services can be sandboxed with many different properties, including restrictions on the file system, device access, net interfaces, and so on. TL;DR</h1> Because (1) with transient units, it's possible to create a new service without writing a configuration file, (2) read-only access to systemd socket doesn't prevent communication with it, and (3) systemd access control relies on polkit only: having a read-only filesystem doesn't prevent the creation of new services with more privileges than the current one. Access control is based exclusively on polkit, which only works with the system's service and authorizes all calls from root. If you write units, do not run your system unit as root</code> and add ProtectHome=true</code> to your service unit. Else, the systemd unit sandboxes are trivially escaped. If you really need to run as root, you may deny access to systemd sockets as a workaround. It's not a bug, but it's not explicitly documented. If you are using another sandbox system, be aware that these sockets can also be used to escape it. </blockquote> Introduction</h1> As introduced recently</a>, I've recently reinstalled my laptop. In my previous setup, I was using container-based isolations for various shell environments. I had a script to generate new toolbox</a> containers with some isolations, for the home and other directories. No surprise, this time I wanted to switch to a systemd-based isolation. (I will share in another post) systemd-run</code> is a tool to run services on-demand using transient units, temporary units managed by systemd. It's a useful tool to do some tests, or schedule tasks for example. Every time a new interactive shell is started with systemd-run (systemd-run --user -S</code>), an orange circle is added to the title of the terminal window (🟠 ~</code>). Other systemd features use transient units, like systemd-mount: it starts a temporary unit that mounts a device on the filesystem. I was using systemd-run</code> to test some sandbox properties (--property ProtectSystem=strict</code>) until my window ended up with 2 circles in its title (🟠🟠 ~</code>). A few questions then arise: Does systemd control somehow the restrictions of the caller service before starting a transient unit, so a new service can only have additional restrictions (and not lose them)? Does it concerns units managed by the user service manager only or the units managed by the system service manager too? Did I miss something? Impacted configurations</h1> Transient units are temporary services managed by the service manager. They don't require any config file. So, as soon as we can talk to systemd, it is possible to start new units, even if we don't have write access to the config directories. It can be more explicit, but the Sandboxing section of the man page</a> of systemd.exec</code> contains a sentence about the ability to talk to systemd on a read-only system: Note that the various options that turn directories read-only (such as ProtectSystem=</code>, ReadOnlyPaths=</code>, ...) do not affect the ability for programs to connect to and communicate with AF_UNIX sockets in these directories. These options cannot be used to lock down access to IPC services hence. </blockquote> Polkit is used by systemd to do access control. Polkit is a toolkit to allow unprivileged processes to speak to privileged processes. It allows any call from root to run privileged process, and it isn't used for systemd user service manager (which runs as a user, so isn't privileged). Given the 3 last points, we can predict 3 possibilities: systemd controls the caller service, and prevents sandboxed services from launching transient units with more privileges than their own</li> systemd controls the caller service, and prevents sandboxed services from launching transient units</li> systemd relies exclusively on polkit for access control, and no other control are performed</li> </ul> [root@archlinux ~]# systemd-run --property DeviceAllow=/dev/vda1 --property ProtectSystem=yes -S Running as unit: run-p503-i803.service; invocation ID: 4d8fd6bf06534e50b5b478d209c53d7b Press ^] three times within 1s to disconnect TTY. [root@archlinux root]# mount /dev/vda2 /mnt mount: /mnt: fsconfig() failed: /dev/vda2: Can't open blockdev. dmesg(1) may have more information after failed mount system call. [root@archlinux root]# systemd-mount /dev/vda2 /mnt # Accepted Started unit mnt.mount for mount point: /mnt </code></pre> It turns out that systemd relies exclusively on polkit for all access controls. And because polkit isn't used for user units, and because polkit accepts all requests from root, user services and services running as root are able to launch new systemd services with more privileges than their own. In other words, ProtectSystem=strict</code> alone does not prevent the process from trivially gaining full access to system using systemd, without any sandbox attributes. If the service runs with another user, but doesn't set ProtectHome=true</code> (implied by DynamicUser=true</code>), or deny access to systemd sockets (InaccessiblePaths=/run/user/<UID>/bus</code>), then the user service manager can be used to start a new service without sandbox attributes. POC</h1> These tests can be performed with transient units, using systemd-run</code>, but in order to confirm that these tests apply to real units, we can use a unit file that exposes a bash shell to the network with socat</code>. To illustrate the problem, we can try different configurations with sandboxing options: A system unit running as root</li> A system unit running as a user, the escape works only when the user is connected</li> A user unit</li> </ul> Below are two examples, one for the system unit running as root, the other for the user unit. System Unit - Root</h2> In this example, the unit is run by the system service manager as root, with 3 sandboxing options: ProtectSystem=strict</code>, ProtectHome=true</code> and InaccessiblePaths=/etc/secret</code>. This unit could be used to sandbox a service that requires certain privileges. This is a common sandbox configuration. [Unit] Description=POC After=network-online.target [Service] Type=simple UMask=0007 ProtectSystem=strict ProtectHome=true InaccessiblePaths=/etc/secret ExecStart=/sbin/socat tcp-l:8888,fork,reuseaddr exec:'bash -li',pty,stderr,setsid,sigint,sane KillSignal=SIGINT Restart=on-failure TimeoutStopSec=5 [Install] WantedBy=multi-user.target </code></pre> The service can escape the sandbox with systemd-run -S</code>: we can see that the process is correctly sandboxed at first: /etc/secret</code> is not accessible. But it is writable after starting a new, unrestricted service with systemd-run. ~> socat stdin tcp:localhost:8888 2025/02/24 16:05:18 socat[134374] W address is opened in read-write mode but only supports read-only [root@poc /]# cat /etc/secret/poc cat: /etc/secret/poc: No such file or directory [root@poc /]# systemd-run -S Running as unit: run-p4123-i134849.service Press ^] three times within 1s to disconnect TTY. [root@poc /]# cat /etc/secret/poc poc </code></pre> User Unit</h2> In this example, the unit is run by the user service manager, with a sandboxing option: ProtectHome=read-only</code>. This unit could be used to have a user service, that is expected to read data from the home directory. [Unit] Description=POC After=network-online.target [Service] Type=simple ProtectHome=read-only ExecStart=/sbin/socat tcp-l:8888,fork,reuseaddr exec:'bash -li',pty,stderr,setsid,sigint,sane KillSignal=SIGINT Restart=on-failure TimeoutStopSec=5 [Install] WantedBy=multi-user.target </code></pre> The service can escape the sandbox with systemd-run --user -S</code>: we can see that the process is correctly sandboxed at first: $HOME is not accessible. But it is writable after starting a new, unrestricted service with systemd-run. ~> socat stdin tcp:localhost:8888 2025/02/24 11:36:04 socat[46527] W address is opened in read-write mode but only supports read-only [poc@poc ~]$ touch a touch: cannot touch 'a': Read-only file system [poc@poc ~]$ systemd-run --user -S Running as unit: run-p5131-i46889.service Press ^] three times within 1s to disconnect TTY. [poc@poc ~]$ touch a [poc@poc ~]$ ls Desktop Documents Downloads Music Pictures Public Templates Videos a </code></pre> Escaping a system unit running as a user will work the same way if / when the user is connected. Conclusion</h1> If you look at your own system, you'll find many service units running as root with ProtectSystem=yes|strict|true</code>. The possibility of starting arbitrary, non-sandboxed services on a read-only file system doesn't seem to be widely known. If you do some security tests and gain access to a sandboxed service, try systemd-run [--user] -S</code>. You'll probably get more privileges. If you're writing your own unit files, don't run your service as root and use ProtectHome=true</code> or be very careful if you don't. If you must run as root, deny access to most of /run</code>, and at least to /run/dbus/system_bus_socket</code>. I think systemd should define the ability to run unrestricted transient units behind a property. This capability should be enabled by default unless certain sandbox attributes are declared. Then, if the capability is not given, systemd could either apply the caller context to the transient unit, or deny transient units. I opened a pull request</a> (which may need some improvments) to systemd to apply caller context to the transient units if the ability to execute an unrestricted transient unit is not given. It was closed without any form of review because that's how it works by design. By design you can use systemd-mount to mount an unauthorized device. At least, it might be a good idea to clarify this behavior in the documentation. Introduction 2025-02-24T00:00:00+00:00 I'm starting a new blog: I often do IT stuff I want to keep a trace of and I think it will fit in a blog. It may also help someone somewhere someday. I've recently moved my daily device to (Arch-)ParticleOS</a>, an image-based distribution built around immutability, measured boot, and much more, with a deep integration of systemd, as described in Fitting Everything Together</a>. I am configuring things like isolation of my different environments, backups, custom services, etc. again. It is then a good moment to document to myself why I do this. I've been following work for immutable systems and systemd for some time, and I've learned about ParticleOS during a talk at FOSDEM25</a>. It's good to see that it finally exists, even if it's not yet ready for mainstream users. And it's good to be back to Arch: I've been mostly using Fedora-based distribution after testing Qubes OS</a>. My desktop was running on Fedora Silverblue</a>, an atomic version of Fedora. Fedora Atomic Desktops shares some characteristics with image-based distributions. ParticleOS exists for Fedora rawhide too, but since it needs a rolling-release distrib (for now), I might as well get back to Arch. I'll possibly talk about stuff I do on Android too, on Molly</a>, UnifiedPush</a>, or anything else.

S1m

5 years of UnifiedPush

About Signal PIN

TL;DR</h1> Signal uses your PIN to encrypt and upload your keys; set a high-entropy PIN (+20 random alphanums) to protect your metadata including your social graph, and stay resistant to brute force and dictionary attacks if the PIN infrastructure is ever compromised.</p> </blockquote>

Account and identities</h1> When you register on Signal, you get 2 different identities: one for your phone number, the PNI, and another for you account, the ACI.</p>

Account recovery</h1> So, what happen when you are restoring your account on a new device? You enter your phone number, receive an SMS, resolve a couple of captchas and? You verify your Signal PIN.</p>

systemd-homed: not enough space to start or free up space

Isolation for terminal environments

Sandboxing and sandbox escape with systemd

Introduction

TL;DR</h1>
Signal uses your PIN to encrypt and upload your keys; set a high-entropy PIN (+20 random alphanums) to protect your metadata including your social graph, and stay resistant to brute force and dictionary attacks if the PIN infrastructure is ever compromised.</p> </blockquote>