Diagnosing SELinux Staging Labels after Work Profile Restore

Let's start with the restore regression. Omar and Lina are here from Package Management, Sanjay represents Product Security, and Eva owns System Quality. Build B46 passes clean-install testing, but app updates fail in a work profile restored from the previous maintenance version. The installer reports access denied while preparing a staging directory. Existing applications still open, and we have no evidence of damaged app data. We need to establish the cause, choose a repair that preserves isolation, and define how existing affected profiles recover. Please keep installation failure, profile restore, and user-data integrity as separate observations until the evidence connects them.

I have four failure logs and two passing controls. The installer reaches the package verification stage, then fails when creating its temporary child directory. File ownership and ordinary mode bits match the passing profile. The difference is the SELinux type on the staging parent: restored profiles carry the restore-service type, while newly created profiles carry the installer-staging type. An audit denial names the installer domain and that parent. This suggests a labeling problem, but I want to verify when the wrong type appears. A later cleanup operation could change the label after creation, so the final state alone does not identify the responsible code.

That distinction matters. A denial is evidence that policy blocked an operation; it is not automatically evidence that policy should allow it. If a restore-owned directory has been placed where the installer expects its own staging area, adding an allow rule could make the symptom disappear while weakening the intended boundary. I would first compare the creation path, expected label from the policy definition, actual label, and caller identity. We also need to confirm that this is installer scratch space rather than application-private data. A repair that relabels the wrong tree could create a larger problem than the original failed update.

Quality reproduced it on every one of six restored work profiles, but none of six newly provisioned profiles. The same application package updates successfully in the personal profile on those devices. I used synthetic app content and recorded checksums before and after each attempt; no content changed during the failed updates. That gives us a useful baseline, not a guarantee about every customer's profile. I can capture labels immediately after restore, after first unlock, and after the update attempt. We should also include an interrupted restore, because the directory may exist before the profile is fully initialized.

The restore service introduced eager staging creation in B46 to shorten the first post-restore update. It creates the parent before handing control back to Package Management. The normal installer path applies the expected labeling operation after creation, but the new restore path assumes the label will be inherited correctly. I will trace that assumption rather than replace it with another one. We need to know whether the restore path calls the same helper, whether the parent already exists, and whether the operation runs before credential-encrypted storage is available. Those conditions determine both prevention and repair.

Omar, walk us through the first failing profile from restore to installation. Lina, compare it with normal provisioning. Sanjay, challenge any claim that the observed type is correct merely because a process created it. Eva, identify what would disprove the labeling hypothesis. I do not want us to jump from a recognizable denial to a patch without checking the surrounding state. The issue tracker also mentions low storage, but that may be a separate failure with the same application message. Let's use the native error and audit event to keep those cases distinguishable.

The profile is restored while locked. After the first unlock, the restore service creates the staging parent with its own default type and records initialization as complete. Later, the installer sees the directory and skips its creation helper because the path already exists. The audit denial occurs on the first attempt to create a child. There is no cleanup relabel between those events. On normal provisioning, the installer creates and labels the parent itself. The difference is not a changed policy rule; it is an alternate creation path that bypasses the established directory contract. The logs also show ample free space in this reproduction.

To test causation, I can use a diagnostic image that routes restore staging creation through the installer helper, with enforcement still enabled. If the expected label appears and updates succeed, that supports the hypothesis. I will also preserve a deliberately mislabeled parent as a negative control; the installer should still reject it. A broad permission change would make that control pass and tell us we have weakened the test. For the low-storage cases, I will create a separate run with the correct label and verify that it reports a storage error rather than the access-denied signature.

That is the right comparison. The policy definition already identifies this location as installer staging, so the creator's default type is not authoritative. We should repair creation to satisfy the existing contract and avoid granting the installer access to restore-service storage generally. However, sharing the helper needs an ownership review. The restore service should request creation through the established interface rather than acquire broad installer privileges. I want the interface to accept a validated user identifier and a fixed staging role, not an arbitrary path supplied by the caller. That keeps the operation narrow and auditable.

I can remove eager creation from the restore service and make it request staging readiness from Package Management after unlock. The installer will verify the expected type even when the directory exists, instead of equating existence with readiness. That prevents future profiles from entering the bad state, but it does not automatically fix the six profiles Eva already created. We need a separate recovery path for those. I would prefer repairing only the known staging subtree after validating ownership and profile identity. A device-wide relabel would be expensive and would make it harder to prove which changes were necessary.

There is pressure to add a narrow allow rule for the installer and remove it in the next release. It would be quick, and affected profiles could update immediately. I understand the labeling argument, but the migration path is more code and has interruption risks. If the staging area is only scratch space, could a temporary rule be a defensible containment while we build the proper repair? I want us to compare actual risks instead of rejecting the option because it sounds inelegant. We also need an answer for a profile that cannot finish initialization today.

The proposed rule is narrow in process name but broad in object meaning. The restore-service type also covers other restore work, so allowing installer operations on that type would cross a boundary beyond this one directory. We would then have to prove those additional objects cannot be reached, which is not a quick validation. I recommend retaining the denial and repairing the mislabeled staging area through a constrained operation. For a profile that is not ready, report a retriable initialization error and preserve the pending update. Do not turn a recoverable install failure into silent access to objects the installer was never intended to manage.

For recovery, I propose a per-user operation under the same lock used for staging creation. It verifies the profile, checks that the directory is the expected staging location, rejects symbolic links and unexpected ownership, then applies the policy-derived label to the allowed subtree. It records completion only after reading back the expected state. If interrupted, the next attempt repeats validation and converges on the same result. We should not mark success merely because the labeling call returned without an exception. The postcondition is that the authorized staging tree has the expected label and unrelated trees are unchanged.

