人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载本文以仓库根目录的 SECURITY.md 为骨架系统讲解 KunLocal-first AI Agent 工作台的安全披露流程、受支持版本策略与五大安全关注范围并结合仓库源码深入剖析凭证加密、Electron 沙箱加固、POSIX 权限收敛等底层实现。读完本文你将掌握 Kun 的安全报告机制理解 OAuth 令牌、密钥文件等敏感数据在磁盘上的加密存储原理并学会从源码与测试两个层面验证项目的安全边界。一、SECURITY.md 的定位披露机制 安全边界声明SECURITY.md 是 Kun 面向安全研究者与用户的公开安全策略文档同时仓库提供了对应的中文版 SECURITY.zh-CN.md。它承担两重职责一是定义漏洞披露流程支持的版本、报告渠道、响应时间承诺二是划定安全范围哪些问题需要私下报告、哪些属于核心防护目标。这两部分共同构成项目安全的对外契约而契约背后的实现则散落在kun/src/security/、src/main/browser-security/等源码目录中下文会逐一对应展开。文档明确要求安全敏感缺陷不得通过公开 Issue 报告必须走私密渠道在修复或缓解措施可用、维护者获得合理响应时间之前不得公开披露。这是所有漏洞报告类安全策略的通用基线也与仓库中多处fail-closed故障关闭的实现哲学一致——不确定时不冒险宁可拒绝操作也不破坏既有数据。二、支持的版本最新维护分支 最新发布版本SECURITY.md 声明安全修复通常应用于默认分支上最新维护的代码并在实际可行时同步到最新发布版本旧版本可能无法收到补丁。这与仓库的发布管理实践吻合仓库根目录的 release/ 目录按release-vX.Y.Z.md组织了大量版本说明例如release-v0.2.0.md至release-v0.3.11.mdkun/src/version.ts 维护运行时版本号。这意味着如果你在生产环境使用 Kun应优先跟随最新发布版本安全研究者应以默认分支main的最新提交为评估基线历史版本的安全修复不保证回填升级是获得修复的主要途径。三、报告漏洞私密渠道与必备要素3.1 报告渠道渠道说明邮件zhongxingyuemailgmail.comGitHub Security Advisories若仓库启用了私有漏洞报告流程可走该入口文档同时要求请勿针对安全敏感问题公开 GitHub Issue避免漏洞细节在修复前被滥用。3.2 建议附带的报告要素SECURITY.md 明确列出的要素如下逐条附上为什么有用的解读问题清晰描述——帮助维护者快速定位缺陷类型是逻辑错误、越权、还是信息泄露受影响的版本、commit 或 release tag——仓库以 release/ 下的版本号和 Git 提交为追踪单位精确到版本/提交可大幅加速分诊复现步骤或概念证明PoC——可复现性是分诊与回归测试的前提影响评估——如是否可远程触发、是否需要认证、影响的数据范围等任何建议的缓解措施——包括临时规避方案与修复思路。这些要素对应源码仓库中的实际测试风格kun/src/security/secret-store.test.ts中的每个用例都围绕一个明确场景展开如OS credential store disabled 时仍可加密/解密报告人若能提供同样的最小化场景维护者即可直接映射到测试矩阵。四、响应承诺3 个工作日确认SECURITY.md 给出了明确的响应时间线3 个工作日内确认新报告确认问题是否在范围内in scope分诊triage过程中持续告知报告人进展尽快负责任地发布修复或缓解措施。五、安全范围五大风险类别与仓库实现对照SECURITY.md 列出的报告范围恰好与仓库源码中的安全实现一一对应。下表给出范围条目与实现证据的映射随后逐项展开。范围条目对应实现证据远程代码执行 / 权限提升Electron 渲染层加固web-contents-hardening.ts不安全文件访问 / 沙箱绕过POSIX 权限收敛posix-permissions.ts、Manager 原子 JSON 路径权威校验凭证、令牌、密钥泄露密钥加密存储secret-store.ts、secret-encryptor.ts更新程序 / 打包 / 发布完整性发布校验脚本scripts/verify-public-release.mjs、scripts/verify-windows-signing.ps1捆绑本地服务 / 集成路径Browser-use 审计日志、扩展宿主隔离等5.1 远程代码执行与权限提升渲染层沙箱Kun 基于 Electron 构建桌面 GUI其安全边界的第一道防线是渲染进程。src/main/browser-security/web-contents-hardening.ts提供的hardenedRemoteWebPreferences集中定义了远程内容的默认 WebPreferencesnodeIntegration: false, nodeIntegrationInWorker: false, nodeIntegrationInSubFrames: false, contextIsolation: true, sandbox: true, webSecurity: true, allowRunningInsecureContent: false, webviewTag: false, navigateOnDragDrop: false, safeDialogs: true, disableDialogs: true, autoplayPolicy: document-user-activation-required, spellcheck: false要点解读sandbox: truecontextIsolation: true渲染进程运行在 Chromium 沙箱中且无法直接访问 Node/Electron 能力这是阻断渲染层 → 主进程 RCE的关键组合nodeIntegration全系关闭包括 Worker 与 SubFrame杜绝任何旁路注入路径webviewTag: false禁用易出问题的webview标签disableDialogs: true禁止远程内容弹出对话框防钓鱼与自动确认攻击。同一文件中的hardenRemoteSession则实现默认拒绝的权限模型target.setPermissionRequestHandler((_contents, _permission, callback) callback(false)) target.setPermissionCheckHandler(() false) target.setDevicePermissionHandler(() false) target.on(will-download, (event) event.preventDefault())即所有权限请求一律拒绝、下载一律拦截。对应的 web-contents-hardening.test.ts 用于验证这些默认值不会被后续修改破坏。5.2 不安全文件访问与沙箱绕过POSIX 权限收敛kun/src/security/posix-permissions.ts提供跨平台感知的权限收紧工具export function shouldApplyPosixMode(platform: NodeJS.Platform process.platform): boolean { return platform ! win32 } export async function applyPosixMode(path: string, mode: number): Promisevoid { if (!shouldApplyPosixMode()) return await chmod(path, mode) }由于 Windows ACL 并不实现 POSIX 权限位该模块在win32上自动跳过避免误用在 macOS/Linux 上则对敏感文件强制0600/0700权限。它被多个子系统复用例如src/main/browser-use/browser-use-audit-log.ts通过import { applyPosixMode } from ../../../kun/src/security/posix-permissions.js对审计日志施加限制性权限——这印证了权限工具是共享安全基础设施而非单一模块的私有实现。此外凭证写入过程对密钥文件目录使用0o700、文件使用0o600见下文并依赖AtomicJsonFile Manager 路径权威校验assertManagerAtomicJsonPath确保密钥/租约文件只能落在 Manager 授权目录内防止路径穿越类越权写入。5.3 凭证、令牌与密钥泄露AES-256-GCM 加密存储这是 SECURITY.md 范围中实现最深的一环。Kun 的凭证存储位于 secret-store.ts其文件头注释直接点明设计动机OAuth tokens must not be plaintextOAuth 令牌不得以明文存储。5.3.1 加密算法与信封格式secret-encryptor.ts 使用AES-256-GCM32 字节密钥、12 字节随机 IV并支持 AAD附加认证数据绑定密文信封格式为enc:v1:iv base64:authTag base64:ciphertext base64encrypt()每次生成全新随机 IVdecrypt()先校验信封前缀再校验认证标签任何篡改都会被 GCM 的完整性校验拒绝。createCompatibleEncryptor还实现了主密钥写、双密钥读的兼容模式用于系统密钥与临时回退密钥并存时期的数据平滑迁移。5.3.2 密钥来源三级优先级createSecretEncryptorkun/src/security/secret-store.ts按如下优先级解析 32 字节主密钥macOS Keychain通过security find-generic-passwordservicekun-secret-keyaccountkun读取security add-generic-password写入Linux Secret Service通过secret-tool lookup/store读写同一 service/accountWindows DPAPI用 PowerShellProtectedData以CurrentUser 作用域对 AES 密钥进行 DPAPI 包裹将dpapi:v1:前缀的受保护 blob 写入密钥文件——即使密钥文件被拷走其他用户或机器也无法解密最终回退生成随机密钥写入0600 权限的密钥文件目录 0700。关键细节密钥内容一律通过stdin 喂给系统凭证助手绝不进入 argv避免密钥出现在进程列表ps中——对应defaultSecretCommandRunner对spawn(command, args, { shell: false })与child.stdin.end(input)的封装。5.3.3 故障关闭fail-closed策略secret-store.ts中多处体现了宁可失败、不可损坏的 fail-closed 语义这是安全范围中凭证泄露风险的核心防线查找失败 ≠ 确认缺失Keychain/Secret Service 查询返回unavailable而非确认missing时默认拒绝生成新密钥替换因为旧凭证仍由临时不可读的密钥加密贸然替换会导致数据永久不可解密报错文案refusing to replace the existing Kun encryption key无法读取的 DPAPI 密钥文件检测到dpapi:v1:前缀但解密失败时抛出UnreadableCredentialKeyError错误码credential_key_unreadable拒绝用新密钥覆盖旧密文双世代密钥并存若 Keychain 密钥与回退密钥文件内容不同则同时保留两者createCompatibleEncryptor双读绝不删除任一代密钥未知凭证状态按加密处理hasPersistedSecretKeyMaterial对无法解析的凭证文件一律视为需要密钥调用方因此 fail-closed 而非误删。5.3.4 并发引导的租约协调多进程GUI Runtime CLI同时首次启动时密钥的查找/迁移/引导必须串行。secret-store.ts通过SecretKeyBootstrapLease实现租约文件为${keyFilePath}.bootstrap-lease.v1.jsonschemaVersion 1租约有效期 30 秒、心跳 5 秒、最长等待 90 秒租约通过 Manager 的AtomicJsonFileCAS 更新选举唯一引导者且租约文件本身不含任何密钥材料——密钥只存在于 OS 凭证库或 0600 密钥文件中Manager 只负责选出一位执行者。当租约过期但属主进程仍存活leaseOwnerIsDefinitelyDead仅以ESRCH判定死亡时会拒绝回收租约防止误杀活进程的密钥引导。5.3.5 自动化场景的隔离开关openspec/changes/harden-automation-credential-store-isolation/specs/credential-store-isolation/spec.md定义了一个重要配置当环境变量KUN_DISABLE_OS_CREDENTIAL_STORE1或显式传入disableOsKeychain选项时密钥提供者完全不调用操作系统凭证助手Keychain / Secret Service / DPAPI改用 0600 密钥文件的加密回退实现主机凭证设施的hermetic密封隔离。这一设计同时服务两类场景自动化测试单元测试与桌面冒烟测试在初始化前启用隔离仅使用各自的数据目录绝不读写宿主用户的凭证库自动化 Agent 运行在 CI 或无人值守环境中避免弹出系统密码对话框。该 spec 还要求官方测试环境在应用初始化前启用隔离、子进程继承隔离设置与secret-store.test.ts中大量以隔离/回退为前置条件的用例如OS credential store disabled场景相互印证。5.4 更新程序、打包与发布完整性SECURITY.md 将updater、packaging 或 release integrity weaknesses列为报告范围。仓库在 scripts/ 目录准备了完整的发布校验链例如verify-public-release.mjs校验公开发布的工件与签名verify-windows-signing.ps1验证 Windows 签名verify-apple-signing.cjs、mac-notarize.cjsmacOS 签名与公证public-release-download.mjs 与 release.sh发布下载与流水线执行。这些脚本证明发布物的签名、公证与完整性校验是发布流程的强制环节而非事后检查。5.5 捆绑本地服务与集成路径Kun 捆绑了 Browser-use、扩展宿主、本地服务等集成路径安全范围要求报告其中的漏洞。仓库中的典型加固包括Browser-use 审计日志browser-use-audit-log.ts对审计日志施加限制性 POSIX 权限并执行有界轮转防止日志被篡改或无限增长不可信内容包裹untrusted-content.ts将外部来源内容包裹为untrusted-content source...标记并对属性做、、转义防止注入与混淆同时保留来源可追踪性扩展宿主扩展通过隔离的 API 面与主进程交互见 docs/extensions/ 中的架构与安全文档默认拒绝越权能力。六、测试与自动化隔离如何验证安全边界仓库为安全实现配备了系统化测试最典型的是 secret-store.test.ts覆盖的关键断言包括密文往返encrypt(bearer-token-123)后序列化 blob不包含明文expect(blob).not.toContain(bearer-token-123)且能正确decrypt还原AAD 绑定以profile-a:credential-a为 AAD 加密的密文用profile-b:credential-a解密必须抛错fail-closed 行为OS 凭证库不可用且不允许回退引导时拒绝执行凭证副作用DPAPI 密钥冲突时报different credential generations密钥文件隔离密钥路径位于 Manager 授权目录之外时在任何凭证副作用发生前即被拒绝回退密钥文件内容不可泄露断言密钥文件本身不包含明文机密。而openspec/changes/harden-automation-credential-store-isolation/下的 spec 则通过WHEN/THEN 场景形式如KUN_DISABLE_OS_CREDENTIAL_STORE恰为1时凭证初始化不执行任何 Keychain/Secret Service/DPAPI 助手固化了隔离行为的验收标准与secret-store.ts中environment[DISABLE_OS_CREDENTIAL_STORE_ENV] 1的判断逻辑一一对应。七、给使用者与安全研究者的实践建议综合 SECURITY.md 与源码实现可提炼出如下可操作建议发现疑似漏洞时不要发公开 Issue通过 SECURITY.md 中列出的私密渠道报告并附上影响版本 PoC 影响评估三要素可显著缩短分诊周期升级策略以最新发布版本为基线见 release/旧版本不保证获得安全修复自动化/CI 场景设置KUN_DISABLE_OS_CREDENTIAL_STORE1隔离宿主凭证库避免自动化运行触碰真实用户密钥理解凭证边界无论密钥来自系统钥匙串还是 0600 密钥文件令牌在磁盘上始终以 AES-256-GCM 密文存储密钥文件回退是已文档化、足够安全的降级路径密钥文件仅属主可读并非明文存储渲染层隔离远程/不可信内容在 sandbox contextIsolation 默认拒绝权限模型的约束下运行任何试图放宽这些默认值的改动都应在 web-contents-hardening.test.ts 中体现回归测试。综上SECURITY.md 不是一份孤立的模板文档它的每一条范围声明都能在仓库中找到对应的实现与测试证据——从凭证的 AES-256-GCM 加密与三级密钥来源到 Electron 渲染沙箱与默认拒绝的权限模型再到发布签名校验与自动化凭证隔离共同构成了 Kun 从披露机制到纵深防御的完整安全体系。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐NOFX 安全策略与纵深防御实践密钥保护、漏洞披露与部署加固完全指南NOFX 安全策略与纵深防御实践密钥保护、漏洞披露与部署加固完全指南 NOFX 是一套同时管理美股、大宗商品、外汇与加密货币交易的 AI 交易终端直接持有真AI Agent金融科技后端前端Lore 安全策略全解读漏洞报告、披露流程与安全加固实践Lore 安全策略全解读漏洞报告、披露流程与安全加固实践 Lore 是一款开源的下一代版本控制系统其安全策略由维护方 Epic Games 制定并公开在仓库版本控制后端Open Glean 安全策略与纵深防御架构漏洞上报、密钥托管与出站请求防护全解读Open Glean 安全策略与纵深防御架构漏洞上报、密钥托管与出站请求防护全解读 Open Glean 是一个开源的 AI 知识工作平台其核心职责包括代用上一篇Humanizer 罗马数字扩展ToRoman 与 FromRoman 的用法、边界约束与源码级实现解析下一篇ChatGPT-ShortcutAiShort快速入门指南30 秒把精选提示词复制到 ChatGPT / DeepSeek 等任意 AI 工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考