南洋理工大学Linux提权安全基准：531个场景测出模型能力差4倍

龙哥导读

当大语言模型开始接管安全工具，真正危险的问题不只是“模型懂不懂漏洞”，而是它能否把观察、判断和多步操作连成一条可执行链。这项研究没有拿几道静态题目做演示，而是构建531个隔离场景、329个环境变体，系统比较模型、代理架构和配置扰动。最醒目的结果是：六个模型总体成功率从10.2%到40.9%，相差约4倍；但更值得防守团队警惕的是，换一套代理架构后，原本落后的模型也可能迅速逼近前列。

这篇论文提出了一个很现实的问题：如果企业只按照“模型排行榜”判断自动化安全风险，会不会看错重点？同一个基础模型，接上不同的枚举、规划、记忆和执行框架，行为能力可能完全不同。换句话说，模型只是发动机，代理框架才决定方向盘、变速箱和刹车怎样配合。

龙哥认为，这项工作的价值不在于展示攻击技巧，而在于把一个模糊的担忧变成可重复测量的问题。研究者把每个实验放进隔离的Docker环境，设定明确的权限起点、成功条件和步数预算，再用构建检查、漏洞差分和修复后一致性验证排除假阳性。防守者由此能回答：风险来自模型本身，还是来自代理框架；某项配置变化能挡住多少；哪些类别最容易形成盲区。

这里必须先把讨论范围说清楚。论文研究的是公开、已知、容器化的Linux权限提升场景，不涉及零日漏洞，也不能直接代表真实生产网络。文章只讨论基准设计、聚合结果、代理架构对风险测量的影响，以及防守团队如何据此安排测试和加固优先级，不展开任何可复制的提权命令或操作序列。

一、为什么过去的安全评测容易“看起来很强”

很多模型安全评测仍停留在问答层：给模型一段漏洞描述，让它选择类别、解释原因，或者生成一段文本。这样的题目可以测知识，却测不到模型在环境里连续观察、修正和停止的能力。真实代理需要处理不完整信息、命令返回、失败反馈和有限预算，任何一步出错都可能让后续判断失效。

论文总结了旧基准的三个缺口。第一，场景数量太少，专门面向Linux权限提升的既有工作通常只有十几个手工场景。第二，环境覆盖不均，某些常见类别占比很高，另一些类别几乎没有。第三，验证不够严格：容器能启动，不等于目标缺陷真实存在；脚本返回正常，也不等于权限发生了可验证变化。

小样本还有一个容易被忽略的问题：一次偶然成功会被放大。如果只有十道题，模型多做对一道，成功率就变化十个百分点；如果场景配置固定，模型还可能依赖某个路径、文件名或提示细节。531个原始场景和329个变体并不能消除所有偏差，但至少让研究者能够观察类别分布、组合上限和环境敏感性，而不是只展示几个“成功案例”。

对企业来说，这种差异很关键。采购者常问“哪个模型最安全”，安全团队更应该问“在哪些任务、哪种代理框架、什么配置和权限范围内，它表现出怎样的能力”。前一个问题容易得到一张简单榜单，后一个问题才接近真实部署决策。

因此，这项研究的第一层贡献不是把成功率做高，而是把测量单位从“问题”变成“可执行场景”。每个场景都有结构化描述、环境材料、成功判据和验证记录。模型必须在预算内完成从观察到结果的闭环，研究者则能回看失败发生在信息收集、方法选择、执行过程还是循环停滞。

二、531个场景是怎样被审出来的

研究团队先建立14个子类别的分类体系，再从公开材料中抽取候选。候选不是直接塞进排行榜，而是先转成统一的场景规范结构。它记录环境、目标、前置条件和验证信息，让后续构建器不必反复理解格式各异的文字说明。结构化输入的意义是减少测量噪声：同类场景用相近的规则描述，错误更容易定位。

接下来是自动构建。Scaffolder根据结构化描述生成隔离环境，必要时参考已经通过的相近样例。这里最容易出现的误区是把“镜像成功生成”当作场景有效。论文没有这样做，而是把构建成功只视为第一道门，后面还要检查目标缺陷能否触发，以及修复后同一路径是否失效。

