Security

Nothing in Sarab runs as root. That answers one question, “can Android take over my machine’s root?”: no, short of a bug in the Linux kernel. It does not answer “can one bad app take over my desktop?”, and this page is about the gap between the two.

The short version: Android runs as your user, fenced in by Linux namespaces rather than by permissions. Apps are kept apart from each other by Android’s usual user model, but kept apart from Android’s own system by little more than that. Sarab is not a sandbox for apps you do not trust. Install apps into it the way you would install a program on your desktop: only from sources you trust.

Who runs as whom

Inside Android	On your machine	What runs there
root	you, your own user	Android’s init, and the display and audio services
system users	your sub-ids	Android’s system services
apps	your sub-ids	every app, Google Play services included

The first row is the one that matters: anything that becomes Android’s root runs as you.

What Android can reach

Android runs with an environment of its own, so nothing from your session, such as the SSH agent or tokens you exported, reaches it. From inside its namespaces it can see:

• the Android image and Android’s data;
• your system’s /usr, read-only;
• your display and your audio server, and nothing else of your session. Your D-Bus session bus, your SSH, GnuPG and keyring agents, and your password manager are out of sight;
• your GPU and sound devices;
• the network, as an ordinary outbound client.

The display and audio connections are real reach into your session. Many compositors, Hyprland and the other wlroots ones included, let every program on the display capture the screen, manage the clipboard and type, and an audio client can record from your microphone. So treat an Android compromise as something that can watch your screen, read your clipboard, type and listen, not as contained.

The image is signed with public test keys

The LineageOS image Sarab uses is signed with the Android Open Source Project’s test keys, whose private halves are published. Android decides which apps may join its own system, and which may replace a built-in app, by their signing keys. So anyone can sign an app that makes itself part of Android’s system, and from there reach whatever Android’s root reaches. This has been confirmed on this image.

Sarab cannot fix that from outside Android; the fix is an image signed with keys that are not public. Until then, an app from an untrusted source can take over Android, and with it what is described above.

What Sarab does about it

• adb is off. It is never started, it would require an authorised key, and no key is authorised. sarab exec is the way in.
• Your terminal stays yours. sarab exec gives commands a terminal of Android’s own and relays it, so nothing inside Android can read what you type afterwards or type into your shell.
• Apps are not debuggable unless they ask to be, as on a phone.
• No new user namespaces inside. Nothing in Android, its root included, can create one, which keeps a large part of the kernel out of apps’ reach, as on a phone.
• Apps see only their own processes, and nothing in Android sees yours.
• Only Android’s system can use the host services. An app that calls Sarab’s clipboard, notification, launcher or power service directly is refused, and the refusal is logged. Note that apps signed with the public test keys count as Android’s system.
• What apps send the desktop is checked. Launcher entries are built only from valid package names and cleaned-up labels, icons must be real PNG images of a sane size, and notification text is escaped.
• The network is outbound only. Nothing can connect into Android from outside, and Android cannot reach services listening only on your machine’s loopback, such as a database or a development server.

What is not enforced

• Android’s network permission, only partly. An app without it cannot look up names, but can still connect to an IP address. Per-app network restrictions, Data Saver, background data limits and VPN lockdown have no effect.
• Your local network. Android sees it as your user does.
• Data at rest. Android’s data is ordinary files in your home directory, readable by anything running as you. An app’s “hardware-backed” keys are files on your disk.
• Verified boot. The Android image is a set of files you can write to.

What Sarab downloads

The first start downloads the LineageOS images Sarab is tested with, over HTTPS, and checks each against a SHA-256 checksum kept in Sarab’s source code, so a changed file on the server is refused. You still trust the people who built those images, since they carry no signature. sarab setup --latest takes the newest build instead, checked only against the checksum the same server publishes.

The image with Google apps includes Google Play services with system privileges. Sarab turns off Play Protect’s check of apps you install from your desktop, because its dialog would have no window to appear in, and it offers to upload the app to Google. Apps from the Play Store are still checked.

The kernel and the GPU

Every app talks to your machine’s kernel directly, through binder, the GPU driver and ordinary system calls. A kernel bug that an app can reach is a compromise of the whole machine. That is true of any container, and it is the real boundary here.

The GPU is shared with your desktop. Anything in Android that makes the GPU hang takes your screen down with it while the kernel recovers.

On Ubuntu 23.10 and later, Sarab asks you to install an AppArmor profile that lets its namespace helper create user namespaces. With Sarab installed in your home directory, anything running as you could replace that helper and gain the same permission. Installed somewhere only root can write, the exemption stays with Sarab.

Android’s services use the GPU as users of their own, so Sarab needs the GPU’s render node open to every local user. That is already the default on Arch Linux, Fedora and upstream systemd. On Debian and Ubuntu, Sarab asks for a rule that does the same.

Reporting a vulnerability

Please report it privately through GitHub: Report a vulnerability on the repository’s Security tab, rather than in a public issue. Include the version you tested and how to reproduce it. Sarab is a one-person project, so expect an answer within a few days.

The full technical model, with the details behind each point on this page, is SECURITY.md in the repository.