diff --git a/projects/kyverno/security-assessment/images/kyverno-architecture.png b/projects/kyverno/security-assessment/images/kyverno-architecture.png index 2970a5382..ef9e62324 100644 Binary files a/projects/kyverno/security-assessment/images/kyverno-architecture.png and b/projects/kyverno/security-assessment/images/kyverno-architecture.png differ diff --git a/projects/kyverno/security-assessment/images/kyverno-physical-architecture.png b/projects/kyverno/security-assessment/images/kyverno-physical-architecture.png index f54d936e6..9057aba3e 100644 Binary files a/projects/kyverno/security-assessment/images/kyverno-physical-architecture.png and b/projects/kyverno/security-assessment/images/kyverno-physical-architecture.png differ diff --git a/projects/kyverno/security-assessment/self-assessment.md b/projects/kyverno/security-assessment/self-assessment.md index 779926e53..4e53d7f9c 100644 --- a/projects/kyverno/security-assessment/self-assessment.md +++ b/projects/kyverno/security-assessment/self-assessment.md @@ -4,7 +4,7 @@ |**Completed**: | *tbd* | |-----------------------------|---------------------------------------| |**Security reviewer(s)**: | John Kinsella, Wesley Steehouwer (@dutchshark) | -|**Project security lead**: | Jim Bugwadia | +|**Project security lead**: | Jim Bugwadia, Shuting Zhao | | **Source code**: | https://github.com/kyverno/kyverno | | **Web site**: | https://kyverno.io/ | @@ -44,7 +44,7 @@ ## Overview -Kyverno helps secure and automates Kubernetes configurations using policies defined as Kubernetes custom resources. It operates as an Kubernetes admission controller and a command-line for off-cluster use. +Kyverno helps secure and automates configurations using policies defined as Kubernetes custom resources. It operates as a Kubernetes admission controller and provides command-line tools for off-cluster use. Additionally, Kyverno has been extended with new policy types (`ValidatingPolicy`, `ImageValidatingPolicy`, `MutatingPolicy`) that utilize CommonExpressionLanguage (CEL) to support non-Kubernetes resources, enabling policy validation for any JSON or YAML payload including Terraform files, Dockerfiles, cloud configurations, and service authorization requests. ### Background @@ -55,28 +55,28 @@ While this is powerful, it also creates a few challenges: 2. Kubernetes configurations are not secure by default. Security and best practices need to be configured for workloads. 3. A resource's configurations is shared across organizational roles (dev-sec-ops) and chances of misconfigurations, or lack of proper configuration, increase as there is no clear ownership. Whether developers, operators, or security engineers are responsible for more `advanced` configuration settings may not be obvious. -### Goal +### Goals -The goal of the Kyverno project is to simplify Kubernetes configuration security and automate processes that otherwise require manual handoffs and coordination across Kubernetes cluster operators and developers. +The goal is to enforce security policies across Kubernetes resources to prevent insecure configurations and ensure compliance. User-defined YAML and CEL policies are enforced through admission control to prevent non-compliant Kubernetes resources from being created or modified, providing immediate feedback to users. If the admission controller is unavailable, CLI tools and background scanning provide alternative enforcement mechanisms to maintain security posture. Kyverno also provides automation through mutation and generation capabilities to automatically fix configurations and create required resources, simplifying security management. CLI tools extend this enforcement to non-Kubernetes resources like Terraform files and Dockerfiles. ### Non-goals -Kyverno is not a general purpose policy engine i.e. it is not designed for use outside of Kubernetes. +Kyverno is NOT designed to address Kubernetes security flaws, as it cannot protect against vulnerabilities in the Kubernetes API server or underlying infrastructure and Kyverno's policy enforcement may be bypassed if Kubernetes has a security flaw. Kyverno does not enforce security requirements that weren't explicitly defined, it enforces only the policies that users define. Kyverno does not replace Kubernetes RBAC, as RBAC controls access while Kyverno enforces policy compliance. Kyverno also does not replace Kubernetes' built-in policy controls like ValidatingAdmissionPolicies and MutatingAdmissionPolicies, but complements these native controls with additional features such as comprehensive reporting, exception management, and periodic scanning. ## Self-assessment use -This self-assessment is created by the Kyverno team to perform an internal analysis of the -project's security. It is not intended to provide a security audit of Kyverno, or +This self-assessment is created by the Kyverno team to perform an internal analysis of the +project's security. It is not intended to provide a security audit of Kyverno, or function as an independent assessment or attestation of Kyverno's security health. -This document serves to provide Kyverno users with an initial understanding of -Kyverno's security, where to find existing security documentation, Kyverno plans for -security, and general overview of Kyverno security practices, both for development of +This document serves to provide Kyverno users with an initial understanding of Kyverno's +security, where to find existing security documentation, Kyverno plans for +security, and general overview of Kyverno security practices, both for development of Kyverno as well as security of Kyverno. -This document provides the CNCF SIG-Security with an initial understanding of Kyverno -to assist in a joint-review, necessary for projects under incubation. Taken -together, this document and the joint-review serve as a cornerstone for if and when +This document provides the CNCF TAG-Security with an initial understanding of Kyverno +to assist in a joint-review, necessary for projects under incubation. Taken +together, this document and the joint-review serve as a cornerstone for if and when Kyverno seeks graduation and is preparing for a security audit. @@ -86,43 +86,79 @@ The following diagram shows the logical architecture for Kyverno. Each major com ![Kyverno Logical Architecture](images/kyverno-architecture.png) -### Webhook +Kyverno consists of four main controllers that work together to provide comprehensive policy management capabilities. Each controller handles specific aspects of policy processing, from admission control to background operations and cleanup tasks. -The `Webhook` component registers as a validating and mutating admission webhook and receives `AdmissionReview` requests from the API server to validate and mutate configuration changes, based on policies. Users can configure which namespaces and resources the webhooks will receive via command line options or the ConfigMap. +### Admission Controller -The `Webhook` also creates and updates `GenerateRequest` and `PolicyChangeRequest` resources to trigger updates via other Kyverno controllers. +* Receives AdmissionReview requests from the Kubernetes API server through validating and mutating webhooks. +* Processes validate, mutate, and image validating rules. +* Manages and renews certificates as Kubernetes Secrets for webhook use through the embedded Cert Renewer. +* Manages and configures webhook rules dynamically based on installed policies through the embedded Webhook Controller. +* Performs policy validation for the `Policy`, `ClusterPolicy`, `ValidatingPolicy`, `ImageValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, and `PolicyException` custom resources. +* Processes Policy Exceptions. +* Generates `EphemeralReport` and `ClusterEphemeralReport` intermediary resources for further processing by the Reports Controller. +* Generates `UpdateRequest` intermediary resources for further processing by the Background Controller. -### Webhook Monitor +### Reports Controller -On startup, Kyverno's `Webhook Monitor` component generates a self-signed certificate (or uses a user-provided certificate) and auto-creates the webhook configurations required to register Kyverno as an admission webhook. The component also periodically monitors if Kyverno is receiving webhook events and recreates the certificate and webhook configurations if needed. +* Responsible for creation and reconciliation of the final `PolicyReport` and `ClusterPolicyReport` custom resources. +* Performs background scans and generates, processes, and converts `EphemeralReport` and `ClusterEphemeralReport` intermediary resources into the final policy report resources. -### Generate Controller +### Background Controller -The `Generate Controller` watches `GenerateRequest` resources and creates, updates, and deletes Kubernetes resources based on Kyverno [generate rules](https://kyverno.io/docs/writing-policies/generate/). The `Generate Controller` also watches for changes in policy definitions to update generated resources. +* Processes generate and mutate-existing rules of the `Policy` or `ClusterPolicy`, and the mutate-existing functionality of the `MutatingPolicy` and `GeneratingPolicy`. +* Processes policy add, update, and delete events. +* Processes and generates `UpdateRequest` intermediary resources to generate or mutate the final resource. +* Generates `EphemeralReport` and `ClusterEphemeralReport` intermediary resources for further processing by the Reports Controller. -### Policy Controller +### Cleanup Controller -The `Policy Controller` performs periodic background scans on existing configurations and creates or updates policy reports based on changes and background scans. The `Policy Controller` watches `ReportChangeRequest` resources and creates, updates, and delete Kyverno [Policy Report](https://kyverno.io/docs/policy-reports/) resources. The `Policy Controller` also watches for changes in policies definitions to update policy reports. +* Processes `CleanupPolicy` and `DeletingPolicy` resources. +* Performs policy validation for the CleanupPolicy and ClusterCleanupPolicy custom resources through a webhook server. +* Reconciles its webhook through a webhook controller. +* Manages and renews certificates as Kubernetes Secrets for use in the webhook. +* Creates and reconciles CronJobs used as the mechanism to trigger cleanup. +* Handles the cleanup by deleting resources from the Kubernetes API. ## Physical Architecture -Kyverno can be installed using a [Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) or YAML files (see [installation doc](https://kyverno.io/docs/installation/)). - -The Kyverno application consists of a: -1. Service -2. Deployment -3. Roles -4. Role Bindings -5. Custom Resource Definitions -6. Service account - -When Kyverno runs, it will check for a named `Secret` with a certificate to use for webhook registration. If the secret does not exist, Kyverno will generate a self-signed certificate and store it in the secret. Kyverno will then generate or update the mutating and validating webhook configurations. +Kyverno can be installed using a [Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) or YAML files (see [installation doc](https://kyverno.io/docs/installation/)). The diagram below shows the Kyverno physical architecture: ![Kyverno Physical Architecture](images/kyverno-physical-architecture.png) -**NOTE:** Currently Kyverno runs as one multi-instance (HA) `Pod` managed by a single `Deployment`. In the future the different controllers may be packaged in separate deployments to allow flexibility in scaling and tuning each component. +A standard Kyverno installation consists of a number of different components, some of which are optional: + +**Deployments** +* Admission controller (required): The main component of Kyverno which handles webhook callbacks from the API server for verification, mutation, Policy Exceptions, and the processing engine. +* Background controller (optional): The component responsible for processing of generate and mutate-existing rules. +* Reports controller (optional): The component responsible for handling of Policy Reports. +* Cleanup controller (optional): The component responsible for processing of Cleanup Policies and Deleting Policies. + +**Services** +* Services needed to receive webhook requests. +* Services needed for monitoring of metrics. + +**ServiceAccounts** +* One ServiceAccount per controller to segregate and confine the permissions needed for each controller to operate on the resources for which it is responsible. + +**ConfigMaps** +* ConfigMap for holding the main Kyverno configuration. +* ConfigMap for holding the metrics configuration. + +**Secrets** +* Secrets for webhook registration and authentication with the API server. + +**Roles and Bindings** +* Roles and ClusterRoles, Bindings and ClusterRoleBindings authorizing the various ServiceAccounts to act on the resources in their scope. + +**Webhooks** +* ValidatingWebhookConfigurations for receiving both policy and resource validation requests. +* MutatingWebhookConfigurations for receiving both policy and resource mutating requests. + +**CustomResourceDefinitions** +* CRDs which define the custom resources corresponding to policies, reports, and their intermediary resources. ## Security functions and features @@ -145,7 +181,7 @@ Kyverno does not currently document meeting particular compliance standards. ## Secure development practices -The Kyverno project follows established CNCF and OSS best practices for code development and delivery: +The Kyverno project follows established CNCF and OSS best practices for code development and delivery. ### Development Pipeline @@ -157,7 +193,7 @@ The [Kyverno container images](https://github.com/orgs/kyverno/packages) are hos The [Kyverno Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) is hosted in ArtifactHub. There is a pending issue to to sign the Helm Chart using Sigstore Cosign (https://github.com/kyverno/kyverno/issues/2758). -The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/definitions/install.yaml) are hosted in the GitHub repository. +The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/config/install-latest-testing.yaml) are hosted in the GitHub repository. A Software Bill of Materials (SBOM) is produced and made available for each release (https://main.kyverno.io/docs/security/#fetching-the-sbom-for-kyverno). @@ -187,9 +223,9 @@ All Kyverno security related issues (both fixes and enhancements) are labeled wi https://github.com/kyverno/kyverno/labels/security -### [CII Best Practices](https://www.coreinfrastructure.org/programs/best-practices-program/) +### [CII Best Practices](https://www.bestpractices.dev/) -The Kyverno project has adopted the OSSF/Scorecard and is tracking progress in [issue #2617](https://github.com/kyverno/kyverno/issues/2617). +The Kyverno project has passed the OpenSSF Scorecard check and is actively working towards achieving silver/gold level certification. Progress is being tracked via [issue 10908](https://github.com/kyverno/kyverno/issues/10908). ### Related Projects / Vendors diff --git a/projects/wasmedge/security-assessment/joint-assessment.md b/projects/wasmedge/security-assessment/joint-assessment.md new file mode 100644 index 000000000..8f48a1e5b --- /dev/null +++ b/projects/wasmedge/security-assessment/joint-assessment.md @@ -0,0 +1,53 @@ +# WasmEdge TAG-Security Security Assessment + + +Completed: 01 07 2025 + +Security reviewers: Justin Cappos @JustinCappos, Marina Moore @mnm678, Constanze Röedig @entlein, Camila Vilarinho @camilaavilarinho, and Victor Lu @victorjunlu + +Project security lead: Hung-Ying Tai @hydai + +Project team: Hung-Ying Tai @hydai, Meng-Han Lee @dm4 + +* Source code: +* Web site: + +## Summary + +The project has built a reasonably secure system with appropriate security controls. However, the security limitations, testing requirements, and benefits could be better communicated to users. Additional focus on going above common recommendations would strengthen the project's security posture. The assessment team appreciates WasmEdge's cooperation in answering questions and clarifying the self-assessment document. + +## Recommendations + +### CNCF recommendations + +* Improve documentation translation across languages, especially into English +* Consider adopting CNCF security best practices for software supply chain attestations (in-toto/SLSA) +* Explore integration with CNCF security projects like SPIFFE/SPIRE for workload identity + +### Project recommendations + +1. The document needs to clearly say about whether you add a formal verifier for your runtime. What do other runtimes provide to validate they are correctly implementing the WASM spec? +2. Have you done validation of how you’re using WASI, what interfaces you are providing, their security, etc.? For example, as an illustrative example, can you explain how you’ve validated that your \--dir interface doesn’t have path traversal vulnerabilities? What is the guidance you give to users who want to use this interface to make sure they do so securely? Are they free to add symlinks / mount file systems, etc. into that part of the directory namespace, etc.? +3. Does the fact that WASI isn’t portable and has a lot of undefined behavior give users any security concerns? +4. How are you doing updates of your core functionality on the device? [https://uptane.org/](https://uptane.org/) + or [https://theupdateframework.com/](https://theupdateframework.com/) +5. Do you (or should you) be attesting to the software running on the edge device? Are you doing software supply chain attestations (in-toto / SLSA, etc.)? Would this be helpful / useful? Would users expect this functionality? Consider: [https://github.com/in-toto/in-toto](https://github.com/in-toto/in-toto) [https://datatracker.ietf.org/group/scitt/about/](https://datatracker.ietf.org/group/scitt/about/) [https://slsa.dev/](https://slsa.dev/) +6. Please explain clearly about how one would use things like non-human identities, monitoring, security filtering, etc. Is everything completely compatible with SPIFFE/SPIRE? Are there any differences in use in comparison to e.g.: [https://wasmcloud.com/blog/2025-03-04-why-were-adopting-spiffe-for-webassembly-workload-identity/](https://wasmcloud.com/blog/2025-03-04-why-were-adopting-spiffe-for-webassembly-workload-identity/) +7. What should users be thinking about with respect to data residency and jurisdictional constraints when processing sensitive data in WasmEdge? How does being at the edge change this equation? +8. Please, add to the main body of the document (and on github) + \- how you ensure continuous verification/testing of the WASM specification of all components (the Verifier, the Loader, the Engine \- every main component in scope of WASM-Edge). + Example: + Where Side Channel Attacks are tested against and how the code verifiably written in “side-channel resistant” way. [https://github.com/WebAssembly/constant-time/blob/main/proposals/constant-time/Overview.md](https://github.com/WebAssembly/constant-time/blob/main/proposals/constant-time/Overview.md) + Can you add to the document for each major attack-class: how is it being tested/fuzzed and can you show in your repo/artifacts, and comment how you’d resolve any failures. +9. Ensure that it is clear why you are having failures on tests when building the code. Your code is being pushed to production regardless. Why is this appropriate? +10. The project could benefit from more effort to explain the security aspects of their design to their userbase. +11. The project would benefit from putting a link (and also a github-badge) in the main-README that goes directly to the security testing/definitions. Fixed by [https://github.com/WasmEdge/WasmEdge/pull/4216](https://github.com/WasmEdge/WasmEdge/pull/4216) + +### Additional recommendations + +* Consider implementing Uptane or TUF for secure updates of core functionality on edge devices +* Evaluate implementing software attestation for edge device workloads +* Provide clearer guidance on data residency and jurisdictional constraints for sensitive data processing + +Tracking issue: +Tracking project board: diff --git a/projects/wasmedge/security-assessment/self-assessment.md b/projects/wasmedge/security-assessment/self-assessment.md index b8246414b..05f9918ee 100644 --- a/projects/wasmedge/security-assessment/self-assessment.md +++ b/projects/wasmedge/security-assessment/self-assessment.md @@ -1,5 +1,5 @@ # WasmEdge Security Self-assessment - + Authors: dm4(@dm4) @@ -31,7 +31,7 @@ A table at the top for quick reference information, later used for indexing. | Software | | | Security Provider | No. | | Languages | C++ | -| SBOM | The software bill of materials for WasmEdge can be found at [LICENSE.spdx](https://github.com/WasmEdge/WasmEdge/blob/master/LICENSE.spdx) | +| SBOM | The software bill of materials for WasmEdge can be found at [LICENSE.spdx](https://github.com/WasmEdge/WasmEdge/blob/master/LICENSE.spdx) and in [sbom.tar.gz](https://github.com/WasmEdge/WasmEdge/releases/download/0.14.1/sbom.tar.gz) within each release. | ### Security links @@ -51,104 +51,88 @@ devices. ### Background -The WasmEdge Runtime provides a well-defined execution sandbox for its contained -WebAssembly bytecode program. The runtime offers isolation and protection for -operating system resources (e.g., file system, sockets, environment variables, -processes) and memory space. The most important use case for WasmEdge is to -safely execute user-defined or community-contributed code as plug-ins in a -software product (e.g., SaaS, software-defined vehicles, edge nodes, or even -blockchain nodes). It enables third-party developers, vendors, suppliers, and -community members to extend and customize the software product. +The WasmEdge Runtime provides a well-defined execution sandbox for its contained WebAssembly bytecode program. The runtime offers isolation and protection for operating system resources (e.g., file system, sockets, environment variables, processes) and memory space. Because the implementation of WasmEdge follows the WebAssembly spec, each module can execute within a sandboxed environment that is separated from the host runtime. You can refer to [WebAssembly/Security](https://webassembly.org/docs/security/). + +Since WebAssembly essentially defines a virtual instruction set architecture (virtual ISA), and WasmEdge is the runtime used to execute this instruction set, when considering the security of WasmEdge, we must understand what instructions WebAssembly defines and whether any instruction can affect the host environment (the environment where WasmEdge is executed) during execution. + +According to the WebAssembly specification, any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the runtime and imported into a WebAssembly module (Reference: [WebAssembly - Introduction - Security Considerations](https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations)). + +Therefore, we can ascertain that when WasmEdge executes any WebAssembly instruction, as long as it is not calling imported functions, the executed instruction will not affect the host environment (the environment where WasmEdge is executed). + +For imported functions that can affect the host environment, WasmEdge implements them through the [WebAssembly System Interface (WASI)](https://github.com/WebAssembly/WASI). WasmEdge runs the [WebAssembly/wasi-testsuite](https://github.com/WebAssembly/wasi-testsuite) during testing to ensure implementation correctness. + +For each module, all OS resources are accessed through the WebAssembly System Interface (WASI). Therefore, each module can only see the virtual resources provided by WasmEdge. This approach allows WasmEdge to effectively manage OS resources. On the same host, each executing wasm program sees an independent set of OS resources and memory space, managed by WasmEdge. + +The most important use case for WasmEdge is to safely execute user-defined or community-contributed code as plug-ins in a software product (e.g., SaaS, software-defined vehicles, edge nodes, or even blockchain nodes). +It enables third-party developers, vendors, suppliers, and community members to extend and customize the software product. For example, by adding support for WebAssembly functionality in a software product, we can support machine learning interfaces like [WASI-NN](https://github.com/WebAssembly/wasi-nn). +This makes it easier for developers to support machine learning backends such as OpenVINO or PyTorch. ### Actors -- WasmEdge Tool - - Provides CLI tools for users. - - The CLI tools offer a user-friendly interface to interact with WasmEdge - functionalities. - - Includes commands for compiling, running, and debugging WebAssembly - applications. -- WasmEdge Loader - - Loads the WebAssembly bytecode file. - - Parses the loaded bytecode to Abstract Syntax Tree (AST). - - Ensures that the bytecode is correctly structured for further processing. -- WasmEdge Validator - - Validates the parsed bytecode AST to ensure it complies with WebAssembly - specifications. - - Checks for semantic correctness and security constraints. - - Ensures that the bytecode does not contain any invalid or malicious - instructions. -- WasmEdge Engine - - The actual WebAssembly runtime that executes the bytecode. - - Interprets the bytecode and performs the corresponding operations. - - Manages the execution environment, including memory, stack, and system - resources. - - Ensures efficient and secure execution of WebAssembly modules. +* WasmEdge Tool + * Provides CLI tools for users. + * The CLI tools offer a user-friendly interface to interact with WasmEdge functionalities. + * Includes commands for compiling, running, and debugging WebAssembly applications. + * WasmEdge will verify whether the options passed to the CLI are valid. If a specified option does not exist or is invalid, a warning will be displayed. However, any parameters passed to the wasm program will be passed through and handled by the wasm program itself. +* WasmEdge Loader + * Loads the WebAssembly bytecode file. + * Parses the loaded bytecode to an Abstract Syntax Tree (AST). + * The structure of the AST is defined in the WebAssembly specification. After the Loader reads the bytecode of a wasm program, it will check whether these bytecode conform to the [WebAssembly binary format](https://webassembly.github.io/spec/core/binary/index.html). + * Ensures that the bytecode is correctly structured for further processing. + * To ensure the correctness of the WasmEdge Loader, we use the official WebAssembly spec tests ([WebAssembly/spec/test/core](https://github.com/WebAssembly/spec/tree/main/test/core)) in our unit tests. These unit tests are executed with every pull request to ensure the correctness of the Loader. +* WasmEdge Validator + * Validates the parsed bytecode AST to ensure it complies with WebAssembly specifications. + * Checks for semantic correctness to ensure that the AST read by the Loader is valid, according to the [WebAssembly validation](https://webassembly.github.io/spec/core/valid/index.html). + * During this phase, the Validator performs type checking of functions and the instruction sequences in their bodies, ensuring that the operand stack is used consistently, among other checks. +* WasmEdge Engine + * The actual WebAssembly runtime that executes the bytecode. + * Interprets the bytecode and performs the corresponding operations. + * Manages the execution environment, including memory, stack, and system resources. + * Ensures efficient and secure execution of WebAssembly modules. + * Each module can only see the virtual resources and virtual memory provided by the WasmEdge Engine. This approach allows the WasmEdge Engine to effectively manage OS resources and memory. On the same host, each executing wasm program sees an independent set of OS resources and memory space, managed by the WasmEdge Engine. ### Actions -To execute WebAssembly code, WasmEdge follows a series of steps involving -multiple components, each with specific responsibilities. Here is a detailed -description of the process, focusing on data flow and interactions between -components: +To execute WebAssembly code, WasmEdge follows a series of steps involving multiple components, each with specific responsibilities. Here is a detailed description of the process, focusing on data flow and interactions between components: * Interacting with Users (WasmEdge Tool) - - Data Input: The WasmEdge Tool provides a Command-Line Interface (CLI) for - users to interact with the WasmEdge functionalities. - - Action: Users can issue commands to compile, run, and debug WebAssembly - applications. These commands are processed by the CLI tools, which - internally utilize the Loader, Validator, and Engine components to carry - out the requested actions. - - Output: The CLI tools offer feedback to the users, such as execution - results, debug information, and error messages. + + * Data Input: The WasmEdge Tool provides a Command-Line Interface (CLI) for users to interact with the WasmEdge functionalities. + * Action: Users can issue commands to compile, run, and debug WebAssembly applications. These commands are processed by the CLI tools, which internally utilize the Loader, Validator, and Engine components to carry out the requested actions. All of these components are packaged into one WasmEdge binary. + * Output: The CLI tools offer feedback to the users, such as execution results, debug information, and error messages. * Loading the WebAssembly Bytecode (WasmEdge Loader) - - Data Input: The process begins with the WasmEdge Loader component, which - receives a WebAssembly bytecode file as input. - - Action: The Loader reads and parses this bytecode file, converting it into - an Abstract Syntax Tree (AST). - - Output: The AST, which represents the structured form of the bytecode, is - produced as output for further processing. + + * Data Input: The process begins with the WasmEdge Loader component, which receives a WebAssembly bytecode file as input. + * Action: The Loader reads and parses this bytecode file, converting it into an Abstract Syntax Tree (AST). + * Output: The AST, which represents the structured form of the bytecode, is produced as output for further processing. * Validating the Bytecode (WasmEdge Validator) - - Data Input: The AST generated by the Loader is passed to the WasmEdge - Validator. - - Action: The Validator component checks the AST to ensure that it complies - with WebAssembly specifications. This involves verifying semantic - correctness and security constraints, ensuring there are no invalid or - malicious instructions. - - Output: If the bytecode is valid, the Validator produces a validated AST. - If invalid, it generates error messages indicating the issues found. + + * Data Input: The AST generated by the Loader is passed to the WasmEdge Validator. + * Action: The Validator component checks the AST to ensure that it complies with WebAssembly specifications. + This involves verifying semantic correctness and security constraints, ensuring there are no invalid or malicious instructions. According to the current design, unvalidated modules cannot be executed. After validating a module, we [set the validated flag](https://github.com/WasmEdge/WasmEdge/blob/7a4e4ae/lib/validator/validator.cpp#L130), and when initiating a module, + we [check the validated flag](https://github.com/WasmEdge/WasmEdge/blob/master/lib/executor/instantiate/module.cpp#L20) to ensure that only validated modules can be executed. + * Output: If the bytecode is valid, the Validator produces a validated AST. If invalid, it generates error messages indicating the issues found. * Executing the Bytecode (WasmEdge Engine) - - Data Input: The validated AST is passed to the WasmEdge Engine, which is - the core component responsible for executing the WebAssembly code. - - Action: The Engine interprets the bytecode and performs the corresponding - operations. It manages the execution environment, including memory, stack, - and system resources. This ensures efficient and secure execution of the - WebAssembly modules. - - Output: The execution results, which could include changes in memory, - generated outputs, or responses from invoked functions. - -The interaction between these components ensures a smooth and secure execution -flow for WebAssembly programs in WasmEdge. The Loader initiates the process by -parsing the bytecode, the Validator ensures its compliance with standards, the -Engine executes the validated code, and the Tool provides a user-friendly -interface for these operations. This modular approach allows for efficient -handling and execution of WebAssembly code, making WasmEdge a robust and -high-performance WebAssembly runtime. + + * Data Input: The validated AST is passed to the WasmEdge Engine, which is the core component responsible for executing the WebAssembly code. + * Action: The Engine interprets the bytecode and performs the corresponding operations. It manages the execution environment, including memory, stack, and system resources. This ensures efficient and secure execution of the WebAssembly modules. + * Output: The execution results, which could include changes in memory, generated outputs, or responses from invoked functions. + +The interaction between these components ensures a smooth and secure execution flow for WebAssembly programs in WasmEdge. The Loader initiates the process by parsing the bytecode, the Validator ensures its compliance with standards, the Engine executes the validated code, and the Tool provides a user-friendly interface for these operations. This modular approach allows for efficient handling and execution of WebAssembly code, making WasmEdge a robust and high-performance WebAssembly runtime. ### Goals -- Provides a well-defined execution sandbox for its contained WebAssembly - bytecode program. -- Offers isolation and protection for operating system resources and memory - space. -- Execute user-defined or community-contributed code as plugins. +* Provide a well-defined execution sandbox for contained WebAssembly bytecode programs. +* Offer isolation and protection for operating system resources and memory space. +* Execute user-defined or community-contributed code as plug-ins. ### Non-goals -- Compile the C++ code into WebAssembly bytecode. +* Compile code from any language into WebAssembly bytecode. +* Regarding the issue of DoS: if users execute relatively high-load programs on resource-constrained devices leading to DoS, it is not within our focus scope. We believe that if DoS is caused by improper design of the WasmEdge engine or executor, then that is our focus goal. ## Self-assessment use @@ -170,14 +154,15 @@ security audit. ## Security functions and features -- WasmEdge is a standalone WebAssembly runtime where all WebAssembly bytecode - runs independently within this execution sandbox, rather than being managed by - the OS. Access to system resources, whether files, hardware, or internet - connections, can only be achieved through the WebAssembly system interfaces - provided by this virtual machine. -- If users want to access the host OS's filesystem within the WasmEdge runtime, - they can add the `--dir guest_path:host_path:readonly` option in the WasmEdge - CLI to assign the read-only configuration. +* WasmEdge is a standalone WebAssembly runtime where all WebAssembly bytecode runs independently within this execution sandbox, rather than being managed by the OS. Access to system resources, whether files, hardware, or internet connections, can only be achieved through the WebAssembly system interfaces (WASI) provided by WasmEdge. +* By following the WebAssembly specification, WasmEdge has the same security properties. Here are some of the main security properties: + * Modular Isolation: Wasm runs in a sandboxed environment, ensuring that each WebAssembly module is isolated from other modules and the host environment. This isolation prevents direct memory access between modules, enhancing security. Side channel attacks are outside the scope of our focus. + * Linear Memory Model: Wasm uses a linear memory model, meaning memory is treated as a contiguous byte array. This model prevents common programming errors found in traditional languages, such as buffer overflows. + * Type Safety: WebAssembly is strongly typed, with type checks performed both at compile-time and runtime. This reduces the risk of security vulnerabilities caused by type errors. + * No Direct System Calls: Wasm does not allow direct system calls, meaning that even if the code is compromised, it is difficult to directly harm the host system. +* If users want to access the host OS's filesystem within the WasmEdge runtime, they can add the `--dir guest_path:host_path` option in the WasmEdge CLI. +* If users want to prevent host files from being modified, they can add the :readonly flag in the option, like `--dir guest_path:host_path:readonly`. The WasmEdge runtime will manage the filesystem usage to grant only read-only access to the wasm program. +* Currently, only the `--dir` option allows the host's filesystem to be accessed by the wasm program through the WASI, using the virtual filesystem provided by WasmEdge. This part is implemented in accordance with the [WASI-filesystem](https://github.com/WebAssembly/wasi-filesystem) API. ## Project compliance @@ -185,71 +170,104 @@ security audit. ## Secure development practices -- Development Pipeline - - WasmEdge Require contributors to sign off on web-based commits. - - The pull request must be approved by WasmEdge maintainer, committer or - reviewers before merge. - - The pull request must pass the CI jobs before merge. - - WasmEdge also participates in OSS-Fuzz +* Development Pipeline + * WasmEdge requires contributors to sign off on web-based commits. + * A normal pull request must be approved by one of the WasmEdge maintainers, committers, or reviewers before merging. However, a governance-related pull request must be approved by 75% of the WasmEdge maintainers. + * For a new contributor, their pull request will not be able to be triggered unless one of the WasmEdge maintainers or committers approves the CI permission to avoid attacks on the workflow. + * As mentioned in our [GOVERNANCE.md](https://github.com/WasmEdge/WasmEdge/blob/master/docs/GOVERNANCE.md), in extreme cases, maintainers can initiate a vote to remove a specific maintainer from the maintainer list through the voting process. + * The pull request must pass the CI jobs before merging. + * In the tests used for WasmEdge, there are many security-related tests from the official WebAssembly spec test, such as out-of-bound memory access, invalid type, malformed binary, and so on. + * The source of the official WebAssembly spec test is at [WebAssembly/spec/test](https://github.com/WebAssembly/spec/tree/main/test). + We have converted these tests into a format executable by WasmEdge, available at [WasmEdge/wasmedge-spectest](https://github.com/WasmEdge/wasmedge-spectest). + The entry for these tests on CI is in [build.yml](https://github.com/WasmEdge/WasmEdge/blob/master/.github/workflows/build.yml), and the test results can be seen in [Test WasmEdge Core](https://github.com/WasmEdge/WasmEdge/actions/workflows/build.yml). + The logs of the CI tests are publicly available. + * WasmEdge also participates in OSS-Fuzz . OSS-Fuzz aims to make common open-source software more secure and stable by combining modern fuzzing techniques with scalable, distributed execution. Participating in OSS-Fuzz allows us to better identify potential issues in WasmEdge through fuzzing. -- Communication Channels - - Internal - - Direct message on [WasmEdge Discord - server](https://discord.gg/h4KDyB8XTt). - - Inbound - - [WasmEdge Discord server](https://discord.gg/h4KDyB8XTt). - - **#wasmedge** channel on the [CNCF Slack](https://slack.cncf.io/). - - Outbound - - [WasmEdge Discord server](https://discord.gg/h4KDyB8XTt). - - **#wasmedge** channel on the [CNCF Slack](https://slack.cncf.io/). - - Mailing list . - - We host a monthly community meeting to showcase new features, demo new - use cases, and a Q&A part. - - The first Tuesday of each month at 11PM Hong Kong Time/ 7AM PST. +* Communication Channels + * Internal + * Direct message on [WasmEdge Discord server](https://discord.gg/h4KDyB8XTt). + * Inbound + * [WasmEdge Discord server](https://discord.gg/h4KDyB8XTt). + * **#wasmedge** channel on the [CNCF Slack](https://slack.cncf.io/). + * Outbound + * [WasmEdge Discord server](https://discord.gg/h4KDyB8XTt). + * **#wasmedge** channel on the [CNCF Slack](https://slack.cncf.io/). + * Mailing list . + * We host a monthly community meeting to showcase new features, demo new use cases, and a Q&A part. + * The first Tuesday of each month at 11 PM Hong Kong Time/ 7 AM PST. +* Ecosystem + + WasmEdge is a highly optimized WebAssembly runtime environment that seamlessly integrates into the cloud-native ecosystem, particularly in terms of container runtimes. WasmEdge can serve as a WebAssembly image runtime in Kubernetes, which gives it a unique advantage in cloud-native infrastructure. + + Firstly, WasmEdge offers extremely fast startup times, which is crucial in scenarios requiring rapid response, such as Edge Computing. Secondly, WasmEdge has a smaller memory and disk space footprint, enabling it to run efficiently in resource-constrained environments. This is a significant advantage for applications that need to run multiple microservices on edge devices such as Android, OpenHarmony, Raspberry Pi, and the seL4 RTOS. + + Moreover, the integration of WasmEdge with Kubernetes means it can directly leverage existing cloud-native tools and infrastructure, such as container orchestration, service discovery, and auto-scaling, further enhancing its applicability in the cloud-native ecosystem. These features make WasmEdge a powerful tool capable of meeting the demands of modern applications, particularly in scenarios that require efficient, lightweight, and rapid deployment. ## Security issue resolution -As stated in the [WasmEdge security -document](https://github.com/WasmEdge/WasmEdge/blob/master/SECURITY.md), the -process for handling security reports is as follows: +As stated in the [WasmEdge security document](https://github.com/WasmEdge/WasmEdge/blob/master/SECURITY.md), the process for handling security reports is as follows: Users can use the below process to report a vulnerability to WasmEdge: Email: 1. Send email to - * Emails should contain: - * description of the problem - * precise and detailed steps (include screenshots) that created the - problem - * the affected version(s) - * any possible mitigations, if known -1. You will receive a reply from one of the maintainers within 24 hours - acknowledging receipt of the email. After that, we will give a detailed - response about the subsequent process within 48 hours. -1. Please do not submit security vulnerabilities directly as Github Issues. + * Emails should contain: + * description of the problem + * precise and detailed steps (including screenshots) that created the problem + * the affected version(s) + * any possible mitigations, if known + * This mailing list is only visible to the security contacts defined in [WasmEdge/SECURITY_CONTACTS.md](https://github.com/WasmEdge/WasmEdge/blob/master/docs/SECURITY_CONTACTS.md). +2. You will receive a reply from one of the maintainers within 24 hours acknowledging receipt of the email. After that, we will give a detailed response about the subsequent process within 48 hours. +3. Please do not submit security vulnerabilities directly as GitHub Issues. Web: -1. Please visit [GitHub Security Advisory of - WasmEdge](https://github.com/WasmEdge/WasmEdge/security/advisories/new) +1. Please visit the [GitHub Security Advisory of WasmEdge](https://github.com/WasmEdge/WasmEdge/security/advisories/new) * You will receive a confirmation email upon submission -WasmEdge follows a **`90 days` disclosure timeline**. For known public security -vulnerabilities, we will disclose the disclosure as soon as possible after -receiving the report. Vulnerabilities discovered for the first time will be -disclosed in accordance with the following process: - -* The received security vulnerability report shall be handed over to the - security team for follow-up coordination and repair work. -* After the vulnerability is confirmed, we will create a draft Security Advisory - on Github that lists the details of the vulnerability. -* Invite related personnel to discuss about the fix. -* Fork the temporary private repository on Github, and collaborate to fix the - vulnerability. -* After the fix code is merged into all supported versions, the vulnerability - will be publicly posted in the GitHub Advisory Database. +WasmEdge follows a **`90 day` disclosure timeline**. For known public security vulnerabilities, we will disclose the vulnerability as soon as possible after receiving the report. Vulnerabilities discovered for the first time will be disclosed in accordance with the following process: + +* The received security vulnerability report shall be handed over to the security team for follow-up coordination and repair work. +* After the vulnerability is confirmed, we will create a draft Security Advisory on Github that lists the details of the vulnerability. +* Invite related personnel to discuss how to create the fix. +* Fork the temporary private repository on Github, and collaborate to fix the vulnerability. +* We aim to fix the reported vulnerability within a 90-day disclosure timeline and release a new version for end-users within this period. +* On some occasions, we may need to extend this timeline due to the complexity of the problem, lack of available expertise, or other reasons. Submitters will be notified if an extension occurs. +* After the fix code is merged into [all supported versions](https://github.com/WasmEdge/WasmEdge/blob/master/SECURITY.md#supported-versions), the vulnerability will be publicly posted in the GitHub Advisory Database. +* We have a mailing list at , which you can join or browse through this link: [https://groups.google.com/g/wasmedge/](https://groups.google.com/g/wasmedge/). We plan to send upgrade notifications through this mailing list. + +## Appendix + +### Known Issues Over Time + +* [Off-by-one vulnerability of PC stack](https://github.com/ha1vk/blackhat_wasm), which successfully conducts RCE on the host. This was fixed in commit [f2d1427](https://github.com/WasmEdge/WasmEdge/commit/f2d1427). +* [OSV-2023-1119](https://osv.dev/vulnerability/OSV-2023-1119) Segv on unknown address in FunctionCompiler::compileReturn. This was fixed in commit [9ba5f8f](https://github.com/WasmEdge/WasmEdge/commit/9ba5f8f). +* [OSV-2024-140](https://osv.dev/vulnerability/OSV-2024-140) Container-overflow in WasmEdge::LLVM::Compiler::compile. This was fixed in commit [62ce0ee](https://github.com/WasmEdge/WasmEdge/commit/62ce0ee). + +### OpenSSF Best Practices + +[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/5059/badge)](https://www.bestpractices.dev/projects/5059) + +Currently, WasmEdge has a passing level badge for CII best practices. To achieve the silver level badge, WasmEdge still needs to work on the following aspects: + +* Project oversight: For instance, all developers making significant contributions to the project software should declare that they have the legal authority to make such contributions, or clearly define and document the governance model or code of conduct. +* Documentation: This self-assessment document could be used as an architecture document, but we still need some practices for accessibility and internationalization, among others. + +These areas are goals that WasmEdge is continuously working towards to comply with OpenSSF Best Practices. + +### Case Studies + +* Developers can leverage container tools such as Kubernetes, Docker, and CRI-O to deploy, manage, and run lightweight WebAssembly applications. For example, using [KWasm/kwasm-operator](https://github.com/KWasm/kwasm-operator), you can easily specify WasmEdge as the runtime in the YAML file to execute a specified WebAssembly image, such as `wasmedge/example-wasi:latest`. +* Through WasmEdge's WASI-NN support, machine learning-related functions can be implemented via the WASI-NN API. For instance, [LlamaEdge](https://github.com/LlamaEdge/LlamaEdge) utilizes this feature to perform LLM inference using WasmEdge as the runtime. + +### Related Projects / Vendors + +* [WebAssembly Specification](https://webassembly.github.io/spec/core/): The WebAssembly draft specification, a reference implementation, and the official testsuite. +* [WebAssembly/WASI](https://github.com/WebAssembly/WASI): The WebAssembly System Interface (WASI) is a set of APIs for WASI being developed for eventual standardization by the WASI Subgroup, which is a subgroup of the WebAssembly Community Group. +* [crun](https://github.com/containers/crun): A fast and low-memory footprint OCI Container Runtime fully written in C, which has WasmEdge support. +* [LlamaEdge](https://github.com/LlamaEdge/LlamaEdge): The LlamaEdge project makes it easy for you to run LLM inference apps and create OpenAI-compatible API services for the Llama2 series of LLMs locally.