From 652694f15d79851bcb02640f18c204efcbd04d17 Mon Sep 17 00:00:00 2001 From: Tristan F Date: Mon, 24 Apr 2023 07:03:53 -0400 Subject: [PATCH] docs(security): clarify storage explosion attacks in policy (#18697) Deno does not cover storage explosion attacks from evaluated runtime code. I've chosen the following parts for this clarification: - _Evaluated_ code - storage explosion attacks caused by services in Deno such as the HTTP server should still be covered. - Isolated - If the storage explosion attack can happen at arbitrary different files, it may leave a much more lasting impact on a targeted host system than on simply the Deno cache. --- .github/SECURITY.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/SECURITY.md b/.github/SECURITY.md index c5680b2b01..ea7a0af3d3 100644 --- a/.github/SECURITY.md +++ b/.github/SECURITY.md @@ -48,6 +48,10 @@ may change slightly over time, but in general the model is as follows: that a value set in one web worker can not be accessed by another. - All runtime I/O is considered to be privileged and must always be guarded by a runtime permission. This includes filesystem access, network access, etc. + - The only exception to this is runtime storage explosion attacks that are + isolated to a part of the file system, caused by evaluated code (for + example, caching big dependencies or no limits on runtime caches such as the + [Web Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache) API). - Users should not be able to self-escalate their permissions without explicit consent. - I/O required to build an initial static module graph should always follow the