Plan how credentials and device identity reach every profile after onboarding

[Yury-MonZon]

Problem

Each bootable profile is its own btrfs root subvolume with its own /etc, so anything the user
sets up during onboarding lands in exactly one profile. Every other profile stays at factory
defaults, and every profile is offered in the boot menu. The weakest profile therefore decides
the security of the device: hardening @Desktop means nothing if @Minimal still accepts
user/user, and /home is shared, so a login to the weak profile reaches the same data.

We should decide, before onboarding ships, which parts of "who this device belongs to" are
per-profile and which follow the device, and how the ones that follow the device get there.

What is shared and what is not

Path	Backing	Consequence
/home	shared @home subvolume	user data and ~/.ssh are already device-wide
/var/log, /var/cache, /boot	shared subvolumes	not identity, listed for completeness
/etc	per-profile	shadow, passwd, group, ssh, sudoers.d, NetworkManager connections all diverge
/root	per-profile	root's authorized_keys diverges
/var/lib	per-profile	service state, for example tailscale, diverges

Observed drift on a device where one profile had been set up:

• testuser, added in @Desktop, is present in @Desktop and in the profile migrated from it,
  and absent in @Minimal, @Router, @TV-Media-Box, @No-Graphics.
• The user account still carries the build's factory hash in all five factory profiles.
• NetworkManager connections are per-profile, so a network joined in one profile does not exist
  in the others.
• SSH host keys currently happen to match across profiles, but only because the build bakes one
  key set into the image (see "Related" below), not because anything propagates them.

What counts as identity, and where it lives today

