如何限制grim仅从交互式Shell启动？安全防护相关技术问询

1. 原则上，使用AppArmor能否实现该限制？ #

可以实现，但需要精准的规则来区分交互式Shell与其他进程的上下文差异。

交互式Shell的核心特征包括：关联真实的交互式TTY（如/dev/pts/*设备）、存在$PS1环境变量、父进程为用户登录后的终端模拟器（如foot、Alacritty）或登录Shell进程。AppArmor可以通过以下方式构建规则：

• 在grim的profile中，限制其执行权限仅授予满足TTY关联条件的进程，例如通过allow execute ... if exists /proc/<pid>/fd/0 (char)检查标准输入是否指向交互式终端；
• 结合环境变量校验，比如要求$PS1存在且非空，同时排除常见脚本Shell的环境特征；
• 限定父进程的可执行路径，比如仅允许从/bin/bash、/usr/bin/zsh等交互式Shell的二进制路径启动。

需要注意的是，Wayland环境下grim需要访问Wayland socket（通常位于$XDG_RUNTIME_DIR/wayland-0），规则中必须包含该路径的访问权限，否则grim即使被允许启动也无法正常工作。

2. 相较于依赖交互式Shell，使用特定的“解锁/启动”应用来处理参数传递并启动目标应用是否更优？ #

两种方案各有优劣，专用启动器的方案在安全性上更具优势：

依赖交互式Shell的优缺点 #

• 优势：无需额外开发工具，直接利用现有Shell的上下文特征实现限制，配置成本较低；
• 劣势：边界模糊，恶意程序可通过模拟交互式Shell的环境变量、伪造TTY关联等方式绕过限制，规则的维护成本高，容易出现漏判。

专用启动器方案的优缺点 #

• 优势：边界清晰，可通过用户交互验证（如弹出确认对话框、要求输入密码）确保只有用户主动触发时才启动grim；启动器可统一处理参数校验，防止恶意参数传递；在Sway中可将快捷键绑定到启动器，而非直接绑定grim，进一步缩小调用入口；
• 劣势：需要额外配置或开发简单工具，比如用zenity或wofi实现确认弹窗，或者基于Polkit做权限校验，但实现成本并不高。

整体来看，专用启动器方案的安全性更可靠，尤其适合Wayland环境下的截图工具保护场景。

3. 恶意应用可能通过何种方式绕过限制？是否可以通过启动交互式Shell来间接启动受保护的grim？ #

恶意应用确实可以通过启动交互式Shell间接调用grim，例如执行bash -i -c grim，如果你的规则仅校验父进程为交互式Shell，这种方法就能直接绕过。

除此之外，常见的绕过手段包括：

• 伪造交互式Shell的环境变量：手动设置$PS1、$TERM等变量，模拟交互式上下文；
• 伪造TTY关联：打开一个终端设备文件并将其绑定到标准输入/输出，伪装成交互式终端；
• 进程注入：将代码注入到合法的交互式Shell进程中，由Shell进程间接调用grim；
• 篡改或复制grim二进制：如果AppArmor规则仅限制原路径的grim，恶意程序可复制grim到其他路径执行。

应对方法 #

• 结合多维度校验：同时检查父进程的终端模拟器路径、TTY的所有者、环境变量的真实性，而非单一条件；
• 加入用户交互：使用启动器要求用户手动确认（如点击弹窗），即使恶意程序启动Shell，也无法自动完成用户交互步骤；
• 限制grim的文件权限：将grim的执行权限仅开放给特定用户组，同时用AppArmor限制只有启动器进程可执行grim。

内容的提问来源于stack exchange，提问作者Minithoup