第二道门是漏洞差分检查。研究者关注的不是某段脚本有没有打印成功，而是场景在存在目标缺陷时能否产生预期权限变化。第三道门则把相关组件修复或替换，再执行同样验证；如果修复后的环境仍然报告成功，说明场景或验证逻辑可能存在误判。只有同时通过这些检查，候选才进入最终集合。

论文报告的流水线数字很能说明严格验证的必要性。大量候选在构建、差分验证或修复后一致性阶段被淘汰，最终保留531个经审计场景。这个过程告诉防守团队：自动生成测试环境并不难，难的是证明它测到的确实是预期风险，而不是脚本、镜像或判据的偶然错误。

这套思路同样适合内部红队平台。企业不一定复刻论文的全部类别，但可以复用“三道门”：先确认环境可复现，再确认风险在缺陷存在时出现，最后确认修复后风险消失。只有这样，自动化评测结果才适合进入整改优先级和版本回归，而不是成为一张好看的演示图。

论文Figure 1：公开候选先转为ScenarioSpec，再经过环境构建、差分验证和修复后一致性检查。图中多道筛选说明“能运行”与“测得准”是两件事。

三、表格里的4倍差距到底说明什么

论文在531个原始场景上比较六个模型。Table 4按漏洞类别汇总成功率，最高总体成功率是40.9%，最低是10.2%，约为4倍差距。这个数字可以支持“模型选择会显著影响自动化能力”，但不能被改写成“最高模型在真实系统中有四倍危险”。场景分布、代理框架、预算和隔离环境共同决定了这个结果。

更有意思的是，各类别没有一个模型全面领先。有的模型在某一类上明显更强，在另一类上却接近零；另一些模型总体排名靠后，却在特定类别里保持竞争力。这说明单一平均分会隐藏能力形状。对防守团队而言，风险画像应该至少包含类别成功率、失败模式、环境敏感性和代理架构增益，而不只是一个总分。

表中还出现了“组合上限”。六个模型只要任意一个成功，覆盖可达到329个场景，占531个场景的62.0%，明显高于单一最佳模型的40.9%。两种较强模型组合已经覆盖298个场景，即56.1%。这意味着攻击能力不必集中在一个万能模型上，多模型路由或按类别选择模型就可能扩大覆盖。

从防守角度看，组合上限比单模型冠军更值得关注。企业往往按照某个模型的单次表现设置风险等级，但真正的代理平台可以在后台切换模型、重试或调用专门模块。如果安全策略只针对一个固定模型做测试，可能低估系统在多次尝试和路由之后的总体能力。

同时，40.9%也不能被当作“已经可以自动接管大多数真实主机”。论文中的场景是已知材料、明确目标、隔离环境和有限任务边界。真实网络会增加身份体系、资产差异、监控、网络分区和组织流程，也会出现论文未覆盖的技术栈。基准分数的正确用途是比较与回归，不是直接预测生产事故概率。

论文Table 4原表裁图：列出六个模型在设置用户身份位、权限委托、能力位及其他类别上的成功率。总体最高40.9%、最低10.2；指标越高表示在该隔离基准内完成目标的比例越高。

四、真正改写排名的，可能是代理框架

如果只看Table 4，很容易把结论停在“换更强模型”。论文继续比较代理架构后，故事发生了变化。基线采用通用的观察—推理—行动循环；增强框架则加入确定性枚举、类别匹配、规划和策略排序，把部分原本交给模型临场猜测的工作变成结构化流程。

这一变化带来的不是统一的小幅提升，而是不同模型得到不同增益。论文报告，增强架构对五个模型都有改善，其中部分模型提升超过十个百分点。原本总体成功率只有10.2%的模型，在进一步的专用代理框架下可达到接近四成的水平。这里的核心结论不是某个具体框架万能，而是代理工程会改变基础模型的能力排序。

为什么会这样？第一，确定性枚举可以稳定收集环境信息，减少模型因为遗漏而走错方向。第二，类别匹配把观察结果连接到更合适的策略族，降低方法选择错误。第三，分步规划和记忆减少反复试错，让有限步数用在更有价值的判断上。第四，停止条件与状态追踪可以抑制无效循环。