Item	Location	Today
User password hashes, added accounts, group membership	/etc/{shadow,passwd,group,gshadow}	per-profile
User SSH authorized keys	/home/<user>/.ssh	already shared
Root SSH authorized keys	/root/.ssh	per-profile
SSH host keys (the device's identity to clients)	/etc/ssh/ssh_host_*	per-profile, baked at build
Network credentials	/etc/NetworkManager/system-connections	per-profile
sudo policy	/etc/sudoers.d	per-profile
Hostname, machine-id	/etc/machine-id, generated banner	deliberately per-profile
Timezone, locale, keyboard	/etc/localtime, /etc/default/keyboard	per-profile
User-added apt sources and keyrings	/etc/apt, /usr/share/keyrings	per-profile

Decisions we need

1. Which of the above should follow the device, and which should legitimately stay
   per-profile? machine-id is intentionally per-profile so a profile first-boots and takes
   its own hostname. Host keys are the opposite: they identify the device, not the profile.
2. Should onboarding push to the other profiles at the moment it completes, or should each
   profile pull on its first boot from a shared store?
3. What happens to profiles that appear after onboarding, whether from create-profile, from
   receive-snapshot of a fresh build, or from a future image update?
4. Is leaving factory user/user valid on a non-onboarded profile acceptable at all, or should a
   profile that has never been onboarded refuse logins until it is?

Options

A. Push at onboarding completion. Onboarding mounts the top level and writes the chosen
credentials into every profile's /etc. Direct and offline, and it can reuse the per-entry
account merge already written for migrate-profile rather than overwriting databases wholesale.
Downside: it edits other roots behind their back, and it does nothing for profiles created later,
so it needs pairing with option C.

B. Share the files. Move the device-wide items to a shared subvolume and have each profile
reference them, by symlink or bind mount. Nothing to propagate, since there is one copy. Good fit
for /etc/ssh/ssh_host_* and root's authorized_keys. A poor fit for /etc/shadow, because
profiles legitimately differ in service accounts, which is exactly why migrate-profile merges
those databases per entry instead of copying them.

C. Pull on first boot. Onboarding writes a device identity record to a shared location, and a
first-boot unit in each profile applies whatever is present. Covers profiles created later for
free, including ones received from a build, and composes with create-profile already resetting
machine-id so a new profile first-boots. Downside: an identity store on disk needs care, since
it holds hashes and keys.

D. Do nothing and document it. Tell users that each profile has its own credentials. Cheapest,
and defensible for a developer board, but it leaves a default-credential root in the boot menu of
an otherwise hardened device.

Suggested direction

C for the general mechanism, plus B for the SSH host keys specifically, since those have no reason
to differ per profile and sharing them removes a class of host-key warnings entirely. A as the
immediate action at the end of onboarding, so the profiles that already exist are fixed at once
rather than at their next boot.

Interaction with the existing tooling

• create-profile snapshots its source, so a profile cloned from an onboarded profile inherits
  its credentials already. The gap is profiles built from a _stock, which carry factory
  defaults.
• migrate-profile merges account databases per entry, carries usr/local and keyrings, and
  since f99f26a carries /etc/ssh/ssh_host_* explicitly, because the baked-in keys never appear
  in its delta. Whatever we choose here should reuse those semantics rather than invent new ones.
• receive-snapshot lands a _stock from a build, which by definition has never been onboarded.

Related

The build bakes one SSH host key set into every image, so all devices flashed from a given build
share a host identity, and reflashing changes it. That is worth a separate issue, and option B
above would make it moot for profile-to-profile drift but not for device-to-device sharing.

@alchark @zhovner

[alchark]

WiFi country setting is also related (needs to be pulled from common storage and applied in each profile at boot)

[NicolasWalker]

The way I’m understanding it is “ the device boots into several different profiles, each with its own set of accounts, but they all share the same home directory. Set up a password in one profile and the other four still accept the factory user/user — and logging into a weak one reaches the same files. The weakest entry in the boot menu decides the security of the whole device.”

It might be 2 problems: Some are facts that need to be shared (tmz, WiFi, locale, keyboard), and some are actual secrets. We could just gate during setup and leave a marker, and lock login on any profile that doesn’t have one. A profile nobody has set up boots with its accounts disabled instead of accepting the factory password. This removes the default password from the boot menu, and it’s automatically correct for profiles that get created later, since a brand-new profile has never been set up. Needs a supported way back in for developers who want a scratch profile.

When someone finishes setup, push their credentials into the profiles that already exist. Steps 1 and 2 protect future profiles; this repairs the ones already on the device.

Later, optionally, encrypt the home directory. This is the only thing that helps if someone pulls the drive. But it only works if the key comes from a password typed at login — anything stored on disk to allow unattended boot can just be read from a weak profile, which defeats the point. So headless operation and real encryption are in tension, and it should be opt-in rather than forced on everyone.

For this last point, could do the 1Password vault approach and stay safe across devices? From my understanding 1Password’s design is in 3 parts. Pt1: account password is combined with a 128-bit Secret Key that never leaves the device, so neither alone is sufficient.

That derived key doesn’t unlock data directly — it unwraps a pt2: private key, which unwraps per-vault keys, which clicks pt 3: decrypt items. And sharing a vault doesn’t copy secrets to another device; it wraps that vault’s key to the new device’s public key. Thus you get access granted, not propagated and a change or revocation is a re-wrapping without them.

Substitute profile for device and it maps onto this issue:

•	/home gets encrypted with a data key.
•	That data key is wrapped once per enrolled profile.
•	A profile that has never been onboarded has no wrapped copy. It boots fine, user/user still works, and it reads nothing.

Would that not work? It might be a bit over engineered here, but just a thoughtful users who really want encryption annd that only helps if the key comes from something typed at login. Which means @router booting headless to a working /home and real security are mutually exclusive, absent a secure element..

[TheScottBot]

Ayooo,

I wanted to weigh in with a potential curve ball.

It seems like the current model is trying to solve two different things, and as such there's a bit of a blur in the boundaries: configuration isolation and security/trust isolation.

I'd propose adding another tier before profiles: environments.

Device
│
├── Environment A
│   ├── Profile 1
│   └── Profile 2
│
├── Environment B
│   ├── Profile 3
│   └── Profile 4
│
└── Recovery

Recovery would be the default environment, giving you a known-good place from which you can create your first environment, recover broken ones, etc.

The important distinction would then be:

Environment = trust/data boundary
Profile = configuration/use-case boundary within that environment

That gives us a cleaner place for things to live:

DEVICE
    Device encryption key
    Recovery identity?
    Hardware identity

ENVIRONMENT
    Users
    Passwords
    SSH authorised keys
    /home
    Secrets
    Trusted networks?

PROFILE
    Services
    Package selection
    Firewall configuration
    UI configuration
    Specialist tools

Conceptually, configuration flows down through increasingly specific scopes:

Device defaults
       ↓
Environment policy
       ↓
Profile configuration

So device-level configuration might contain things like:

Screen brightness
Locale
Hardware identity

An environment could contain:

Users
/home
Credentials
Network trust
Encryption material

And profiles could contain:

Services
Packages
Firewall rules
Specialised configuration

The reason I think this might be useful for the problem in this issue is that it changes the question from:

How do we propagate credentials between profiles?

to:

Should these profiles actually belong to the same trust domain?

For example, I might have a Daily Driver environment containing Desktop and Development profiles. I'm happy for those to share my /home, user identity and credentials.

But I might separately have a Pentest environment containing several profiles for different kinds of testing. Those profiles can share state with each other without automatically gaining access to everything in my Daily Driver environment.

That gives a fairly simple rule for users to reason about:

Profiles within an environment trust one another's data. Environments do not.

It also gives us two useful containment boundaries. If I completely bork a profile, ideally the rest of its environment survives. If I completely bork an environment, Recovery and my other environments still exist.

I'm throwing this out primarily to challenge the assumption that credential propagation is necessarily the right layer to solve this at. There are obviously implementation/storage/UX implications to adding another abstraction, and I haven't dug deeply enough into the current profile implementation yet to know what those costs look like.

But I think separating "how do I want this system configured?" from "what am I willing to let this system access?" could make the security model substantially easier to reason about.

[rafaetri]

Prototype for the SSH host-key part, which flipperos-btrfs-tools#1 (owner password) leaves open:
flipperdevices/flipperos-btrfs-tools#2 and #184.

Since #160 each profile generates its own host keys, so switching profiles should show clients a
"host key changed" warning. The PRs keep one key set on the shared boot subvolume and copy it
into each profile at boot.

One question: #1 suggests a new shared subvolume for this kind of state; I used /boot because
every profile already mounts it. Happy to switch so both end up in one place.

Tested with unit tests and a full local image build. Not tested on hardware (I don't have a board).