Architecture, limits and implementation status

Security model

Tilo is designed to keep an ordinary mistake, a hostile application, a compromised package source or an overreaching collaborator from becoming authority over the whole computer. This page states where each boundary is enforced and where it ends.

What the model is for

Threat	Primary boundary
A stolen, powered-off computer	Encrypted disk; TPM-bound unlock where available; recovery kept separately
A malicious or compromised application	Empty starting view, capability hand-off, network isolation, namespaces, seccomp and Landlock
A correctly signed malicious update or dependency	Runtime authority remains bounded; signatures and reproducibility do not widen it
A collaborator writing outside their grant	Signed changes are checked against replicated permission state before merge
A peer forwarding somebody else’s change	Admission checks the connection; authorship checks each change independently
A modified boot or system partition	Signed unified kernel image and an integrity-checked, read-only system image
A lost device	Per-device certificate revocation without replacing the person’s identity
Remote control that outlives its purpose	A separate, visible, session-scoped input grant with a local emergency stop

This is not a claim that one mechanism makes the machine “secure.” It is a set of boundaries intended to remain useful when another boundary fails.

The person is the root, not the TPM

The root identity is a recoverable, person-scoped account key. It authorises devices; a device does not define the account. Every machine receives its own certificate, hardware-bound when its hardware supports that, and that certificate can be revoked without replacing the identity or re-enrolling every other device.

person-scoped account key
  └── device certificate
        ├── disk unlock
        ├── local login
        ├── peer identity
        ├── document authorship
        └── access subject

A TPM holds a non-exportable device key and can release it only after an expected boot. This makes normal unlock quieter and makes boot-state evidence possible. It does not become the owner of the account or the only recovery path. A machine without a TPM uses a longer passphrase; it keeps the same identity, revocation and workspace permission model.

Adding, losing and recovering a device

An authorised device signs a certificate for the new device after an explicit pairing step.
The new device uses that certificate for peer identity and signed workspace changes. It never receives the account’s recovery secret merely by joining.
Revoking a device is a signed change to the account’s authorisation state. Peers that have received the change reject later sessions and changes from that certificate.
Losing every authorised device requires the recovery copy created during account setup.

One day-to-day unlock

On supported hardware, one PIN releases the device key used for disk unlock, login and the local credential store. The recovery password is not a routine login secret. A machine without hardware-backed guess throttling uses a longer boot passphrase instead of pretending that a short PIN is equally safe there.

Disk unlock is tied to a signed prediction of the expected boot measurements rather than one frozen measurement. A firmware or operating-system update can ship the next signed policy with the update, so normal maintenance does not turn the recovery secret into a frequent fallback.

The booted system is one verified object

Owner-enrolled keys: A self-built image can be signed by its owner. A collaborator may trust that key and still verify what booted; verification is not reserved for vendor images.
Signed UKI: The kernel, initramfs and kernel command line are one signed unified kernel image. The component that unlocks the disk and the hardening options are therefore inside the signature.
Verified system image: The root filesystem is read-only and integrity-checked on every read. The installed system is identified by the hash of its contents.
Bounded rollback: The unlock policy admits the current deployment and a bounded set of earlier deployments. An older image may boot, but does not automatically receive the data key.

Rollback prevention before the kernel receives control is not complete. At present, an image outside the accepted window can begin booting and then fail to unlock the data. That is weaker than a bootloader-enforced anti-rollback counter and is tracked as such.

Administration has three different levels

Level	What it permits	What persists
Brokered operation	A named operation such as restarting one service or loading one signed module	Only the result of that operation
Work layer	A root shell and traditional package tools inside an inspectable filesystem overlay	The overlay only if explicitly kept; a broken layer cannot replace the next boot
Unlock system	Replace the kernel or write to the sealed system base	System modifications, plus a durable record that the machine was unlocked

A brokered capability never accepts an arbitrary command to run as root. The moment a “narrow” operation accepts any executable path, it has collapsed back into unrestricted root. Writing to the sealed system cannot be leased safely because it can place code that runs outside the sandbox at the next boot.

Unlocking does not wipe personal data. It also does not protect that data from somebody who already has the physical access and credentials needed to unlock the machine. The durable unlock state makes modification detectable to the owner and, once peer attestation exists, to collaborators; it is evidence, not retroactive protection from data copying.

An application starts with an empty view

Tilo has to confine normal Linux binaries, a format that was not designed around mandatory mediation. Each application therefore receives a constructed view rather than the ambient filesystem and network of the login account.

Files: The system picker returns an already-open handle to the selected file. The application does not receive the surrounding directory or a path it can race and reopen later.
Filesystem: Directories outside the grant do not appear in the application’s filtered view. A hidden file and a file that never existed produce the same observable result.
Network: No network means an empty network namespace, including local addresses. A configured account or pasted origin can imply access to that origin without granting arbitrary egress.
Devices and ongoing access: Camera, microphone, location, screen capture, background work and broad access require an explicit, time-bounded grant and remain visible while active.

