okumin commented on code in PR #6535: URL: https://github.com/apache/hive/pull/6535#discussion_r3541069609
########## THREAT_MODEL.md: ########## @@ -0,0 +1,402 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to you under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +# Apache Hive — Threat Model (v0 draft) + +> **Status:** v0 draft produced by the ASF Security team (Michael Scovetta +> rubric, run with Claude Opus) for the Apache Hive PMC to review, correct, +> and own. Every non-trivial claim is provenance-tagged +> *(documented)* / *(maintainer)* / *(inferred)*; the *(inferred)* tags are +> the producer's hypotheses and each has a matching question in §14. Written +> against `master`; revise on a new public-facing surface (a new server +> endpoint, auth mechanism, file format, or execution engine), not on +> internal refactors. +> +> As of the PMC's 2026-07 review, **this in-repo model is the canonical Hive +> security model**. Security information scattered across +> <https://hive.apache.org/> predates it and may be out of date; where they +> disagree, this document wins. *(maintainer — okumin, §14 Q14)* + +## §1 — Purpose and consumers + +This document describes the **implicit security contract** between Apache +Hive and its downstream operators: what Hive assumes about its environment, +what it upholds given those assumptions, what it leaves to the operator, and +which "syntactically possible" misuses fall outside the intended design. It +serves the **integrator/operator** (which threats they own) and the +**triager** (classifying a scanner/AI/CVE-style finding as valid, out of +model, or disclaimed by design — cite the section). + +## §2 — What Hive is + +Apache Hive is a **SQL data-warehouse layer over Apache Hadoop** *(documented: +README)*. The in-scope component families: + +| Component | Role | Primary surface | +| --- | --- | --- | +| **HiveServer2 (HS2)** | the SQL front door — accepts queries over a Thrift/binary or HTTP transport, authenticates the session, compiles + authorizes + executes | network (the highest-value untrusted boundary) *(inferred — §14 Q1)* | +| **Hive Metastore (HMS)** | a Thrift service holding table/partition/schema metadata + storage locations | network (intra-cluster) *(inferred — §14 Q1)* | +| **Query compiler + execution** | parse → plan → run on Tez / MapReduce / Spark; reads/writes HDFS, HBase, object stores | depends on the configured engine *(documented: README)* | +| **UDF / SerDe / file-format layer** | user-supplied or built-in functions and (de)serializers invoked during execution | in-JVM code execution *(inferred — §14 Q2)* | +| **JDBC/ODBC drivers + Beeline** | client-side connectors | client trust domain | + +Hive is **not** a standalone secured appliance: it is a clustered service +deployed behind an operator-controlled perimeter, depending on Hadoop (HDFS, +YARN), a metastore RDBMS, an external authorization provider (typically Apache +Ranger in production deployments, though SQL-standard authorization may also be +used), and a KDC for Kerberos — all treated as trusted dependencies. +*(maintainer — okumin, §14 Q3)* + +## §3 — Adversaries in and out of scope + +**In scope**: + +1. **Untrusted clients at Hive's service boundaries** — a **SQL client** + submitting statements to HiveServer2, and a **client accessing the Hive + Metastore through its supported APIs** — attempting to read/modify data + outside their authorization, or to reach the host through query features. + *(maintainer — okumin, §14 Q4)* +2. A **network MITM** on the client↔HS2 or HS2↔HMS path, **in scope when TLS + (or equivalent transport protection) is enabled**; the operator is + responsible for configuring TLS correctly. *(maintainer — okumin, §14 Q4)* +3. A **direct Metastore (HMS) client.** Some external services (e.g. Apache + Spark) connect to the Hive Metastore directly, so HMS is expected to enforce + caller authorization at the **application level** — it is not merely an + intra-cluster service shielded by a network perimeter. A client reaching HMS + outside its authorization is in-model. *(maintainer — okumin, §14 Q1.)* + +**Out of scope** *(maintainer — okumin, §14 Q5)*: + +4. **An operator with `root` / the Hadoop superuser / direct HDFS or metastore-DB + access.** Anyone who already controls the storage layer or the cluster + processes is not an adversary Hive defends against → `OUT-OF-MODEL: + adversary-not-in-scope`. +5. **A trusted authenticated admin** performing an authorized action (creating a + function, changing config, granting a role). A new path to a privilege the + principal already holds is `OUT-OF-MODEL: equivalent-harm`. +6. **Bugs in the dependencies Hive orchestrates** — Hadoop/HDFS, YARN, Tez, + the metastore RDBMS, Ranger, the KDC, the JVM. Report upstream → + `OUT-OF-MODEL: unsupported-component`. + +## §4 — Trust boundaries + +- **Client → HiveServer2** is the primary boundary. In a secure, in-model + deployment, the operator configures authentication (Kerberos / LDAP / PAM / + custom, etc.) and authorization, and statements are checked by the configured + authorizer before execution. From HS2's point of view the **SQL + text, JDBC connection properties, and session-configuration overrides are all + untrusted**; Hive rejects non-acceptable operations through the authorization + plugin or through the configured deny lists — `hive.conf.restricted.list` + (settings an untrusted user may not change), `hive.conf.locked.list`, and + `hive.conf.hidden.list` (secret values an untrusted user may not read). + *(maintainer — okumin, §14 Q6)* +- **HiveServer2 → Metastore** and **HS2 → execution engine / HDFS** are + intra-cluster boundaries. The Metastore is protected at the **application + level** (it enforces caller authorization), because external services such as + Spark talk to HMS directly (§3.3); network isolation is defense-in-depth, not + the primary control *(maintainer — okumin, §14 Q1)*. The HS2 → engine / HDFS + path is assumed inside an operator-controlled perimeter *(maintainer — okumin, §14 Q3)*. +- **`doAs` impersonation:** when enabled, HS2 executes work as the connected + end user against HDFS rather than as the Hive service principal; when + disabled, all access runs as the Hive principal and authorization is fully + delegated to the SQL-layer authorizer. Because the recommended posture uses + an authorization plugin (typically Apache Ranger), **`hive.server2.enable.doAs=false` + is the typical / expected configuration**: HS2 enforces authorization itself + rather than pushing it down to per-user HDFS permissions. *(maintainer — + okumin, §14 Q7)* + +## §5 — What Hive upholds (given §3/§4 assumptions) + +Given valid input and a secure configuration, Hive is expected to uphold the +following. **These properties are configuration-dependent** — they hold when the +operator has configured authentication, authorization, and transport protection +per §6/§8, not by default. *(maintainer — okumin, §14 Q8)* + +- **Authentication.** HiveServer2 and the Hive Metastore can require clients to + authenticate using the configured mechanism (e.g. Kerberos, LDAP), depending + on the endpoint. +- **Authorization scoping.** Requests are authorized as the authenticated Hive + session / metastore user through the configured authorization manager + (typically Apache Ranger). Decisions are scoped to Hive objects and operations + — databases, tables, partitions, columns, functions, and the relevant metadata + operations. +- **Metastore authorization.** When the Hive Metastore is directly exposed to + clients, metastore-side authorization can be enforced through + `HiveMetaStoreAuthorizer` as a pre-event listener, and metadata read/list + results can be filtered server-side via the metastore filter hook. +- **Transport protection.** HiveServer2, the Hive Metastore, and the HS2 Web UI + can protect traffic confidentiality and integrity when TLS/SSL is enabled and + correctly configured. +- **Configuration protection.** Sensitive or security-critical configuration + values can be restricted, locked, or hidden (§4/§8 deny lists) so untrusted + users cannot change security posture at runtime or read secret values. +- **Credential handling.** Secrets can be externalized through Hadoop credential + providers rather than stored in cleartext configuration files. +- **Memory safety on well-formed input** to the extent the JVM provides it; + Hive is Java, so classic memory-corruption is out of the language model. + +Hive does **not** by itself guarantee authorization for a caller who bypasses +Hive and accesses the underlying storage or metastore database directly; those +paths must be protected separately by HDFS / object-store / IAM / database +controls. *(maintainer — okumin)* + +## §6 — What Hive leaves to the operator + +*(maintainer — okumin, §14 Q9)* + +- **Transport security (TLS)** on the HS2, Metastore, and HS2 Web UI endpoints, + and the KDC / LDAP server's own security. Review Comment: ```suggestion and the KDC / LDAP server's own security. - **Choosing and configuring authentication.** Hive supports several authentication mechanisms, such as Kerberos and LDAP, depending on the endpoint. The operator is responsible for enabling appropriate authentication for all exposed endpoints; otherwise, clients may be accepted without proving an identity. ``` -- 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]
