From 1fd427b9c46a4b6daa2ea7cbb0830dac47f8cd68 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tobias=20Nie=C3=9Fen?= Date: Mon, 1 May 2023 20:38:26 +0200 Subject: [PATCH] doc: document dangerous symlink behavior Much earlier, a design decision was made that the permission model should not prevent following symbolic links to presumably inaccessible locations. Recently, after some back and forth, it had been decided that it is indeed a vulnerability that symbolic links, which currently point to an accessible location, can potentially be re-targeted to point to a presumably inaccessible location. Nevertheless, months later, no solution has been found and the issue is deemed unfixable in the context of the current permission model implementation, so it was decided to disclose the vulnerability and to shift responsibiliy onto users who are now responsible for ensuring that no potentially dangerous symlinks exist in any directories that they grant access to. I believe that this design issue might be surprising and that it comes with significant security implications for users, so it should be documented. Original vulnerability report: https://hackerone.com/reports/1961655 --- doc/api/permissions.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/api/permissions.md b/doc/api/permissions.md index 33e24f49dd5a7e..e17bbb38e55cbc 100644 --- a/doc/api/permissions.md +++ b/doc/api/permissions.md @@ -568,6 +568,11 @@ There are constraints you need to know before using this system: * Relative paths are not supported through the CLI (`--allow-fs-*`). * The model does not inherit to a child node process. * The model does not inherit to a worker thread. +* Symbolic links will be followed even to locations outside of the set of paths + that access has been granted to. Relative symbolic links may allow access to + arbitrary files and directories. When starting applications with the + permission model enabled, you must ensure that no paths to which access has + been granted contain relative symbolic links. * When creating symlinks the target (first argument) should have read and write access. * Permission changes are not retroactively applied to existing resources.