skip to content

How does a file-and-device reachability profile differ from a syscall allowlist when both can refuse the same workload?

level: middleimportance: should knowfreq 38%

answer

  1. one gates the verb, one the object
  2. which call against which thing
  3. both kernel-enforced, both deny by default
  4. widen them separately, always
  5. accelerated work usually needs both changed

basics

~20 s

They answer different questions. The allowlist decides which kernel calls may be attempted at all; the reachability profile decides which files and devices a call is allowed to touch. Widening one leaves the other exactly as it was.

solid answer

~50 s

A syscall allowlist gates the **verb**: may this kernel call be made by this workload, yes or no, checked on every call and sometimes on one argument's value. A reachability profile gates the **object**: which paths, directories and device nodes this workload may reach, and with which access. Both are enforced by the kernel and both are deny-by-default in their shipped form, which is why a refusal from either can look identical to the process. The practical consequence is that they must be widened separately: permitting a call does not make a device reachable, and naming a device does not permit a call that was never on the list. A workload doing hardware-accelerated work usually needs both changes, and an engineer who makes only one concludes the profile 'did not work' and reaches for the switch that turns everything off.

code

yaml · 13 lines
yaml
confinement:
  callFilter:              # the verb: which kernel calls may be attempted
    mode: allowlist
    base: platformDefault
    alsoPermit:
      - inspectOtherProcess
  reachability:            # the object: what those calls may touch
    devices:
      - name: mediaAccelerator
        access: readWrite
    paths:
      - name: /workload/cache
        access: readWrite

go deeper

for a junior

Hold on to the one-line split: one wall says which kernel calls a workload may make, the other says which files and devices those calls may touch.

for a middle

Explain that both are kernel-enforced and deny-by-default, and predict the consequence of widening only one — the workload still fails and the other wall is blamed.

for a senior

Show that you diagnose by the object of the failing operation, and that you widen the narrow thing on the correct wall rather than switching either of them off.

for a principal

Note that both arrive as declarations on the workload rather than in its image, so they are reviewable artefacts — and argue for making them explicit on workloads that carry real blast radius.

## Two walls, two different questions A confined workload is refused by the kernel for two structurally different reasons, and keeping them apart is most of the value of this subject. - A **syscall allowlist** decides *which kernel calls may be attempted*. It is a list of entry points; a call not on it is refused before it does anything. This is the **verb**. - A **reachability profile** — a mandatory access-control profile — decides *which files, directories and device nodes the workload may reach, and with what access*. It does not care which call is being used to reach them. This is the **object**. Both are enforced in the kernel, both are checked on the workload's own processes, and in their shipped form both are deny-by-default. That is why a refusal from either can arrive at the process as the same unhelpful error. ## Side by side | | syscall allowlist | reachability profile | |---|---|---| | what it names | the kernel calls that are permitted | the paths, directories and devices that are reachable | | the question it answers | may this operation be attempted at all | may this operation touch that object | | granularity | per call, sometimes on one argument's value | per path or device, per access mode | | typical shipped default | permits what ordinary programs use, denies an administrative tail | hides most of the host's device nodes, restricts what is writable | | how a refusal looks | an error from an operation with no file in it | an error opening something that exists and looks readable | | how you widen it | permit the named call | name the path or device, with the access needed | ## Why widening one does not widen the other This is the part interviews are actually probing, because it is where teams get stuck: - Permitting a call adds an entry point; it says nothing about what that call may address. A permitted call that reaches for a device the profile does not name is still refused. - Naming a device makes an object reachable; it does not add a call. If the library needs a call that the list never had, naming the device changes nothing. - A workload doing accelerated media work commonly needs **both** — the call and the device — and an engineer who changes one and sees no improvement concludes that confinement is unfixable and reaches for the switch that removes it wholesale. - The reverse also holds and is easy to forget: narrowing one wall does not narrow the other, so a tightly written reachability profile does not compensate for a permissive call list. ## Where these two sit relative to the other hardening In front of both sits a different wall entirely — the account the workload runs under and how much of its filesystem is writable — which is a separate decision made in the workload's spec rather than in either of these profiles. Behind both sits the fact that these walls all guard one shared kernel; they shrink what a compromised workload can reach, and they do not make it a separate machine. Naming those neighbours correctly is part of a good answer, and so is not conflating them: file *ownership* on a file is not the reachability profile, and a broad privilege set is not the call list. ## Declaring them In practice both arrive as declarations attached to the workload rather than as anything baked into its image, which is why the same image behaves differently on two differently configured platforms. A spec that carries both makes the pair visible to a reviewer, which is the main argument for declaring even the defaults explicitly on workloads that matter. ## What interviewers check That you separate verb from object without prompting; that you know both are kernel-enforced and deny-by-default; that you can predict the failure mode of changing only one of them; and that you do not describe either as 'file permissions', which is a third mechanism owned by neither.

  • A permitted call still fails when it opens a device — which wall refused it?
    The reachability profile. The call itself was allowed to be attempted, so the allowlist is satisfied; what was refused is the object it addressed. Name that device, with the access it needs, in the workload's profile — and leave the call list alone, because it was never the obstacle.
  • Why does the same image behave differently on two platforms?
    Because neither wall ships inside the image. The call list and the reachability profile come from the platform's configuration and the workload's spec, so two differently configured platforms confine the same bytes differently. It is also why a workload that works locally with no confinement at all tells you nothing about how it will behave in a cluster.

saying these in an interview costs you the question

  • Calls the reachability profile 'file permissions' on the workload's files.
  • Thinks permitting a kernel call also makes a device reachable.
  • Believes one of the two is enforced by the platform rather than the kernel.
  • Assumes both walls are widened by a single setting.
  • Says a strict reachability profile makes a permissive call list safe.