这些模块并没有让模型“学会新知识”，却改变了知识被调用的方式。就像同一名工程师拿到不同的检查清单、日志系统和自动化工具，交付质量可能差很多。对安全治理来说，审批对象不能只有模型，还必须包括工具权限、系统提示、记忆、规划器、重试策略和执行沙箱。

企业部署代理时常把框架看成普通应用代码，认为只要底层模型通过评估就够了。论文提示了相反方向：框架本身可能是能力放大器，也是风险放大器。一次版本更新如果增加了更强的系统枚举、自动路由或长期记忆，即使模型名称不变，整体风险等级也可能发生变化。

论文Figure 6：代理把确定性信息收集、类别匹配、计划排序与交互执行串成四段。文章只讨论这些模块如何影响风险测量，不展示任何可操作的提权步骤。

五、环境一变，成功为什么会掉下来

论文用329个参数化变体测试环境扰动。研究者改变部分环境元素，再看模型能否保留原来已经展示过的成功。不同模型的成功保持率从59.0%到78.2%。这说明模型并非只靠抽象能力完成任务，其中相当一部分表现依赖具体路径、名称、输出格式或其他环境线索。

保持率的含义需要谨慎理解。它不是总体成功率，而是在模型曾经成功的场景上，环境变化后还能成功多少。某个模型原始成功数量更多，分母也更大；另一个模型原始成功较少，却可能在那部分场景上保持得更稳。因此，保持率和总体成功率必须一起看。

对防守者来说，这组实验有两个启发。其一，配置多样性和轮换可以打断一部分依赖固定线索的自动流程。其二，扰动不是根本修复：最好的保持率仍然超过七成，说明能力并不会因为改名或轻微变化自动消失。真正可靠的策略仍是最小权限、及时修补、隔离、高价值动作二次确认和持续审计。

配置扰动更适合做“额外摩擦”，而不是安全主墙。它可以增加自动化流程的成本，让固定脚本和脆弱代理更容易失败；但一旦代理具备更好的观察、重新规划或多模型重试能力，单纯依赖隐藏路径和改名的收益会迅速下降。把混淆当修复，就像把门牌号换掉却不锁门。

这也解释了为什么回归测试必须保留变体。若每次模型或框架升级都只跑原始场景，团队可能把对固定模板的适应误认为泛化。更好的做法是保留一部分未见变体、按类别分层抽样，并记录版本之间能力新增、保持和退化的来源。

六、失败记录比成功案例更能指导加固

论文没有只统计成功率，还分析失败模式。自动化代理可能在方法选择阶段就走错，也可能识别出方向却执行失败；有时会重复相同动作，有时在无效信息上消耗预算。不同失败对应不同防御含义：方法选择错误说明知识或匹配不足，执行错误说明环境交互仍不稳定，循环则说明状态追踪和停止机制需要加强。

从安全团队视角看，失败日志可以反过来形成检测规则。如果代理反复枚举、连续尝试同类路径或在权限变化前出现固定序列，监控系统就有机会在真正成功前介入。论文没有证明这些模式在所有生产环境都稳定，但它提供了一个可用于设计遥测字段和回归样本的起点。

更重要的是，不要把代理失败等同于风险消失。系统更新、提示调整、工具权限增加或模型切换都可能让同一场景从失败变成成功。防守团队应把失败视为“当前版本、当前配置下未完成”，而不是永久安全证明。

同样，成功也不应自动升级为严重生产漏洞。基准场景的成功表示代理在隔离条件下满足预设判据。要进入真实整改流程，还需要结合资产暴露、已有补丁、权限边界、业务价值和可检测性。测量平台的职责是发现能力变化，风险管理的职责是把能力与真实环境结合。

因此，一份有用的内部报告至少要分开记录四类信息：模型与版本、代理框架与工具、场景与变体、最终结果与失败阶段。只保留“成功/失败”会丢掉最能帮助工程团队改进的部分。

七、企业怎样把这篇论文变成防守清单

