Security Model

Security Model

Bull hardens every VM it creates with a set of technical controls. This page explains what those controls are, what they protect against, and — just as importantly — what they do not.

What Bull does

Control	Implementation
Credential encryption	Passwords encrypted with GPG (AES256 + SHA512, 65M S2K iterations), stored in .credentials.gpg. Never written in plaintext.
In-memory only plaintext	The password exists in memory during provisioning and is wiped from environment variables right after use.
Encrypted home	/home inside the VM is encrypted with ecryptfs.
Locked default accounts	The distro's default OS accounts are locked after provisioning.
No host exposure	Vagrant synced folders are disabled — the VM cannot reach the host filesystem.
VPN kill switch	iptables drops all non-VPN traffic, so a dropped tunnel does not leak to the clear net. See VPN and Kill Switch.
Input validation	VM names, toolkit names, and toolkit URLs are validated; URLs are rejected if they contain shell metacharacters, preventing injection via vagrant ssh -c.
Tightened permissions	The Vagrantfile (which briefly holds the provisioning password) is chmod 600 and sanitized afterward; credential files are chmod 600; the GPG home is chmod 700.
Run-as-root guard	Bull refuses to run without root, since it manages the hypervisor, iptables, and encrypted storage.

Password handling

When you do not supply a password, Bull generates a 24-character random one with openssl and stores it encrypted. Prefer --password-file over --password: the file is read once and then wiped, whereas --password is visible in ps aux while the process runs. Retrieve a stored password with bull show-pass <name>.

Legacy VMs that predate GPG encryption may have a plaintext .credentials file. Bull warns about these and recommends recreating the VM.

What Bull does not protect against

These are technical measures only. They do not protect against:

• User error — pasting secrets into the wrong window, mishandling outputs, weak custom passwords.
• Social engineering.
• Vulnerabilities in the underlying tools — Vagrant, VirtualBox, libvirt, Kali, or Parrot themselves.
• A compromised host — Bull runs as root on your machine; if the host is owned, so is Bull.
• Provider trust — the kill switch enforces routing, but it cannot verify a VPN provider's no-log claims.

Scope of security reports

Bull is a wrapper around Vagrant and a hypervisor. Security reports should concern vulnerabilities in Bull itself — for example command injection via toolkit URLs, credential leaks, or privilege-escalation flaws in the wrapper logic. Vulnerabilities in the underlying tools belong to their respective maintainers.

Reporting a vulnerability

Do not open a public issue for security vulnerabilities. Instead:

1. GitHub Security Advisories (preferred): go to Security → Advisories and click "Report a vulnerability".
2. Email: contact the maintainer via the email on their GitHub profile.

You should receive an acknowledgment within 48 hours, and a fix will be coordinated privately before public disclosure. The canonical policy is SECURITY.md.