The package manifest lists the maximum capabilities an application may ask for; it grants none of them. Opening a file, dropping a record or pasting already expresses intent and hands over that specific capability without another prompt. Everything broader is granted once, while open, until logout or until revoked.

Denial is returned as not available, the same condition an application must already handle when a device, file or network does not exist. A permission system where refusal makes the application unusable is not meaningful.

Enforcement layers

bubblewrap namespaces construct the process, mount and network view;
seccomp-bpf reduces the available syscall surface;
Landlock applies kernel-enforced filesystem and network restrictions to the process and its descendants;
portals and system brokers hand over typed capabilities;
SELinux protects the trusted base—the compositor, sync service and filesystem service—rather than carrying per-application policy.

These layers share the host kernel. They limit application authority; they are not a claim that a kernel exploit is harmless.

Packages answer three separate questions

Question	Mechanism	What it does not prove
Provenance: who published these bytes?	Signed, content-addressed package root and publisher identity	That the publisher or dependency was benign
Integrity: do these bytes match the declared source?	Reproducible build attestations	That reproducible malware is safe
Authority: what may the process do?	Sandbox plus runtime capabilities	That every kernel or broker implementation is bug-free

Installing a package runs no installation hook and grants no capability. An update inherits the authority of the version it replaces; requesting a new capability still requires a person or applicable policy at the moment it is needed. Bytes may arrive from a peer, mirror or USB drive because every artifact is verified locally against the signed root; transport is not authority.

Collaboration checks the connection and the change

A workspace host holds a complete replica and is the root of that workspace’s permission state. Other peers may hold partial replicas. Native applications exchange signed state, not rendering code; a normal Linux application stays on its host and streams surfaces to participants.

The host is therefore a storage trust boundary. On a self-hosted or company-hosted workspace, whoever administers that machine controls the complete stored replica unless another encryption layer removes that access. Confidential-computing isolation and client attestation are planned for commercial hosting, but are not implemented and are not a current claim that the hosting operator cannot read tenant data.

Admission: May the authenticated peer connect to and synchronise this workspace? The answer comes from the identity on the encrypted connection, not a name inside a message.
Authorship: Was this individual change signed by an identity allowed to perform it? This is checked per change even when a relay delivered it.
Read access: Enforced by not sending data outside the grant. Revocation stops future delivery; it cannot recall a copy already received.
Write access: Peers validate signed operations against permission state before merging them. A failing batch is rejected as a whole rather than repaired after merge.

A person, agent and application are all named permission subjects. An agent uses the same exported actions and scoped grants as the visible interface; there is no parallel automation API with ambient authority. Its changes remain signed and attributed to the agent rather than to the person who configured it.

Remote input is a separate grant

Watching a shared surface does not imply permission to type. Remote input is granted per session, displayed continuously, independently revocable and subordinate to the local keyboard and pointer. One local emergency action disconnects remote input, drops its transient grants and locks the session.

Peer attestation can detect change, not trust

The designed protocol asks a peer to prove which image it booted, which owner-enrolled key signed it and whether the machine records itself as unlocked. The receiving machine compares that evidence with the first connection. This can detect a reimage, signing-key change, rollback or a machine changing from locked to unlocked.

It cannot prove that the machine is safe now. Boot measurements do not notice a compromise after boot, say nothing about an individual application, and the first connection is trust-on-first-use. A machine without a TPM retains the same identity and workspace access model, but cannot satisfy a policy that specifically requires boot-state evidence.

This peer-attestation protocol is designed and not implemented end to end.

What the model cannot do

It cannot make an authorised reader forget data, prevent a photograph, or recall an exported copy.
It cannot make sync or history serve as an independent backup.
It cannot make a desktop-session install verify the distribution’s boot chain or administrator accounts.
It cannot turn a valid signature, reproducible build or TPM quote into proof that code is benign.
It cannot contain a kernel exploit with userspace namespaces alone.
It cannot claim global revocation before disconnected replicas have received the new permission state.

Implementation status

Status	Current scope
Built and exercised	Signed and content-addressed qpkg roots, publisher identities, scoped attestors, revocation checks at install and launch, three-layer application confinement, per-workspace writable directories, reproducible image builds, signature verification on update, filtered filesystem views, isolated networking, sealed-root reads, measured version data and bounded rollback tests.
Written, not proven end to end	Owner-enrolled Secure Boot tooling and encrypted installation. The relevant code and tests exist, but the complete physical-machine path has not earned an “enforced” claim yet.
Designed, not built	Peer boot-state attestation, source-log witnessing, independent rebuilder counts, resource budgets and per-origin network implication.
Open	Revocation timing for offline replicas, eviction of revoked workspace content from local search indexes, bootloader-level anti-rollback, hosted-operator isolation, and the exact hosted-to-peer-to-peer failure behaviour when complete replicas disappear.

A verification script that cannot distinguish “the property is absent” from “I could not inspect it” is a failed check. Status moves upward only when the check has demonstrated that it can fail for the right reason.

Related reference

Permission subjects, scopes and lifetimesOperational trust, recovery and remote inputImage signature and release verificationExport, backup and deletion boundaries