https://avatars.githubusercontent.com/u/18242685

lihuu's blog

sandbox-exec Policy 编写指南:基本结构与规则

适用场景:sandbox-exec -f xxx.sb

一、Policy 基本结构

SBPL 基于 Scheme 语法(Lisp 变体),采用 S-Expression(S 表达式)。

1. 最小结构

一个最基础的策略文件通常包含版本声明和默认行为:

(version 1)

(allow default)                            ; 默认允许所有操作
(deny file-read* (subpath "/Users/lihu/.ssh")) ; 显式拒绝读取 .ssh 目录

2. 语法组成

单条规则的基本格式如下:

OpenClaw 本地沙盒化运行(macOS)实施笔记

本文记录如何在 不创建新用户 的前提下,用 sandbox-exec(Seatbelt)对 OpenClaw(AI Agent)进行本地沙盒化运行。

一、背景与目标

运行 OpenClaw(AI Agent)存在潜在安全风险:

  • 可能被 Prompt 注入执行危险命令
  • 可能访问 SSH Key、Keychain 等私密数据
  • 可能误删/篡改系统文件
  • 可能污染 Homebrew 工具链

目标是在 不创建新用户 的前提下,把 OpenClaw 运行在一个 受限沙盒环境 中,实现:

macOS Tahoe 26.x SSH 安全加固笔记

最近 Claude Bot 比较火,搞了个 Mac mini 来玩玩。下面是把 Mac mini 当作服务器的一些安全设置,主要是 SSH 方面的配置。

适用版本:macOS Tahoe / Sonoma / Ventura 及以后
架构特点:launchd Socket Activation(不再由 sshd 直接监听端口)

加固目标

  • 仅允许 SSH 公钥登录
  • 禁用密码/交互认证
  • 使用自定义端口,关闭默认 22
  • 最小化网络暴露面
  • 可验证、可回滚

一、背景说明(重要)

从 Ventura 开始,macOS 的 SSH 端口由 launchd 监听:

WOL网络唤醒设置

BIOS/UEFI 层级配置

这是所有设置的前提。如果硬件层关闭,系统层做再多努力也无效。

  1. 进入 BIOS:通常是开机连续按 DelF2
  2. 电源管理设置 (Power Management)
    • Wake On LANResume By PCI-E Device:设为 Enabled
    • ErP Ready:设为 Disabled(这是关键!ErP 开启会将待机功耗降至 0.5W 以下,直接切断网卡电源)。
    • Deep Sleep:设为 Disabled

操作系统设置

、 Windows 操作系统配置

Windows 默认倾向于在关机时“彻底休眠”,这有时会干扰网卡状态。

Wake-on-LAN (WOL) 技术深度解析:从协议到驱动的完整实现

一、 核心原理:协议栈与硬件实现

WOL 是一种基于 OSI 模型第二层(数据链路层) 的硬件唤醒技术,由 AMD 和 HP 于 1997 年提出,并在 IEEE 802.3 标准中得到规范。

1. Magic Packet 数据结构

WOL 的核心载荷是一个 102 字节的特殊以太网帧,其结构定义如下:

+----------------+------------------+
| 6 bytes 0xFF   | Synchronization  |
+----------------+------------------+
| 96 bytes       | Target MAC × 16  |
+----------------+------------------+
  • 同步流 (Sync Stream):6 个字节的 0xFFFF:FF:FF:FF:FF:FF),作为魔术包识别标记。
  • 目标载荷:目标 NIC 的 MAC 地址连续重复 16 次(16 × 6 = 96 字节)。
  • 封装协议
    • 标准实现使用 UDP/7(Echo Protocol)或 UDP/9(Discard Protocol)
    • 也可以使用 EtherType 0x0842 直接封装在以太网帧中
    • 关键点:NIC 的物理层(PHY)芯片通过硬件模式匹配 MAC 序列,不依赖 IP 层解析

2. NIC 的待机监听机制

即使系统处于 ACPI S5 状态(Soft Off),主板的 ATX 电源仍会通过 +5V Standby(紫色线) 为 NIC 提供约 2-3W 的待机功耗。此时 NIC 进入 PCI Power State D3hot/D3cold,仅保留以下组件活跃:

Xcode 注释标签(Annotation Tags)与最佳实践指南

本指南适用于 Swift / SwiftUI / macOS/iOS 应用开发,帮助你在工程中正确、优雅、专业地使用 Xcode 支持的注释标签,提高代码可读性、可维护性和团队协作效率。


1. Xcode 支持的注解标签一览表

以下标签是 Xcode 原生支持 的,它们在导航栏、Issue Navigator 中具有特殊行为。

注解标签 Xcode 行为 用途 官方支持
// MARK: 在导航栏创建分组 Section 组织代码结构 ✔ 是
// MARK: - 分组 + 分隔线 更强的视觉分割 ✔ 是
// TODO: 出现在 Issue Navigator → Todos 待办事项 ✔ 是
// FIXME: 出现在 Issue Navigator → Todos 待修复的问题 ✔ 是
// WARNING: 构建时出现黄色警告 ⚠️ 强调重要问题 ✔ 是
// ERROR: 构建时报红色错误 ❌ 阻止构建(调试用) ✔ 是
// NOTE: 普通注释,无特殊行为 补充说明 ✔ 是
/// 文档注释(Quick Help 支持) 类型/方法/属性文档 ✔ 是
/** ... */ 多行文档注释 长段落说明 ✔ 是

2. 注解标签详解

2.1 // MARK: —— 代码分区(最常用)

用于将大型 Swift 文件分块,让导航结构更清晰。

从 Cloudflare 11.18 全局崩溃事件深度剖析:分布式系统中的容错哲学与配置管理实践

引言:当蝴蝶效应遭遇分布式系统

2025 年 11 月 18 日 11:20 UTC,作为支撑全球 20% 互联网流量的基础设施巨头 Cloudflare 遭遇了自 2019 年以来最严重的全球性服务中断。这次事故的起因极具讽刺意味:并非精心策划的网络攻击,也非复杂的硬件故障,而是一次旨在"提升安全性"的 ClickHouse 数据库权限优化——为了实现更细粒度的查询权限控制,工程师将用户访问的表元数据从单一的 default 数据库扩展到了底层的 r0 数据库。

从编程哲学到微服务架构:控制与逻辑的分离之道

编程的本质,是对复杂度的驯服。 人类在构建系统时,总会在“秩序”与“自由”之间寻找平衡: 我们希望系统可控,却又希望它具备足够的灵活性。

而“控制与逻辑的分离”,正是这场平衡的核心哲学。


一、从程序语言看“控制”与“逻辑”的两极

在最原始的机器世界里,程序员手动控制一切:寄存器、内存、跳转指令。 那时没有“逻辑”,只有“控制”;系统完全依赖人的思维去维持秩序。