Skip to content

Latest commit

 

History

History
53 lines (44 loc) · 6.12 KB

threat-modeling.md

File metadata and controls

53 lines (44 loc) · 6.12 KB

Threat Model Analysis for google/leveldb

Threat: Data Corruption due to Uncontrolled Shutdown

  • Description: An attacker might intentionally trigger a system crash (e.g., power failure, kernel panic) or exploit another vulnerability to force an unclean shutdown while the application is writing to LevelDB. LevelDB uses a write-ahead log (WAL) and memtables, but incomplete writes during a crash can lead to inconsistencies.
    • Impact: Loss of recently written data; potential corruption of the database, requiring recovery or leading to application malfunction. Inconsistent data may lead to incorrect application behavior.
    • Affected LevelDB Component: WAL (Write-Ahead Log), Memtable, SSTables (Sorted String Tables). The core data storage and recovery mechanisms.
    • Risk Severity: High
    • Mitigation Strategies:
      • Application-Level Checksums: Calculate and store checksums (e.g., CRC32, SHA-256) of data before writing to LevelDB and verify them after reading. This detects corruption.
      • Robust Error Handling: Thoroughly check leveldb::Status return values for all LevelDB operations (Put, Get, Delete, Iterator operations). Handle errors gracefully, logging them and potentially attempting recovery.
      • Filesystem Integrity: Use a journaling filesystem (e.g., ext4, XFS, NTFS) to reduce the risk of filesystem-level corruption.
      • Regular Backups: Implement a robust backup strategy to allow restoration of data in case of corruption.
      • Application-Level Transactions (if needed): If atomic multi-key updates are critical, consider implementing a transaction layer above LevelDB (since LevelDB itself only provides atomic single-key operations and batch writes). This might involve a separate WAL at the application level.
      • Graceful Shutdown Handling: Implement signal handlers (e.g., SIGTERM, SIGINT) to gracefully shut down the application, ensuring LevelDB has a chance to flush data to disk.

Threat: Data Leakage via File Permissions

  • Description: An attacker with local access to the system (or through a separate vulnerability) might attempt to read the LevelDB data files directly if the file permissions are too permissive.
    • Impact: Exposure of sensitive data stored in the database, potentially leading to privacy breaches or further attacks.
    • Affected LevelDB Component: SSTables (Sorted String Tables), Manifest files, Log files – the files on disk that store the database data and metadata.
    • Risk Severity: High (if sensitive data is stored unencrypted)
    • Mitigation Strategies:
      • Strict File Permissions: Ensure the LevelDB data directory and all files within it have the most restrictive permissions possible. Only the user account running the application should have read/write access. Use chmod (on Linux/macOS) or equivalent tools to set appropriate permissions.
      • Data Encryption at Rest: Encrypt sensitive data before storing it in LevelDB. Use a strong encryption algorithm (e.g., AES-256) and securely manage the encryption keys. This is the most important mitigation.
      • Directory Traversal Prevention: Validate all user inputs that might be used to construct file paths, preventing attackers from accessing files outside the intended directory.

Threat: Data Tampering via Direct File Modification

  • Description: An attacker with local access (or through a separate vulnerability) could directly modify the LevelDB data files (SSTables, etc.), bypassing application-level controls.
    • Impact: Data integrity violation. The application may behave incorrectly due to the tampered data, potentially leading to security vulnerabilities or data corruption.
    • Affected LevelDB Component: SSTables (Sorted String Tables), Manifest files.
    • Risk Severity: High
    • Mitigation Strategies:
      • Data Encryption at Rest: Encrypting the data before storing it in LevelDB makes it much harder for an attacker to modify the data meaningfully.
      • Application-Level Integrity Checks: Calculate and store cryptographic hashes (e.g., SHA-256) or digital signatures of data before writing to LevelDB. Verify these hashes/signatures after reading from LevelDB to detect tampering.
      • Strict File Permissions: As with data leakage, ensure restrictive file permissions.

Threat: Concurrent Access Violation

  • Description: Multiple processes, or unsynchronized threads within the same process, attempt to access the same LevelDB database concurrently without proper locking. LevelDB provides internal locking for single process, multi-threaded access, but it does not handle inter-process concurrency.
    • Impact: Data corruption, unpredictable behavior, crashes.
    • Affected LevelDB Component: All components. The entire database is at risk.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Single Process Access: Ideally, design the application so that only a single process accesses the LevelDB database at any given time.
      • External Locking (if multiple processes are required): If multiple processes must access the same LevelDB database, use a robust external locking mechanism, such as:
        • File locks (e.g., flock on Linux).
        • System-level semaphores.
        • A dedicated lock server.
      • Thorough Testing: Rigorously test concurrent access scenarios to ensure the locking mechanism is working correctly.
      • LevelDB's Built-in Locking (for threads within a single process): Ensure that if multiple threads within the same process are accessing LevelDB, you are relying on LevelDB's internal locking and not introducing your own, potentially conflicting, locking mechanisms. LevelDB is thread-safe within a single process, provided you don't disable its internal locking.