T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:289
- Finding
- Overly Broad Directory Permissions and Unnecessary Administrator Execution## Vulnerability Details **File Location**: `SKILL.md`, lines 289-299 **Vulnerability Type**: Excessive filesystem permissions and privilege escalation **Risk Level**: Medium ### Vulnerable Code ```powershell # Method 1: Modify folder permissions icacls "D:\YourFolder" /grant Users:F # Method 2: Run OpenClaw as administrator # Right-click PowerShell → Run as administrator ``` ```text **Windows (GUI)**: 1. Right-click target folder → Properties 2. Security → Edit 3. Add → Enter your username → Check Names 4. Check "Full control" → OK ``` ### Technical Analysis The permission-recovery instructions recommend granting the Windows `Users` group full control over the destination directory through `Users:F`. This applies the permission to a broad group rather than limiting access to the current user or the specific process responsible for project generation. Full control includes the ability to read, create, modify, and delete files and to alter directory permissions. Consequently, another local account or a process operating under another user context may be able to tamper with generated source code, dependency manifests, build configuration, application configuration, or executable scripts. The alternative recommendation to run OpenClaw as an administrator also violates the principle of least privilege. Project generation ordinarily requires write access only to a dedicated project directory. Elevating the entire Agent gives its subsequent filesystem operations, generated commands, and invoked tools administrative privileges beyond those legitimately required by the task. ### Attack Path 1. Project generation fails because the selected destination is not writable. 2. The user follows the Skill instructions and either grants `Users:F` to the project directory or launches OpenClaw as an administrator. 3. In the broad-permission scenario, another local user or compromised process modifies pr ...[truncated 1234 chars]
- Remediation
- ## Remediation Suggestions 1. Remove administrator execution as a routine solution for destination-directory write failures. 2. Prefer the documented fallback that generates the project inside a user-owned workspace. 3. Grant access only to the current user, only on a dedicated project directory, and only with the permissions needed to create and modify project files. 4. Replace the broad Windows command with a narrowly scoped command such as: ```powershell icacls "D:\Target\Project" /grant "$env:USERNAME:(OI)(CI)M" ``` `M` grants modify access rather than full control, while `(OI)(CI)` applies the permission to files and subdirectories. 5. Validate and display the canonical destination path before changing permissions. Reject system directories, existing sensitive directories, path roots, and paths containing unexpected traversal components. 6. Do not recommend granting access to generic groups such as `Users` or `Everyone`. 7. If elevation is exceptionally necessary, isolate the single permission-management operation rather than running the entire Agent with administrative privileges. 8. Add a warning that users should not recursively change permissions or ownership on existing workspace roots, home directories, or operating-system directories.