第一，评估对象从模型扩展到完整代理系统。同一模型接入不同的枚举器、规划器、记忆和工具权限，可能呈现完全不同的能力。模型升级、框架升级和权限变更都应触发重新评估。

第二，用差分验证保证测试场景真的有效。场景能启动只说明工程文件没有立刻报错；缺陷存在时成功、修复后失败，才说明判据更接近目标风险。内部靶场应保留修复版本作为对照。

第三，按类别看风险，不迷信总榜。模型在不同权限提升类别上的能力并不均匀。企业可以按自己的资产和配置分布加权，而不是照搬论文的平均分。

第四，把环境变体放进持续回归。路径、名称和配置轻微变化后，能力保持率仍然可观。未见变体能帮助团队区分模板记忆与真正泛化，也能发现某次升级新增了哪些能力。

第五，严格限制自动执行面。高风险动作应在隔离环境运行，生产系统采用最小权限、短期凭据、命令白名单、关键动作复核和完整审计。即使模型当前成功率不高，也不应把低分当作放宽权限的理由。

第六，保留失败阶段和行为轨迹。无效循环、重复尝试和异常枚举既是代理质量问题，也可能成为防守侧的检测机会。遥测设计应覆盖工具调用、权限变化、资源访问和策略切换，而不是只记最终返回文本。

八、和相似研究放在一起看

自动渗透测试基准AutoPenBench关注生成式代理在渗透测试任务中的整体能力，进攻性网络操作评测OCCULT则从进攻性网络操作能力角度评估大语言模型。PrivEscalate把镜头进一步缩小到Linux权限提升，并用更大规模、可执行、带差分验证的场景做细粒度测量。三者共同说明，安全评测正从“模型会说什么”转向“模型连接工具后能完成什么”。

这种变化也意味着传统语言模型安全测试不够用了。内容过滤可以减少模型直接输出危险文本，却无法单独管理代理在工具层的组合行为。一个系统可能每一步看起来都普通：读取状态、选择模块、调用工具、根据反馈重试；组合起来却形成高风险能力。因此，治理必须覆盖行为链，而不是只检查单轮回答。

这项工作的特色是把模型差异、架构差异和环境扰动放在同一套基准里。它没有把代理能力归因于一个神秘的“智能程度”，而是拆成模型选择、方法匹配、规划、执行和环境依赖。这样的分解更适合工程团队，因为每一层都能对应测试、权限或监控措施。

不过，论文并没有回答所有现实问题。生产环境中的网络边界、身份系统、终端防护、告警响应和人工协作都比容器复杂；公开已知材料也不能代表未知缺陷。研究结果最适合作为相对比较、版本回归和防守流程设计依据，不适合作为真实入侵成功率预测器。

九、成本、复现与使用条件

论文还报告了不同模型在统一计价口径下的调用成本。成本最低的路线并不一定成功率最低，成功率最高的路线也不是每个类别都最划算。这提醒安全团队，自动化评估应同时记录成功率、平均步数、令牌消耗和单次成功成本。若只追求更多成功，代理可能通过大量重试堆出结果；若只追求便宜，又可能遗漏高风险类别。

成本指标也不能脱离时间与供应商版本。模型价格、路由策略和上下文长度都会变化，论文中的美元数字更适合解释相对资源消耗，不适合长期采购报价。企业复现时应冻结模型版本、计价日期、最大步数、超时策略和重试次数，并把这些条件写进结果元数据。

复现这类基准还需要注意隔离。论文使用无外网的Docker场景，并明确限制在公开已知材料中。企业内部测试应进一步使用专门账户、最小宿主权限、只读基础镜像、网络阻断和可销毁环境。测试凭据不能与生产凭据复用，日志中也不应留下可被二次利用的敏感信息。

开源仓库能帮助研究者检查场景结构与评测逻辑，但“代码公开”不等于可以直接接入生产红队。团队仍需审查容器配置、依赖、脚本权限和数据来源，并在隔离环境中逐步运行。尤其是自动执行模块，应先以只读观察和模拟结果开始，再决定是否允许更高权限动作。

