Add threat model#133
Conversation
| The Language Runtime enforces I/O permissions set by the Evaluator Client before evaluation begins. | ||
| No Pkl code can modify these settings at runtime. |
There was a problem hiding this comment.
Might be worth noting that evaluators setting may be set via settings.pkl and/or PklProject so these files must be trusted or restricted as well. Probably worth calling out --no-project/--omit-project-settings and the override behavior of evaluator settings.
| ==== Package Integrity | ||
|
|
||
| When importing a package, the runtime verifies the package's contents against a SHA-256 checksum declared in the project's dependency list (`PklProject.deps.json`). | ||
| This verification is independent of which server served the package, providing integrity guarantees even if the package server is compromised or the connection is intercepted. |
There was a problem hiding this comment.
This could also cover the local cache, in addition to remote servers.
There was a problem hiding this comment.
The local cache is trusted and their contents aren't verified; attacks that require that an attacker have write permissions to the filesystem is considered out-of-scope.
|
|
||
| === Package Resolution | ||
|
|
||
| ==== Tampered Package |
There was a problem hiding this comment.
Not sure if this belongs here or in supply chain, but we should call out that we do not offer protection against typo-squatting. Maybe in the future we can build a system to do that.
There was a problem hiding this comment.
WRT building a system that prevents typosquatting: that's currently not a goal; we don't intend on maintaining a package registry anytime soon.
| * Pkl cannot perform I/O outside what is explicitly allowed. | ||
| * Pkl code cannot modify or exceed the permissions established by the Evaluator Client. | ||
| * Pkl cannot execute arbitrary system commands or load native code. | ||
| * Pkl will run to completion, or time out. |
There was a problem hiding this comment.
Do we consider whatever the Pkl equivalent of adversarial regular expressions or ReDoS out of scope? Maybe a good example.
There was a problem hiding this comment.
Mmm I think that ReDoS is out of scope; guards against DoS attacks would happen via resource limit flags (CPU and memory) if/once we have them.
Open to opinions here though.
| If the import URI does not include a SHA-256 checksum segment, the runtime performs no integrity verification and Pkl code within the tampered package is evaluated. | ||
|
|
||
| NOTE: Package imports that include a checksum in the URI are verified against the declared hash. | ||
| Direct imports without a checksum (e.g., `package://example.com/pkg@1.0.0#/mod.pkl`) are not verified. |
There was a problem hiding this comment.
This probably deserves its own item on the list, feels like a big deal.
There was a problem hiding this comment.
Can you clarify? This is already its own item?
| @@ -0,0 +1,392 @@ | |||
| = Threat Model | |||
There was a problem hiding this comment.
Add a version and date so that users can identify how recently reviewed this was.
There was a problem hiding this comment.
Added a "last edited" date. Is the version useful? Can the edited date serve as the version?
Co-authored-by: Jen Basch <jbasch94@gmail.com>
Co-authored-by: Jen Basch <jbasch94@gmail.com>
|
|
||
| * Pkl cannot perform I/O outside what is explicitly allowed. | ||
| * Pkl code cannot modify or exceed the permissions established by the Evaluator Client. | ||
| * Pkl cannot execute arbitrary system commands or load native code. |
There was a problem hiding this comment.
Teechnically, due to external readers, Pkl can execute arbitrary code. But this is explained in other parts of this doc, so it's probably fine to not point this out here.
| Package imports that include a checksum in the URI are verified against the declared hash. | ||
| Direct imports without a checksum (e.g., `package://example.com/pkg@1.0.0#/mod.pkl`) are not verified. |
There was a problem hiding this comment.
This can also happen with regular project imports, not only direct package imports.
If the cache does not contain package X and an attacker tampered with it, Pkl will download the malicious package and cache it locally.
There was a problem hiding this comment.
The PklProject.deps.json file guards against this; it includes the checksum of all dependencies and verifies them when downloading.
There was a problem hiding this comment.
It protects you from a package version you already know about being tampered. It doesn't protect you from a package version being tampered before you store the checksum.
There was a problem hiding this comment.
Yeah that's the "trust on first use" policy; definitely worth mentioning.
| Users whose package imports do not include checksums would fetch and execute malicious packages without any verification failure. | ||
|
|
||
| *Attacker:* Remote Attacker; Network Attacker + | ||
| *Violates:* _pkg.pkl-lang.org only redirects to official Pkl-hosted content_; _Imported package dependencies are authentic_ |
There was a problem hiding this comment.
_pkg.pkl-lang.org only redirects to official Pkl-hosted content_ is not in the Security Goals.
There was a problem hiding this comment.
Ah yeah, I had that initially but got rid of it.
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
4 participants
No description provided.