Security Proposal: Protecting non-technical users during installation (Privilege Escalation & Docker Risks)

[AnnoDomine]

Hi everyone, and thanks to the maintainers for building such a massive and feature-rich AI workspace. Bringing local, privacy-first AI to a broader audience is a fantastic goal.
Given the origin of this project and its massive reach, a significant portion of the user base likely consists of everyday users who may not fully understand the security implications of running system-level commands. Because of this, I wanted to raise a critical discussion regarding the current installation practices and propose some immediate safety guardrails.
Currently, the setup process uses a few "fast-path" methods that unintentionally open up users' machines to severe security risks, especially if a malicious PR slips through or a supply chain attack occurs.
The Core Security Concerns
Windows Execution Policy Bypass: The command powershell -ExecutionPolicy Bypass -File .\launch-windows.ps1 completely disables Windows script execution protections for that session. For an average user, this removes a vital OS-level safety net.
Root / Admin Requirements: The Linux setup (scripts/check-docker-gpu.sh) and the Python setup script request sudo or Admin privileges. Running complex, remotely cloned scripts with root privileges is highly risky.
Supply Chain Risks: Running pip install -r requirements.txt without pinned package hashes makes the thousands of users a prime target for dependency spoofing.
Docker Host Access: Providing a Docker container with direct GPU passthrough, host network binding (0.0.0.0), and mounted volumes essentially breaks container isolation. If the container is compromised, the host is compromised.
Proposed Immediate Actions
To protect the community, we should prioritize transparency and explicit user consent over a one-click installation. I'd like to propose two immediate additions:

1. A Prominent Security Disclaimer in the README
   Before the installation steps, we need a clear, plain-English warning explaining what the installation actually does to the system (e.g., "This installation requires administrator privileges, modifies system execution policies, and grants the application deep access to your hardware. Please do not run these scripts unless you trust this repository.").
2. Mandatory Consent Prompts in Installation Scripts
   No script should elevate privileges or bypass execution policies automatically. The scripts should pause and explicitly prompt the user for consent. For example:
   Warning: This script needs to temporarily bypass Windows Execution Policies and requires Administrator rights to configure your GPU. Do you understand the risks and wish to proceed? [y/N]
   Moving Forward
   In the long run, implementing pinned dependency hashes, exploring RemoteSigned execution instead of Bypass, and enforcing a stricter review policy for installation-related PRs would solidify the project's foundation.
   I'd love to hear the maintainers' thoughts on this. Ensuring the code works is step one, but ensuring it doesn't accidentally compromise a user's daily driver PC needs to be part of the baseline.

Translated with Gemini

[WGlynn]

The proposal lists the right fixes, but most of them sit at one layer of the safety stack. A useful framing from mechanism-design might help organize them into something maintainers can ratify once and apply consistently.

Three layers of install-time safety, each with different change-budgets:

Layer 1: physics. Invariants the install path must satisfy unconditionally, regardless of platform or convenience tradeoff. Examples: no install path executes arbitrary remote code without surfacing what it's about to do; no install path silently weakens OS-level protections without explicit user acknowledgment. These aren't best-practices; they're the floor below which the install is structurally broken. A PR that removes one is invalid by construction, not by review-judgment.

Layer 2: constitution. Invariants the project has chosen but can be governance-modified through an explicit process. Examples: pinned dependency hashes; specific Docker privilege limits; default execution policy. Stricter than physics but not absolute. A future PR can argue to change them and there's a defined review path. The current README operates implicitly at this layer; making it explicit lets reviewers know which changes need governance-level scrutiny versus ordinary PR review.

Layer 3: governance. Best-practices and advisory measures that respond to context. Examples: consent prompts on specific operations; security disclaimers; per-platform install variants. PR-reviewable in the normal flow.

The "fast-path" risks the OP describes mostly live at layer 1 right now without being labeled as such. A PowerShell bypass, root requirement for remote scripts, GPU-passthrough with default network binding. Those feel like they ought to be physics-floor, but a PR that introduced any of them would currently get reviewed on the same axis as a typo fix.

Concrete suggestion: a short SECURITY-INVARIANTS.md file enumerating the layer-1 invariants explicitly. Layer-2 and layer-3 stuff continues to live in README and CONTRIBUTING.md. The benefit isn't documentation for users; it's that PR review gets a clean reference for "this PR touches a physics-invariant" versus "this PR is a layer-3 nicety." Most of the OP's specific suggestions can then slot into whichever layer they belong to, and disagreements about strictness become disagreements about which layer something belongs to rather than whether to do it at all.

ryslan25500-cloud's hardware concerns and the OP's install concerns are arguably the same shape of problem at different attack surfaces. A constitutional layer for both would make the project's safety posture legible without requiring every PR reviewer to re-derive what's actually mandatory.

[CoolJohn-lab]

They are the same person. He’s a weirdo going round opening up fake issues and backing himself up on his alt account.

[WGlynn]

lol wuttt

[AnnoDomine]

The proposal lists the right fixes, but most of them sit at one layer of the safety stack. A useful framing from mechanism-design might help organize them into something maintainers can ratify once and apply consistently.

Three layers of install-time safety, each with different change-budgets:

Layer 1: physics. Invariants the install path must satisfy unconditionally, regardless of platform or convenience tradeoff. Examples: no install path executes arbitrary remote code without surfacing what it's about to do; no install path silently weakens OS-level protections without explicit user acknowledgment. These aren't best-practices; they're the floor below which the install is structurally broken. A PR that removes one is invalid by construction, not by review-judgment.

Layer 2: constitution. Invariants the project has chosen but can be governance-modified through an explicit process. Examples: pinned dependency hashes; specific Docker privilege limits; default execution policy. Stricter than physics but not absolute. A future PR can argue to change them and there's a defined review path. The current README operates implicitly at this layer; making it explicit lets reviewers know which changes need governance-level scrutiny versus ordinary PR review.

Layer 3: governance. Best-practices and advisory measures that respond to context. Examples: consent prompts on specific operations; security disclaimers; per-platform install variants. PR-reviewable in the normal flow.

The "fast-path" risks the OP describes mostly live at layer 1 right now without being labeled as such. A PowerShell bypass, root requirement for remote scripts, GPU-passthrough with default network binding. Those feel like they ought to be physics-floor, but a PR that introduced any of them would currently get reviewed on the same axis as a typo fix.

Concrete suggestion: a short SECURITY-INVARIANTS.md file enumerating the layer-1 invariants explicitly. Layer-2 and layer-3 stuff continues to live in README and CONTRIBUTING.md. The benefit isn't documentation for users; it's that PR review gets a clean reference for "this PR touches a physics-invariant" versus "this PR is a layer-3 nicety." Most of the OP's specific suggestions can then slot into whichever layer they belong to, and disagreements about strictness become disagreements about which layer something belongs to rather than whether to do it at all.

ryslan25500-cloud's hardware concerns and the OP's install concerns are arguably the same shape of problem at different attack surfaces. A constitutional layer for both would make the project's safety posture legible without requiring every PR reviewer to re-derive what's actually mandatory.

Good points. I personal like them :)
And yeah. 1 single PR with > lets say 5000 lines of changes will be easily overseen vulnarity or in the worst scenario attacks. Not even an AI can recognize them because of the token window size.