All lessons Leer en español

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.

4 minreadyShort lesson

Helpful before thisLinux privilege escalation

See all lessons in this topic

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.

Approved task → Trusted dependencies → Scoped authorityApproved taskTrusted dependenciesScoped authority
Review the approved purpose together with the task's identity, inputs, and maintenance permissions.

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.

  1. 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.
References