安全与信任
5 分钟阅读
Barn 面向受信任的本地开发工作站。同一套 Linux 实验环境中的所有节点共享同一个私有子网，且控制节点持有可管理其余节点的部署级 SSH 私钥。Barn 的属主与身份检查旨在防止误删无关宿主文件或误杀进程，而非在共享服务器上隔离互不信任的多租户用户。
宿主权限
日常请始终以普通登录用户运行 barn。QEMU 进程、Barn.app 虚拟机、镜像下载、虚拟磁盘与状态文件均归当前普通用户所有并以该身份运行。只有以下三项宿主级操作需要管理员（sudo）权限：
| 操作 | 特权变更范围 |
|---|---|
barn setup（安装 Linux 宿主依赖） |
调用发行版包管理器（apt/dnf）安装 QEMU、固件与 OpenSSH（macOS 上的 Homebrew 以普通用户身份运行） |
barn network install / uninstall |
安装或卸载宿主全局固定 IP 网络后端（Linux 上的 barn0 网桥，macOS 上的 socket_vmnet launchd 服务） |
barn hosts install / uninstall |
通过独立的 barn-hosts-helper 修改 /etc/hosts 中由 Barn 标记界定的区块 |
在请求 sudo 授权前，setup、network 与 hosts 都会先打印完整的变更计划。在终端中，如果宿主缺少依赖或 Barn 网络不完整，up、start、restart 与 reload 会提议准备宿主：它们执行同一份 setup 计划、同样只询问一次，且从不默认 --yes。没有终端时这些命令只报告缺少的条件，无人值守准备请执行 barn setup --yes。
请确保 barn 与 /opt/barn/libexec/barn-hosts-helper 来自同一次构建：CLI 调用 helper 前会核对其内嵌 SHA-256 摘要，helper 在每次写入前后都会校验 /etc/hosts 的属主、权限、硬链接数及预期内容摘要。
相比之下，原生的 barn mac 工作流在虚拟机启动时按需创建用户态 vmnet 网络，不安装任何 root 守护进程或特权网络服务（详见设计说明与卸载指南）。
客机访问与 SSH 信任
Linux 实验环境的默认客机管理账号为 dba（密码已锁定、具备免密 sudo 权限，并使用 $BARN_HOME 中生成的 Ed25519 部署密钥登录）。Barn 同时会将该私钥分发到控制节点，以便在控制节点上运行 Ansible 剧本管理其他节点——因此能够登录控制节点的用户即拥有整套 Linux 实验环境的管理权限。
Barn 针对三类 SSH 连接路径采用不同的主机密钥校验策略：
| 连接路径 | 主机密钥策略 |
|---|---|
宿主 → Linux 客机（经由 barn 或 ~/.ssh/barn_config） |
使用独立 known_hosts 文件与虚拟机 UUID 别名，并启用 StrictHostKeyChecking accept-new（首次连接自动记录密钥，后续若密钥不匹配则拒绝连接；显式 recreate 会生成新的虚拟机 UUID） |
| Linux 控制节点 → 实验环境其他节点 | 对 Barn 管理的节点别名配置 StrictHostKeyChecking no 与 UserKnownHostsFile /dev/null，使实验节点频繁重建后仍可直接连通 |
| 宿主 → 已初始化的 macOS 客机 | 对照绑定到 barn-mac-<instance_id> 的单机专属 known_hosts 严格校验主机密钥，并禁用 SSH agent forwarding |
每台 macOS 虚拟机拥有独立的 Ed25519 SSH 密钥对与随机生成的桌面管理员密码（保存在虚拟机目录内权限为 0600 的 password 文件中，可通过 barn mac password 查看）。首次初始化完成后，Linux 与 macOS 客机均强制使用 SSH 公钥认证，关闭 SSH 密码认证与 root 远程登录，并为管理账号配置免密 sudo。提交 Issue 或分享配置时，请先剔除日志和状态文件中的私钥与密码。
首次连接 Mac 客机时，信任依据来自 runner 独占的私有网络，以及 SSH 连接前后的 runner 身份核验，随后将观察到的主机密钥固定到实例 UUID。GUI 密码与 SSH 私钥采用相同的文件权限边界；私钥已经授予客机 sudo 权限，单独将密码存入 Keychain 只会增加签名身份和锁定状态故障，无法进一步保护客机权限。详见原生 Mac 生命周期。
共享文件与测试磁盘
- 宿主目录共享：可写共享（Linux
vm_shares中设readonly: false或barn mac --share使用:rw）允许客机进程直接修改所挂载的宿主目录，且客机写入的内容在删除虚拟机后依然保留。请仅共享专门的工作目录；若客机无需写入宿主文件，请优先使用只读共享。 - 持久盘与测试数据盘：普通 Linux
destroy与recreate会保留persistent: true的持久数据盘。恢复客机时，up会格式化没有任何签名的数据盘；已有的 ext4 或 XFS 文件系统在检查工具报告可识别的损坏时会被重置，持久盘也不例外；其他探测或检查失败会保留数据并给出警告。重要数据请在实验环境之外做好备份（详见存储与访问）。
下载与镜像信任
Barn 将软件分发与镜像校验划分为四个彼此独立的信任机制：
| 机制 | 校验范围 |
|---|---|
发布资产 checksums.txt |
列出每个发布资产的 SHA-256 摘要，包括 CLI 归档、.deb/.rpm 软件包、SPDX 物料清单、Homebrew Formula、安装脚本与发布元数据；安装脚本会按它校验所选归档 |
| macOS 发行包代码签名 | 正式发布的 Apple Silicon CLI、helper 与 Barn.app 均使用 Developer ID 签名并通过 Apple 公证，App 已装订票据；本地源码构建默认使用 ad-hoc 签名 |
Linux 镜像目录签名（catalog.json.minisig） |
使用二进制内置的 Ed25519 生产公钥校验 catalog.json 签名，并执行按仓库隔离的修订号防回滚检查 |
| 镜像产物校验 | 在启用镜像前逐一核对 .qcow2 文件的字节大小、SHA-256 摘要、虚拟磁盘容量与独立 qcow2 结构安全性 |
发布资产均从对应标签的源码构建：配齐 Mac 签名密钥时由标签工作流构建，否则走文档中的本地发布流程。发布提交必须先通过源码 CI；两条路径都要求软件包、归档、SBOM 与校验和验证通过后才能创建 GitHub Release 草稿，本地发布步骤见 Mac 发布手册。
1.2.0 的 release.json 用 signed:false, attested:false 描述通用发行元数据的范围：Git tag、通用校验和及发布元数据没有独立密码学签名或 attestation。目录的 Minisign 校验与 Apple Silicon 代码签名/公证仍分别适用于上表中的对象，最终验收记录逐项验证了这些机制。
两个官方镜像仓库（https://repo.pigsty.io/barn 与 https://repo.pigsty.cc/barn）无论通过默认配置还是 --repo 显式选中，均强制要求有效的 minisign 目录签名。通过 --repo 或 BARN_REPO 显式指定的自定义 HTTPS 仓库或本地目录仓库可以使用未签名目录，请仅添加你信任的镜像源（详见镜像参考）。
报告安全漏洞
发现安全漏洞时，请通过 GitHub 私密安全通告或发送邮件至 [email protected] 私下报告，并附上 barn --json version、宿主系统与架构以及脱敏后的最小复现步骤。安全修复发布在最新的 1.x 补丁版本中：只有最新的 1.x 版本受支持，0.x 版本不再提供修复。完整政策见 SECURITY.md；日常功能缺陷请提交至 GitHub Issues。