laskoviymishka commented on code in PR #1886: URL: https://github.com/apache/iceberg-go/pull/1886#discussion_r3875514808
########## SECURITY-THREAT-MODEL.md: ########## @@ -19,205 +19,461 @@ # Apache Iceberg Go Security Threat Model -This document describes the detailed security threat model for Apache -Iceberg Go. It is intended for maintainers and automated security triage. +## Status and Reporting + +This document is detailed guidance for Apache Iceberg Go maintainers and +automated security triage. It describes classification defaults and the +evidence needed to raise confidence; it does not replace case-by-case review by +the project or the Apache Security Team. + +Possible vulnerabilities must be reported privately through the Apache Security +Team process. This document guides classification and scanner confidence; it +does not authorize public disclosure and does not automatically accept or +reject a report. + +Follow the [Apache Iceberg security model](https://iceberg.apache.org/security/) +and the [Apache security vulnerability reporting +process](https://www.apache.org/security/). Send undisclosed Iceberg reports to +`[email protected]`; the Apache Security Team's +`[email protected]` address remains a private fallback. Do not open a public +issue for a possible undisclosed vulnerability. ## Purpose -Apache Iceberg Go is primarily a client library and implementation of the -Iceberg table format and catalog interactions for Go applications and services. -It is typically embedded in larger systems that provide their own -authentication, authorization, and credential management. Because of that -deployment model, not every unsafe or surprising behavior is a security -vulnerability in Iceberg Go itself. +Apache Iceberg Go is a client library, table-format implementation, catalog +client, and command-line tool. It is commonly embedded in applications and +services that supply their own authorization, credential management, and +storage policy. -This model is intended to answer: +This threat model helps a reviewer describe: -- what Iceberg Go generally treats as a security vulnerability -- what Iceberg Go generally treats as correctness, hardening, or deployment - work -- which boundaries are primarily owned by Iceberg Go versus the surrounding - catalog, application, or service -- which issue classes should be downgraded by default by scanners +- the actor and the capability the actor already has; +- the input or service the actor controls; +- the Iceberg Go-owned or external boundary affected; +- any secret or credential that reaches a new audience; and +- demonstrated confidentiality, integrity, availability, memory, or + destructive impact. -## Scope +The categories below are conditional triage defaults, not blanket rejection +rules. A finding that crosses an Iceberg Go-owned boundary or demonstrates a +security impact must be reviewed even when it also has a normally trusted +precondition. -This model is scoped to the Apache Iceberg Go repository itself: +In this document, a **new audience** is any log, error, CLI text or JSON output, +serialized metadata, host, catalog or client, or principal that was not already +authorized to receive the secret, credential, or credential-bearing request. -- table format and metadata handling -- catalog and REST catalog clients -- transport, credential, and configuration handling implemented in this repo -- command-line or helper tooling shipped in this repo +A **documented Iceberg Go-owned availability boundary** is an explicit Review Comment: Every Out-of-Scope override leans on this term ('reassess if a finding violates a documented Iceberg Go-owned availability boundary'), but the only example given is the Puffin 256 MB limit. A maintainer triaging, say, an Avro decode cap or a manifest slice limit can't tell whether it's a documented and owned boundary without auditing the code first. Not a blocker, but a short non-exhaustive list of the enforced limits, or even just a pointer like 'see the puffin and table package docs', would let the rule be applied without a codebase dig. ########## SECURITY-THREAT-MODEL.md: ########## @@ -19,205 +19,461 @@ # Apache Iceberg Go Security Threat Model -This document describes the detailed security threat model for Apache -Iceberg Go. It is intended for maintainers and automated security triage. +## Status and Reporting + +This document is detailed guidance for Apache Iceberg Go maintainers and +automated security triage. It describes classification defaults and the +evidence needed to raise confidence; it does not replace case-by-case review by +the project or the Apache Security Team. + +Possible vulnerabilities must be reported privately through the Apache Security +Team process. This document guides classification and scanner confidence; it +does not authorize public disclosure and does not automatically accept or +reject a report. + +Follow the [Apache Iceberg security model](https://iceberg.apache.org/security/) +and the [Apache security vulnerability reporting +process](https://www.apache.org/security/). Send undisclosed Iceberg reports to +`[email protected]`; the Apache Security Team's +`[email protected]` address remains a private fallback. Do not open a public +issue for a possible undisclosed vulnerability. ## Purpose -Apache Iceberg Go is primarily a client library and implementation of the -Iceberg table format and catalog interactions for Go applications and services. -It is typically embedded in larger systems that provide their own -authentication, authorization, and credential management. Because of that -deployment model, not every unsafe or surprising behavior is a security -vulnerability in Iceberg Go itself. +Apache Iceberg Go is a client library, table-format implementation, catalog +client, and command-line tool. It is commonly embedded in applications and +services that supply their own authorization, credential management, and +storage policy. -This model is intended to answer: +This threat model helps a reviewer describe: -- what Iceberg Go generally treats as a security vulnerability -- what Iceberg Go generally treats as correctness, hardening, or deployment - work -- which boundaries are primarily owned by Iceberg Go versus the surrounding - catalog, application, or service -- which issue classes should be downgraded by default by scanners +- the actor and the capability the actor already has; +- the input or service the actor controls; +- the Iceberg Go-owned or external boundary affected; +- any secret or credential that reaches a new audience; and +- demonstrated confidentiality, integrity, availability, memory, or + destructive impact. -## Scope +The categories below are conditional triage defaults, not blanket rejection +rules. A finding that crosses an Iceberg Go-owned boundary or demonstrates a +security impact must be reviewed even when it also has a normally trusted +precondition. -This model is scoped to the Apache Iceberg Go repository itself: +In this document, a **new audience** is any log, error, CLI text or JSON output, +serialized metadata, host, catalog or client, or principal that was not already +authorized to receive the secret, credential, or credential-bearing request. -- table format and metadata handling -- catalog and REST catalog clients -- transport, credential, and configuration handling implemented in this repo -- command-line or helper tooling shipped in this repo +A **documented Iceberg Go-owned availability boundary** is an explicit +project-owned resource limit that Iceberg Go documents and enforces, such as +the Puffin reader's configured maximum blob size (256 MB by default). It is not +a general availability guarantee for an embedding service. -It is not a general threat model for every Go service that embeds Iceberg Go. +## Scope + +This model covers Iceberg Go-owned behavior in: -In particular, it does not attempt to define the complete security model for: +- the Go library and CLI; +- catalog implementations and REST catalog clients; +- configuration, HTTP transport, authentication, request signing, metrics, and + delegated storage credentials; +- table metadata, manifests, data-file planning, deletion vectors, and Puffin + files; and +- built-in and registered IO adapters, including local filesystem operations. -- applications or services that embed Iceberg Go -- storage-level authorization enforced outside Iceberg Go +It is not a complete threat model for every process or deployment that embeds +Iceberg Go. Application user authorization, provider IAM, storage ACLs, +catalog-side credential scope, and embedding-application tenant isolation are +external enforcement points unless Iceberg Go explicitly takes ownership of a +more specific boundary. ## Security Goals Iceberg Go should: -- avoid exposing secrets or delegated credentials to principals that were not - already trusted with them -- avoid creating new unauthorized capabilities in Iceberg Go-owned components -- avoid violating trust boundaries that Iceberg Go itself owns, such as - leaking auth, transport, or credential-bearing state across catalog or - client boundaries in the same process - -Iceberg Go does not aim to be the primary enforcement point for: - -- user-to-user authorization inside the embedding application -- storage-level authorization -- service-side credential scoping performed by an external catalog +- prevent tokens, client secrets, storage credentials, signed requests, and + credential-bearing configuration from reaching a new audience; +- preserve per-catalog and per-client authentication and credential isolation + for state Iceberg Go creates, including internally managed auth, transport, + metrics, and delegated-credential state; +- avoid creating network, signing, storage, or destructive capabilities that + the configured principal did not authorize; +- preserve documented Iceberg Go-owned availability boundaries by enforcing + their explicit resource limits; +- avoid attacker-observable memory disclosure or memory corruption in direct + or transitive native or `unsafe` behavior; and +- avoid deleting or mutating objects beyond the actor's proven table, + warehouse, catalog, or storage capability. + +Iceberg Go is not the primary enforcement point for application user +authorization, provider IAM, storage ACLs, catalog-side credential scope, or +tenant isolation in the embedding application. Those external responsibilities +do not waive the Iceberg Go-owned isolation and routing goals above. ## Roles ### Operator -The operator configures the surrounding catalog, application, service, and -storage integration around Iceberg Go. This role is trusted to choose -endpoints, warehouses, storage integrations, and credentials. +The operator chooses catalog properties, initial endpoints, warehouse and +storage roots, transports, TLS and proxy settings, and credentials. Those +choices are trusted deployment inputs. An operator may also deliberately +install plugins or share objects between clients. ### Catalog control plane -The catalog control plane resolves tables and supplies metadata, locations, -configuration, and delegated credentials to Iceberg Go. It may be implemented -by a REST catalog server or another catalog implementation. Iceberg Go assumes -this control plane is trusted and outside its primary security boundary. +The selected catalog resolves tables and may supply metadata, locations, +configuration, endpoint capabilities, and delegated storage credentials. The +catalog is normally trusted for those control-plane choices, but that trust +does not authorize Iceberg Go to send credentials to an unintended audience or +to cross a separate client boundary. ### REST catalog client -The REST catalog client consumes catalog-provided metadata, configuration, and -credentials. Client-side bugs in routing, caching, or reuse may still be -security-relevant if they leak credential-bearing state across boundaries that -the Iceberg Go client is expected to preserve. +The REST client applies operator and catalog configuration, constructs +catalog-local sessions, routes OAuth and catalog requests, optionally signs +requests with SigV4, negotiates advertised endpoints, and selects +prefix-matching vended credentials for storage IO. Client-owned routing, +selection, caching, or reuse bugs are in scope when they create a new audience, +cross a separately constructed catalog or client, or add an unauthorized +capability. ### Embedding application -Applications and services embedding Iceberg Go are responsible for their own -user-facing authorization boundaries unless Iceberg Go explicitly documents -otherwise. +The embedding application decides which users may invoke Iceberg Go and owns +its user and tenant boundaries. It may intentionally share an `AuthManager`, +custom transport, database handle or implementation, registry implementation, +or other mutable dependency. +Such deliberate sharing is caller-owned; Iceberg Go-created state that crosses +otherwise separate catalog or client instances is not. ### Table writer or maintainer -This role may already have legitimate power to write or replace table -metadata, write or delete files, choose paths under an allowed warehouse or -table location, and invoke destructive maintenance operations. If a report -only shows a new way to achieve the same effect this role can already cause -legitimately, it is usually not a security issue in Iceberg Go. +A writer or maintainer may be authorized to replace metadata, add or remove +table references, write files, and invoke maintenance operations. A reviewer +must establish the actor's actual capability, the affected objects, and the +audience before treating a new path as equivalent to an authorized operation. + +### CLI operator + +The CLI is an operator-authorized client, not a privilege boundary. +Confirmations, `--yes`, and dry-run behavior are safety UX. Destructive +commands execute with the caller's catalog and storage authority; the CLI does +not add a separate authorization layer. ## Trust Boundaries ### Boundary 1: operator-trusted configuration -The following are generally treated as trusted operator or deployment inputs: +Catalog properties, initial endpoints, warehouse and storage roots, custom +transports, TLS configuration, proxy settings, and credentials are +operator-trusted deployment inputs. A finding that requires direct control of +those values normally has a trusted-input precondition and therefore lower +confidence. + +That downgrade does not apply when Iceberg Go exposes a secret to a new +audience, reuses state across a separately constructed catalog or client, +bypasses an operator-selected restriction, causes attacker-observable memory +impact, or performs an unauthorized mutation or deletion. + +### Boundary 2: catalog-supplied metadata and locations + +The selected catalog is trusted to provide table metadata, table and file +locations, table properties, manifests, data-file references, statistics, and +other control-plane information. Iceberg Go follows those values to construct +IO and table operations; it does not impose a universal table-root sandbox. + +Incorrect or malicious catalog-supplied content is normally a trusted-input or +robustness precondition. It remains security-relevant when processing it +discloses a secret, crosses client state, creates an unauthorized capability, +causes attacker-observable memory disclosure or corruption, or deletes or +mutates objects beyond the actor's proven authority. + +### Boundary 3: REST configuration, routing, and delegated storage access + +The selected REST catalog is trusted to supply metadata, locations, +`/v1/config` defaults and overrides, endpoint capability advertisements, and +vended storage credentials. Configuration merging may change the effective +REST base URI, OAuth route, catalog prefix, and other client properties. +Advertised capabilities select REST operations, while location-prefix matching +selects vended credentials used to construct storage IO. + +A malicious control plane is normally a trusted-input precondition, but that +precondition does not dismiss a client bug that forwards a credential to a new +host, creates an unexpected outbound request, crosses a separately constructed +catalog/client boundary, or bypasses an operator-selected restriction. + +OAuth routing, SigV4 signing, endpoint selection, and delegated-credential +selection therefore require impact-based review. The mere presence of a +configurable endpoint, server override, advertised endpoint, or vended +credential is not by itself a vulnerability. -- catalog properties -- endpoint configuration -- warehouse and storage roots -- transport wiring and credential configuration +### Boundary 4: storage-level authorization -If a report depends on the attacker controlling those values directly, it is -usually not a vulnerability in Iceberg Go itself. +Storage providers enforce object permissions through provider IAM, storage +ACLs, and the credentials made available to Iceberg Go. Catalog-side credential +scope is also an external enforcement point. -### Boundary 2: catalog-supplied metadata +A storage operation that is already authorized against the same objects is +normally not a new Iceberg Go capability. A client bug remains in scope if it +misroutes credentials, expands their effective use, crosses client state, or +deletes or mutates objects outside the actor's proven storage capability. -Iceberg Go often accepts metadata locations, table properties, namespace -properties, and related control-plane information from a catalog. By default, -Iceberg Go treats those sources as trusted. +### Boundary 5: Iceberg Go-owned client state -This means a malicious catalog supplying incorrect or malicious metadata is -usually not an Iceberg Go vulnerability by itself. +Iceberg Go internally creates REST sessions and per-catalog authentication, +transport, metrics, and delegated-credential state. Separately constructed Review Comment: Small inconsistency worth resolving: 'metrics' is listed here (and in Security Goals) as Iceberg Go-owned state that separately constructed catalogs must not share, but Out-of-Scope 6 says sharing a registry implementation is caller-owned and not a security issue. An app that deliberately shares a `metrics.Registry` across two catalogs lands in both buckets at once, so a maintainer could reach opposite conclusions depending on which section they read first. Metrics also aren't usually credential-bearing, so either dropping 'metrics' from the isolation set here, or a sentence on why cross-catalog metric aggregation is security-relevant, would settle it. Non-blocking. ########## SECURITY-THREAT-MODEL.md: ########## @@ -19,205 +19,461 @@ # Apache Iceberg Go Security Threat Model -This document describes the detailed security threat model for Apache -Iceberg Go. It is intended for maintainers and automated security triage. +## Status and Reporting + +This document is detailed guidance for Apache Iceberg Go maintainers and +automated security triage. It describes classification defaults and the +evidence needed to raise confidence; it does not replace case-by-case review by +the project or the Apache Security Team. + +Possible vulnerabilities must be reported privately through the Apache Security +Team process. This document guides classification and scanner confidence; it +does not authorize public disclosure and does not automatically accept or +reject a report. + +Follow the [Apache Iceberg security model](https://iceberg.apache.org/security/) +and the [Apache security vulnerability reporting +process](https://www.apache.org/security/). Send undisclosed Iceberg reports to +`[email protected]`; the Apache Security Team's +`[email protected]` address remains a private fallback. Do not open a public +issue for a possible undisclosed vulnerability. ## Purpose -Apache Iceberg Go is primarily a client library and implementation of the -Iceberg table format and catalog interactions for Go applications and services. -It is typically embedded in larger systems that provide their own -authentication, authorization, and credential management. Because of that -deployment model, not every unsafe or surprising behavior is a security -vulnerability in Iceberg Go itself. +Apache Iceberg Go is a client library, table-format implementation, catalog +client, and command-line tool. It is commonly embedded in applications and +services that supply their own authorization, credential management, and +storage policy. -This model is intended to answer: +This threat model helps a reviewer describe: -- what Iceberg Go generally treats as a security vulnerability -- what Iceberg Go generally treats as correctness, hardening, or deployment - work -- which boundaries are primarily owned by Iceberg Go versus the surrounding - catalog, application, or service -- which issue classes should be downgraded by default by scanners +- the actor and the capability the actor already has; +- the input or service the actor controls; +- the Iceberg Go-owned or external boundary affected; +- any secret or credential that reaches a new audience; and +- demonstrated confidentiality, integrity, availability, memory, or + destructive impact. -## Scope +The categories below are conditional triage defaults, not blanket rejection +rules. A finding that crosses an Iceberg Go-owned boundary or demonstrates a +security impact must be reviewed even when it also has a normally trusted +precondition. -This model is scoped to the Apache Iceberg Go repository itself: +In this document, a **new audience** is any log, error, CLI text or JSON output, Review Comment: These two terms, 'new audience' here and 'documented Iceberg Go-owned availability boundary' just below, end up governing almost every Boundary, In-Scope, and Out-of-Scope entry, but they're defined inside the Purpose prose. Someone landing directly on Boundary 3 or Out-of-Scope 7 (which the doc itself says is a real access pattern for maintainers and scanners) hits them with no definition in view. Not blocking, but I think a short Definitions section right before Trust Boundaries would make the governing terms much easier to find. wdyt? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
