GuestKit is designed for disk image inspection and manipulation. When using this tool:

1. Untrusted Disk Images: Exercise caution when processing disk images from untrusted sources

   • Malicious disk images could potentially exploit vulnerabilities in parsing code
   • Run GuestKit in isolated environments when processing untrusted images
   • Consider using containers or VMs for additional isolation

2. Privilege Requirements: Some operations require elevated privileges

   • NBD mounting may require root or appropriate capabilities
   • LUKS operations require access to /dev/mapper
   • LVM operations require access to device mapper

3. Data Integrity: Always work on copies of important data

   • GuestKit can modify disk images
   • Use read-only mode when inspection is the only goal
   • Keep backups of critical data

When using add_drive_ro(), the following operations are safe:

• Disk format detection
• Partition table reading
• Filesystem inspection
• OS detection
• File reading (when mounted read-only)
• Package listing
• Configuration inspection

The following operations modify data and should be used carefully:

• write(), write_append() - Modify files
• mkfs() - Destroys existing filesystem data
• part_del() - Deletes partitions
• luks_format() - Destroys existing encryption
• lvcreate(), lvremove() - Modifies LVM configuration
• dd(), zero_device() - Overwrites device data

GuestKit performs basic input validation but relies on underlying tools for detailed validation:

1. Path Traversal: Guest paths are resolved but may still access unexpected locations
2. Device Names: Device names are passed to system commands - validate externally if from untrusted sources
3. Command Injection: Arguments to guest commands should be sanitized by callers

• Passwords/keys are passed as command-line arguments to cryptsetup
  • Keys may be visible in process lists temporarily
  • Consider using key files instead of passwords in production
• LUKS operations require appropriate privileges

// DO: Use read-only mode for inspection
g.add_drive_ro("/path/to/untrusted.img")?;

// DON'T: Write mode on untrusted images
g.add_drive_opts("/path/to/untrusted.img", None, false)?; // risky!

// DO: Validate paths before use
let path = user_input.trim();
if path.contains("..") || !path.starts_with("/") {
    return Err("Invalid path".into());
}

// DO: Use timeouts for operations
use std::time::Duration;
// Future: g.set_timeout(Duration::from_secs(30))?;

Please do NOT report security vulnerabilities through public GitHub issues.

Instead, please send a report to:

• Email: ssahani@redhat.com
• Subject: "[SECURITY] GuestKit Vulnerability Report"

Please include the following information:

1. Description: Brief description of the vulnerability
2. Impact: Potential impact and severity assessment
3. Reproduction: Step-by-step instructions to reproduce
4. Affected Versions: Which versions are affected
5. Suggested Fix: If you have one (optional)
6. Disclosure Timeline: Your expected disclosure timeline

Subject: [SECURITY] GuestKit Vulnerability Report

Description:
Command injection vulnerability in xyz() function when processing
untrusted device names.

Impact:
An attacker with control over device names could execute arbitrary
commands with the privileges of the GuestKit process.

Affected Versions:
0.2.0 and earlier

Reproduction:
1. Create malicious device name: `"; rm -rf / #"`
2. Call g.some_function() with this device name
3. Observe command execution

Suggested Fix:
Add shell escaping for device names before passing to Command::new()

Disclosure Timeline:
Requesting 90 days for fix before public disclosure

• Initial Response: Within 48 hours
• Assessment: Within 1 week
• Fix Development: Depends on severity
  • Critical: 7 days
  • High: 14 days
  • Medium: 30 days
  • Low: 60 days
• Public Disclosure: After fix is released

We follow a coordinated disclosure process:

1. Private Report: Vulnerability reported privately
2. Acknowledgment: We acknowledge receipt within 48 hours
3. Investigation: We assess severity and impact
4. Fix Development: We develop and test a fix
5. Release: We release a patched version
6. Public Disclosure: We publish security advisory
7. Credit: We credit the reporter (if desired)

Published security advisories will be available at:

• GitHub Security Advisories
• CHANGELOG.md with [SECURITY] tags
• Release notes

• Written in pure Rust (except external tool calls)
• No unsafe code in core library
• Bounds checking on all array/slice access
• Protection against common memory errors (use-after-free, double-free, buffer overflows)

GuestKit executes external commands for some operations:

• Uses std::process::Command for safe command execution
• Arguments are properly separated (no shell parsing)
• Output is captured and parsed safely

• Core library runs with user privileges
• External tools (qemu-nbd, cryptsetup, lvm) may require elevation
• Users should apply principle of least privilege

1. Verify Checksums: Verify package checksums before installation

   sha256sum target/release/guestkit

2. Use Read-Only Mode: When possible, use read-only mode

   g.add_drive_ro(disk_path)?;

3. Validate Input: Always validate untrusted input

   fn safe_read_file(g: &mut Guestfs, path: &str) -> Result<String> {
       // Validate path
       if !path.starts_with("/") || path.contains("..") {
           return Err("Invalid path".into());
       }
       g.cat(path)
   }

4. Limit Privileges: Run with minimum required privileges

   # Use capabilities instead of full root
   sudo setcap cap_sys_admin+ep target/release/guestkit

5. Isolate Workloads: Process untrusted images in containers

   podman run --rm -it \
       --device /dev/nbd0 \
       -v /path/to/images:/images:ro \
       guestkit inspect /images/untrusted.qcow2

1. Input Sanitization: Always sanitize user input

   // Bad
   g.command(&[&format!("cat {}", user_input)])?;
   
   // Good
   g.cat(&validate_path(user_input)?)?;

2. Error Messages: Don't leak sensitive information in errors

   // Bad
   Err(format!("Failed with key: {}", secret_key))
   
   // Good
   Err("Authentication failed".into())

3. Resource Limits: Set appropriate resource limits

   // Future API
   g.set_memory_limit(512 * 1024 * 1024)?; // 512MB
   g.set_timeout(Duration::from_secs(300))?; // 5 minutes

4. Audit Logging: Log security-relevant operations

   log::info!("Opening LUKS device: {}", device);
   g.luks_open(device, key, mapname)?;

GuestKit relies on several external tools and libraries. Security of these dependencies:

• qemu-img: Disk format conversion and inspection
• qemu-nbd: NBD server for mounting
• cryptsetup: LUKS encryption
• lvm2: Logical volume management

Users should keep these tools updated via their package manager.

Dependencies are regularly audited using:

cargo audit

We strive to:

• Minimize dependencies
• Use well-maintained crates
• Regularly update dependencies
• Review dependency changes

GuestKit is licensed under LGPL-3.0-or-later, ensuring:

• Security fixes can be shared
• Modifications must be disclosed
• Commercial use is permitted

We aim to follow:

• Rust API Guidelines
• Secure coding practices
• OWASP secure coding guidelines

Security updates will be released as:

• Patch versions (0.2.x) for backward-compatible security fixes
• Minor versions (0.x.0) if security fix requires API changes

All security updates will be clearly marked in:

• Release notes
• CHANGELOG.md
• GitHub releases

For security questions that aren't vulnerabilities:

• Open a discussion on GitHub
• Email: ssahani@redhat.com

Thank you for helping keep GuestKit secure!