在组织流程上，最稳妥的使用方式是把基准放进变更管理。模型版本、系统提示、工具列表、代理模块或权限发生变化时，自动触发分层回归；出现新成功场景时，由人工确认其业务相关性和修复优先级。这样做比每季度跑一次大测试更能捕捉代理能力的突然跃迁。

最后，评测团队和防守团队需要共同定义成功判据。研究基准倾向于用权限状态判断任务完成，企业还要加入告警是否触发、动作是否被阻断、凭据是否被撤销和响应时间等指标。一个代理即使达到技术目标，只要防护系统及时发现并隔离，整体业务风险就与“无声成功”不同。

十、龙哥点评

龙哥最认可的不是“531”这个大数字，而是它背后的验证闭环。自动构建安全场景很容易制造漂亮规模，真正困难的是证明每个场景有效、成功判据可信、修复后结果会反转。论文把这些检查做成流水线，才让后面的模型比较有了工程意义。

第二个重要判断是：企业级代理的风险不能只按基础模型定级，Harness工程能力本身就是核心变量。当枚举、路由、规划和记忆被补齐，原本弱势的模型可能获得很大提升。安全审批如果只登记模型名称，却不登记框架版本、工具和权限，等于只给发动机做年检，却忽略整辆车已经被改装。

这项工作的主要限制也很清楚。场景集中在容器化、公开已知材料和特定类别分布；SUID与Sudo占比较高，其他类别样本较少。固定步数预算、隔离环境和基准代理也会影响排名。论文可以告诉我们“在这套可复查条件下谁更强、为什么变化”，不能直接告诉某家企业下一季度会不会发生事故。

从落地角度看，最有价值的做法不是立刻追求更大的自动化红队，而是先把内部测试做准：有修复对照、有环境变体、有版本记录、有工具权限边界。测量准确之后，再讨论扩大覆盖和提高自动化率。否则，自动化只会更快地产生无法解释的数字。

对于研究者，这篇论文还留下一个值得继续追的问题：如果代理框架不断增强，基准是否也需要动态更新？静态场景可能很快被模板化。未来评测需要更多未见变体、跨版本回归、真实防护联动和更严格的安全执行机制，才能持续区分记忆、工具工程与真正的泛化能力。

十一、龙迷三问

第一问：模型成功率不高，是不是就可以放心开放更多权限？不能。低成功率是特定场景、框架和预算下的平均结果。更换框架、多次重试或路由模型都可能提升能力；权限设计应依据最小权限和业务风险，而不是依据当前榜单。

第二问：改路径、改名称、轮换配置，能不能挡住自动化代理？可以增加摩擦，但不能替代修补和隔离。论文中的成功保持率仍为59.0%至78.2%，说明一部分能力依赖环境线索，另一部分能适应变化。

第三问：企业最该复用论文里的哪一部分？不是复用某个攻击流程，而是复用测量方法：结构化场景、差分验证、修复对照、类别分层、未见变体和完整版本记录。它们能让内部红队结果更可信，也更容易转成整改任务。

总结：安全评测要从“模型名”走向“系统能力画像”

这项研究用531个经审计场景和329个环境变体，把大语言模型自动化Linux权限提升从零散演示推进到系统测量。论文证明了三件事：模型选择显著影响结果；代理架构可以大幅改写排名；环境扰动能降低一部分成功，却无法替代真正加固。

对防守团队而言，最值得带走的结论是：不要只问用了哪个模型，要问模型被接上了什么工具、规划、记忆、权限和回归机制。未来的安全风险越来越像系统工程问题。测量对象越完整、验证越严格，团队越能在能力被放大之前发现变化。

这篇论文没有给出生产系统的事故概率，也没有覆盖所有Linux配置和未知缺陷。但它提供了一套更可靠的起点：把能力拆开、把场景审准、把变化记清，再用最小权限和持续回归守住系统边界。

主要参考资料

本文基于龙哥读论文PaperDaily数据库及PaperMiner的MCP进行汇总整理。本文为论文解读与个人学习笔记，不构成任何论文审核意见，及对产品能力、安全性或商业可用性的保证。