Security in depth · Unit 22 · Lesson 8 of 44
Delegation is more than a command name
Review the task, target identity, and trusted inputs behind a delegation rule.
Helpful before thisLinux privilege escalation
After this lesson you can
- Find a mismatch between approved delegation and control of a task’s configuration.
One idea. One situation. One reasoned decision.
How it works
A sudo policy describes who may perform a permitted task, as which target identity, with applicable argument and environment rules. Authentication and authorization are separate: confirming the requester does not make every allowed operation appropriately scoped.
The task’s trusted configuration and dependencies also matter. An invocation can be narrow while the application’s behavior remains controlled through another input.
Read the supplied record
S1 is a fictional delegation summary, not executable policy syntax.
| Review item | Supplied fact |
|---|---|
| Nina’s approved purpose | Support generates one approved monthly summary |
| Target identity | report-reader |
| Invocation | Fixed arguments and reviewed environment |
| Program updates | Release maintainers only |
| Data-selection configuration | Content editors may change it |
| Editors’ approved role | Formatting only |
Assume the application actually uses that configuration to choose report fields, and the supplied editing permission is effective. No record proves past misuse.
The mismatch is configuration authority: editors can change a decision outside their approved formatting role. Propose separating formatting inputs from controlled data-selection settings, with Nina approving purpose and maintainers owning implementation. Review the target identity’s required data access as a separate boundary.
Acceptance should show that the approved summary still works and that an ordinary formatting editor cannot change the controlled selection policy. A successful invocation log alone does not prove the resulting report contains only approved fields.
Keep the conclusion scoped. This packet supports a delegation-design finding, not a claim that a person accessed unrelated records. Document application assumptions needing confirmation.
The key distinction: A constrained invocation still depends on the inputs it trusts.
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
Which review conclusion best follows from S1?
Show the answer
Correct answer: Configuration ownership needs correction or an approved boundary before accepting the delegation. Editors’ documented control of data-selection settings exceeds their approved formatting role. A narrow invocation alone does not resolve that mismatch.
Try it
- WriteWrite a four-row delegation review for S1: approved purpose, permitted target identity, unresolved configuration control, and one allowed/denied outcome to verify before acceptance.