I can test interruption before validation, during the subtree walk, and before the completion record is written. Every rerun must be safe and produce the same final labels. I will place sentinel directories outside the allowed scope and compare their labels, ownership, and contents before and after recovery. We should also test profile deletion while recovery is queued and a locked profile whose encrypted storage is unavailable. In those cases the operation must stop without acting on another user's directory. The test needs to verify the absence of unintended changes, not only that an app update eventually succeeds.

We will take the constrained repair route and keep enforcement unchanged. Omar's question is useful because it exposes the real trade-off: a short policy patch can carry a large object-scope risk, while a longer repair can be bounded by explicit checks. We still need a latency budget. Users should not wait through a full storage scan before installing one update. Lina, please measure the staging subtree size and give us a bounded operation with progress reporting. If the tree is unexpectedly large or ownership is inconsistent, fail safely and attach diagnostics rather than expand the repair scope automatically.

Today is October nineteenth. Lina owns the prevention patch by two this afternoon Seoul time and the recovery prototype by tomorrow noon. Omar owns the staging contract document and install-error mapping by four today. Sanjay will review the interface and object scope tomorrow at two. Eva will complete the prevention matrix by tomorrow evening and recovery interruption tests by Wednesday noon. We will not merge a policy allow rule as a substitute. The candidate must preserve existing applications and pending updates, and recovery must touch only the verified staging area. Any unrelated label change blocks approval immediately.

The contract will state that staging readiness requires correct location, ownership, label, and storage availability. An existing directory is only one input to that decision. I will distinguish initialization-in-progress, invalid staging state, low storage, and package verification failure in the internal error mapping. The application-facing message can remain simple, but support diagnostics must preserve the native cause. I will also check that a failed preparation does not discard the queued update or repeatedly redownload the same package. A correct security boundary should not force users into an endless retry loop with no explanation of what is waiting.

My review will include path resolution, user identity, lock coverage, and the source of the expected label. The code must derive that label from the authoritative policy configuration rather than embed a string that can drift across products. I will examine failure paths as closely as success paths, especially when the profile disappears between validation and execution. We need evidence that the operation cannot follow a substituted link or act on a recycled user identifier. I will also verify that the installer remains denied access to restore-service objects outside the staging contract. The negative control must continue to fail.

The matrix will cover clean profiles, restored profiles, interrupted restores, multiple work profiles across test devices, and repeated recovery. We will perform an app update and a fresh install after each successful repair, then compare synthetic user-data checksums. I will include one profile with no affected directory to verify a clean no-op, and one with unexpected ownership that must be rejected. For normal-sized staging trees, the proposed recovery budget is two seconds on the reference device. If that budget is exceeded, we report the duration and tree size; we do not skip validation to make the timing pass.

The prototype will expose a small recovery result with validated user, reason, affected-object count, duration, and final verification status. It will not log application contents. I will implement the completion marker as a record of verified state, not as permission to skip checks forever. On a later attempt, the installer will still confirm staging readiness because a component could recreate the directory incorrectly. I will keep prevention and recovery changes separate for review, but both are required for the affected-profile candidate. Shipping prevention alone would leave the existing profiles broken, which would make our success claim incomplete.

The decision review is Wednesday, October twenty-first, at three in the afternoon Seoul time. We will inspect the creation trace, policy review, prevention results, and recovery interruption evidence. Approval requires successful updates on the restored profiles, unchanged unrelated labels and user data, and continued rejection of invalid objects. If recovery remains unsafe, we can accept the prevention fix into a development branch while holding the affected-profile release candidate. We will not describe the incident as resolved until existing profiles have a verified repair path. I will send that distinction to release coordination today so the schedule reflects the actual scope.

I will bring a before-and-after timeline showing creation, label verification, preparation, and install completion. The report will preserve the original audit denial so reviewers can see why policy blocked the old state. I will not remove denial logging just to make the candidate look quiet. A remaining denial with a different target may reveal another incorrect creation path, and we should investigate it separately. For support, I will document how to identify the affected staging signature without asking users to erase their work profile. Resetting the profile would discard evidence and impose a cost that this targeted repair is meant to avoid.

I will add the broader lesson to our interface review checklist: directory creation includes its security state, not only its pathname and mode bits. An optimization that moves creation to another service must preserve that state contract explicitly. This is not a reason to stop all initialization optimizations, but it is a reason to review their object ownership and labeling consequences. I will use the synthetic directory trace in the checklist so reviewers can compare expected and actual states. The review should help teams find the mistake before it appears as a confusing permission failure in somebody else's component.

For closure I will retain three reproducible controls: the original mislabeled restore, a clean profile, and an interrupted repair resumed to completion. Each will include the artifact identifiers, profile state, expected labels, and checksum results. I will also provide a summary of rejected unexpected ownership and link cases. Those are passes for the protection mechanism, not failed recovery coverage to be hidden. Reviewers should see both successful correction and successful refusal. If the candidate changes before release, we rerun the relevant controls rather than assume that an earlier security review covers different code.

I have the implementation scope and deadlines. I will first route creation through the existing staging interface and reproduce the original update with enforcement enabled. Then I will add recovery for verified existing directories and exercise interruption before asking for review. If I find a directory that does not match the expected contract, I will stop that repair and return diagnostics instead of broadening the helper. I will post the first prevention trace by two today and flag any dependency that threatens tomorrow's recovery prototype. That gives us a concrete checkpoint before Wednesday's approval discussion.