Which CWE abstraction level do you file a world-readable Linux credentials file at, and why?
answer
- three true labels, one useful one
- Pillar organises, Class describes, Base constrains
- does the row imply a checkable sentence
- permission assignment on a critical resource
- create with the mode, do not tighten after
basics
~20 sFile it at Base: CWE-732, incorrect permission assignment for a critical resource. The Pillar and Class above it are true but imply no change; only the Base entry names the resource and the consequence, so only it constrains the fix.
solid answer
~50 sA configuration agent that creates `/etc/svc/db.conf` mode 0644 with a database password in it maps honestly at three levels, and only one of them is useful. `CWE-664` (improper control of a resource through its lifetime) is the Pillar — organisational, not a mapping target. `CWE-284` (improper access control) is the Class — true of half the estate and it implies no change. `CWE-732`, incorrect permission assignment for a critical resource, is the **Base**: it names the resource (a file holding something that matters) and the consequence (the wrong principals can read it), so the fix statement follows directly — the agent must create the file with a restrictive mode rather than create it and tighten it afterwards, because the create-then-tighten order leaves the secret readable for a window. Choose Base as the mapping target unless you have specific evidence for a Variant beneath it.
code
text · 13 linesPillar CWE-664 Improper Control of a Resource Through its Lifetime
Class CWE-284 Improper Access Control
Base CWE-732 Incorrect Permission Assignment for Critical Resource
finding: /etc/svc/db.conf mode 0644 owner root:root
written by the configuration agent, contains a DB password
...
filed at Pillar -> not a valid mapping target at all
filed at Class -> "control access properly" : no testable change
filed at Base -> "the file must not be readable
by principals that do not need it, from the
moment it exists" : testable changego deeper
Know that a weakness entry sits at a level and that the broad ones are not what you file against. Be able to say that incorrect permission assignment on a file is a more specific statement than improper access control.
Walk the chain out loud — Pillar, Class, Base — and say what each level adds. Explain why the Base entry is the first one from which a verifiable fix statement follows.
Show the second-order judgment: why Base mapping surfaces the create-then-tighten window and the shared upstream template, and why over-specific mapping from behavioural evidence alone is a claim you cannot defend in review.
Decide what your organisation's mapping target level is and who arbitrates disputes about it, knowing that the choice determines whether the remediation register can be counted or is a pile of categories.
## The finding A configuration agent runs across a Linux server fleet and renders service configuration from templates. One template produces `/etc/svc/db.conf`, containing a database password, owned by `root` with mode 0644. Every local account on every host in the fleet can read it. Nobody attacked anything; a reviewer reading the agent's templates found it. The reviewer files it as `CWE-284`, improper access control. That is not wrong. It is also not useful, and explaining why is the whole exercise. ## Walking the chain **Pillar — `CWE-664`, improper control of a resource through its lifetime.** True: a resource (the file) was created in a state it should never have been in. It is also true of memory-management bugs, of leaked handles, of session lifetime errors. Pillars exist to organise the tree, and the taxonomy's mapping guidance treats them as invalid mapping targets for exactly this reason. **Class — `CWE-284`, improper access control.** True, and one abstraction narrower: this is about who may reach a resource. It still names no resource, no mechanism and no consequence. Filed at this level the row says "access control is wrong somewhere", which is where the reviewer's judgment stops and the reader's guessing begins. **Base — `CWE-732`, incorrect permission assignment for a critical resource.** Now the entry text carries the resource (something whose confidentiality matters), the mechanism (a permission assignment) and the consequence (principals who should not read it can). From that a fix statement follows without further interpretation. ## Why Base is the level that constrains the fix At Base the finding becomes falsifiable. "The agent must create this file with a mode that excludes principals that do not need it" is a statement a change can satisfy and a reviewer can re-check. It also exposes a second-order detail the abstract levels hide: the *ordering* matters. An agent that writes the file with default permissions and then tightens it has still exposed the secret for the interval between the two operations — a window that repeats on every configuration run, on every host. That detail is visible only once the mapping is specific enough to be about permission assignment on a file at creation time. A Class-level row would never have surfaced it. A second reason Base is the right target: recurrence. The point of a weakness class is to show that the same specific mistake keeps happening. If this finding, a world-writable log directory, and an over-broad group on a shared directory are all filed as `CWE-284`, the register shows one big undifferentiated pile. Filed at Base they show a pattern in how the configuration agent's templates handle file modes — which is the actual defect, and it is one change to one template library rather than n changes to n files. ## When to go below Base A Variant narrows a Base to a language, platform or technology where that specificity changes the shape or the fix. Descending to a Variant is only honest when the evidence supports it. Here, the reviewer read the templates and can see how the file is created, so a platform-specific narrowing would be defensible if one existed that added something. Contrast that with a report derived from behaviour alone — someone observed that an unprivileged account could read a secret and inferred the rest. That reporter can support "the permissions are wrong"; they cannot support a claim about *how* the code assigns them, and a Variant-level mapping from that evidence is over-claiming. **Map at the most specific level the evidence actually supports, which is usually Base.** ## Saying it to the reviewer The useful phrasing avoids sounding like taxonomy pedantry: "`CWE-284` is true and I would keep it as the parent, but I want the row at `CWE-732`, because that is the level where the sentence 'the agent creates the file with a mode that excludes other local accounts' either is or is not satisfied. At `CWE-284` there is no sentence to check." ## What this does not decide The mapping level says nothing about severity, about whether anybody read the file, or about whether this fleet even has untrusted local accounts. Those are separate arguments. The abstraction level decides one thing only: whether the row implies a verifiable change.
- A reporter who only observed the behaviour maps the finding at Variant level. What is your objection?Over-claiming. A Variant asserts a language, platform or technology specific shape of the mistake, which requires seeing how the code assigns the permission. Someone who only observed that an unprivileged account could read the file can support a Base mapping and no more. The honest rule is the most specific level the evidence supports.
- Why does filing three unrelated permission findings under one Class label cost you something?It hides the pattern. Filed at Base, three findings about file modes written by the same configuration agent point at one template library and one change. Collapsed into a single access-control Class label alongside unrelated authorisation bugs, the register shows a pile of items with no shared owner and no shared fix, so nobody sees the single upstream cause.
- Does the Base mapping tell you how severe this is?No. The abstraction level is about whether the row implies a verifiable change, not about impact. Severity depends on what the credential reaches, whether the fleet has untrusted local accounts, and how long the file has existed at that mode. Those are separate arguments and the taxonomy deliberately does not make them for you.
saying these in an interview costs you the question
- Files at Class level and calls the mapping finished
- Picks the deepest entry available regardless of evidence
- Thinks the abstraction level implies severity
- Misses that create-then-tighten leaves an exposure window
- Argues Pillar entries are acceptable mapping targets