jperezduerto.info
Security in depth · Unit 22 · Lesson 12 of 44
Loaded libraries share process authority
Review a native plugin separately from the trusted program that loads it.
Helpful before thisLinux privilege escalation
After this lesson you can
- Explain why verifying a main executable does not verify every in-process dependency.
One idea. One situation. One reasoned decision.
How it works
Dynamically loaded native libraries contribute code inside a host process. Without a separate isolation mechanism, they share its execution context and can use its authority. A separate file does not make a library a restricted process.
The dynamic loader has rules for locating dependencies. Application plugins may add another selection mechanism, so a review must identify both what is loaded and how it is maintained.
Read the supplied record
L1 describes a fictional archive viewer running as archive-reader.
| Component or property | Supplied evidence |
|---|---|
| Main program | Approved release package verified |
| Native display plugin | Separate local package; provenance not recorded |
| Loading model | Plugin loaded into the viewer process |
| Current authority | Read approved archive records |
| Plugin update owner | Not assigned |
Assume the verification covers only the main package, the plugin was actually loaded, and no separate sandbox constrains it. Main-program verification therefore does not establish plugin integrity or approval.
The immediate finding is incomplete dependency assurance and ownership. It is not proof of malicious behavior. Ask the release owner to identify the plugin version and approved source, verify the delivered artifact against trusted release evidence, and assign a controlled update path.
Checking a filename or observing that the viewer still opens is insufficient. Functional compatibility, integrity, and suitability for the approved task are different questions.
Retain evidence for the selected plugin and its relevant dependencies. If processing moves to a restricted service, review that boundary; “plugin” alone does not mean isolation.
The key distinction: A trusted host does not automatically make separately supplied code trustworthy.
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 conclusion is justified by L1’s successful main-program verification?
Show the answer
Correct answer: The verified main release is identified; the separate plugin still needs provenance and update review. The supplied verification covers only the main package. The native plugin is separate code loaded into the same process.
Try it
- WriteWrite a release-review note for L1 with the verified component, unverified component, shared authority assumption, and two pieces of evidence needed before approving the plugin update.