From 4659badb95a84b0c1c13a401ea9021f99ad87534 Mon Sep 17 00:00:00 2001 From: Forgind <12969783+Forgind@users.noreply.github.com> Date: Tue, 31 Dec 2024 16:13:22 -0800 Subject: [PATCH 1/6] Start on trust boundary doc --- documentation/general/trust-code.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 documentation/general/trust-code.md diff --git a/documentation/general/trust-code.md b/documentation/general/trust-code.md new file mode 100644 index 000000000000..f303acfcb116 --- /dev/null +++ b/documentation/general/trust-code.md @@ -0,0 +1,15 @@ +# Overview +The .NET SDK is intended to be a collection of tools for manipulating, building, and executing code. As a result, there is no way to ensure that it is 100% secure regardless of how it is used. Nevertheless, the SDK team tries to protect users from any unexpected security gaps. It strikes a balance between enabling the functionality that empowers our users to achieve more while protecting users from bad actors trying to take compromise their machines. + +This document attempts to make clear the line between what security threats are up to the user and what threats the SDK should protect against. It defines the trust boundary where the user can assume that as long as they are secure in the ways outlined in this document, they will not be compromised by an outside threat actor. + +# Types of Threats + +## Untrusted Source Code +You should never build or run code from an untrusted source without employing mitigating factors like those described [here](linkToHowToRunCodeDoc). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory or any parent directory up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. + +## Untrusted Locations +Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. It is generally recommended to avoid running dotnet commands from within any directory that contains any files you do not trust. + +## Untrusted Packages +NuGet follows [a preset order](link?) in looking for packages. Of note, it does not always search the sources listed in the NuGet.config, as that is often slower than the alternative. On the other hand, a malicious NuGet package can be found if one exists in your cache. Ensure that all NuGet packages you request are from trusted and verified sources. From 99d679121263752cdf27d4022b36b4a6c4b73884 Mon Sep 17 00:00:00 2001 From: Forgind <12969783+Forgind@users.noreply.github.com> Date: Fri, 14 Feb 2025 15:01:10 -0800 Subject: [PATCH 2/6] Apply suggestions from self review --- documentation/general/trust-code.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/general/trust-code.md b/documentation/general/trust-code.md index f303acfcb116..b3d39708247f 100644 --- a/documentation/general/trust-code.md +++ b/documentation/general/trust-code.md @@ -6,10 +6,10 @@ This document attempts to make clear the line between what security threats are # Types of Threats ## Untrusted Source Code -You should never build or run code from an untrusted source without employing mitigating factors like those described [here](linkToHowToRunCodeDoc). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory or any parent directory up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. +You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory or any parent directory up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. ## Untrusted Locations Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. It is generally recommended to avoid running dotnet commands from within any directory that contains any files you do not trust. ## Untrusted Packages -NuGet follows [a preset order](link?) in looking for packages. Of note, it does not always search the sources listed in the NuGet.config, as that is often slower than the alternative. On the other hand, a malicious NuGet package can be found if one exists in your cache. Ensure that all NuGet packages you request are from trusted and verified sources. +NuGet follows a preset order in looking for packages in [various caches](https://learn.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders). It first searches the (expanded) global-packages folder, followed by the (compressed and short-lived) http-cache before finally using the NuGet.config file to determine where to find any unfound packages. Of note, it does not always search the sources listed in the NuGet.config, as that is often slower than the alternatives. On the other hand, a malicious NuGet package can be found if one is cached or even if a downloaded package in a temp folder is modified before it can be expanded. Ensure that all NuGet packages you use are from trusted and verified sources. From 74e2dcb58235e8323ea03ab1900093b717df9226 Mon Sep 17 00:00:00 2001 From: Forgind <12969783+Forgind@users.noreply.github.com> Date: Thu, 20 Feb 2025 11:03:12 -0800 Subject: [PATCH 3/6] Add more places we auto-search --- documentation/general/trust-code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/general/trust-code.md b/documentation/general/trust-code.md index b3d39708247f..c5aa72cf17a3 100644 --- a/documentation/general/trust-code.md +++ b/documentation/general/trust-code.md @@ -6,7 +6,7 @@ This document attempts to make clear the line between what security threats are # Types of Threats ## Untrusted Source Code -You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory or any parent directory up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. +You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, or executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. ## Untrusted Locations Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. It is generally recommended to avoid running dotnet commands from within any directory that contains any files you do not trust. From ca150d1d33b08088d4196238d543ebb80f2b463e Mon Sep 17 00:00:00 2001 From: Forgind <12969783+Forgind@users.noreply.github.com> Date: Thu, 13 Mar 2025 15:54:10 -0700 Subject: [PATCH 4/6] PR feedback --- documentation/general/trust-code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/general/trust-code.md b/documentation/general/trust-code.md index c5aa72cf17a3..89c70c47161c 100644 --- a/documentation/general/trust-code.md +++ b/documentation/general/trust-code.md @@ -9,7 +9,7 @@ This document attempts to make clear the line between what security threats are You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, or executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. ## Untrusted Locations -Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. It is generally recommended to avoid running dotnet commands from within any directory that contains any files you do not trust. +Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. Do not run dotnet commands from within any directory that contains any files you do not trust. ## Untrusted Packages NuGet follows a preset order in looking for packages in [various caches](https://learn.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders). It first searches the (expanded) global-packages folder, followed by the (compressed and short-lived) http-cache before finally using the NuGet.config file to determine where to find any unfound packages. Of note, it does not always search the sources listed in the NuGet.config, as that is often slower than the alternatives. On the other hand, a malicious NuGet package can be found if one is cached or even if a downloaded package in a temp folder is modified before it can be expanded. Ensure that all NuGet packages you use are from trusted and verified sources. From 73c98f244a1a758a42a1fc643c25448535aae415 Mon Sep 17 00:00:00 2001 From: Forgind <12969783+Forgind@users.noreply.github.com> Date: Fri, 14 Mar 2025 15:11:38 -0700 Subject: [PATCH 5/6] Cite NuGet rather than expressing trust boundary --- documentation/general/trust-code.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/documentation/general/trust-code.md b/documentation/general/trust-code.md index 89c70c47161c..d86eddf749f8 100644 --- a/documentation/general/trust-code.md +++ b/documentation/general/trust-code.md @@ -1,15 +1,19 @@ # Overview -The .NET SDK is intended to be a collection of tools for manipulating, building, and executing code. As a result, there is no way to ensure that it is 100% secure regardless of how it is used. Nevertheless, the SDK team tries to protect users from any unexpected security gaps. It strikes a balance between enabling the functionality that empowers our users to achieve more while protecting users from bad actors trying to take compromise their machines. - -This document attempts to make clear the line between what security threats are up to the user and what threats the SDK should protect against. It defines the trust boundary where the user can assume that as long as they are secure in the ways outlined in this document, they will not be compromised by an outside threat actor. +The .NET SDK is intended to be a collection of tools for manipulating, building, and executing code. As a result, there is no way to ensure that it is 100% secure regardless of how it is used. This document attempts to make clear the line between what security threats are up to the user and what threats the SDK should protect against. It defines the trust boundary where the user can assume that as long as they are secure in the ways outlined in this document, they will not be compromised by an outside threat actor. # Types of Threats ## Untrusted Source Code -You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, or executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. +You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. ## Untrusted Locations Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. Do not run dotnet commands from within any directory that contains any files you do not trust. ## Untrusted Packages -NuGet follows a preset order in looking for packages in [various caches](https://learn.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders). It first searches the (expanded) global-packages folder, followed by the (compressed and short-lived) http-cache before finally using the NuGet.config file to determine where to find any unfound packages. Of note, it does not always search the sources listed in the NuGet.config, as that is often slower than the alternatives. On the other hand, a malicious NuGet package can be found if one is cached or even if a downloaded package in a temp folder is modified before it can be expanded. Ensure that all NuGet packages you use are from trusted and verified sources. +Since many SDK commands utilize NuGet under the covers, we further assume that: +* NuGet packages in local caches are trustworthy. +* NuGet.Config, Packages.Config, .props, and similar files within our resolution scope (see previous comments on trusted and untrusted directories) point only to trusted package repositories and/or packages. + +See: [Managing the global packages and cache folders](https://learn.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders), [Managing package trust boundaries](https://learn.microsoft.com/nuget/consume-packages/installing-signed-packages), and [Consuming packages from authenticated feeds](https://learn.microsoft.com/nuget/consume-packages/consuming-packages-authenticated-feeds) for more information. + +Violating these assumptions may lead to unwanted code execution. From c4ade61d7b311125e4aedd6cf524eca1e217ec1d Mon Sep 17 00:00:00 2001 From: Forgind <12969783+Forgind@users.noreply.github.com> Date: Sat, 22 Mar 2025 14:01:44 -0700 Subject: [PATCH 6/6] PR feedback --- documentation/general/trust-code.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/general/trust-code.md b/documentation/general/trust-code.md index d86eddf749f8..aaa33bc8a524 100644 --- a/documentation/general/trust-code.md +++ b/documentation/general/trust-code.md @@ -4,10 +4,10 @@ The .NET SDK is intended to be a collection of tools for manipulating, building, # Types of Threats ## Untrusted Source Code -You should never build or run code from an untrusted source without employing mitigating factors like those described [here](https://github.com/dotnet/sdk/blob/main/documentation/general/ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. +You should never build or run code from an untrusted source without employing mitigating factors like those described [here](ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files. ## Untrusted Locations -Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. Do not run dotnet commands from within any directory that contains any files you do not trust. +Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. Do not run dotnet CLI commands from within any directory that contains any files you do not trust. ## Untrusted Packages Since many SDK commands utilize NuGet under the covers, we further assume that: