system类是编程语言中封装系统操作的抽象类，其安全边界由宿主进程的操作系统权限（windows访问令牌/linux uid/gid）及安全策略决定，而非自身具备权限模型。
System 类本身不是 Windows 或 Linux 中的用户账户或进程实体，而是编程语言（如 Java、C#）中用于封装系统级操作的抽象类。它不直接参与操作系统访问控制，但其调用行为会落入底层系统的安全机制约束中。真正决定“谁可以访问什么资源”的，是运行该 System 类代码的执行上下文——即当前进程所持有的访问令牌（Windows）或有效 UID/GID（Linux），以及对应的安全策略。
System 类调用受制于宿主进程权限
Java 的 System 类中如 System.getProperty()、System.getenv()、System.loadLibrary() 等方法，看似“系统级”，实则依赖 JVM 所在进程的操作系统权限。例如：
- 调用
System.getenv("PATH")能否读取环境变量，取决于进程是否有权访问该变量——普通用户进程无法读取被标记为“受限”的系统级环境项； - 执行
System.loadLibrary("malware")加载本地 DLL/SO，需满足：文件路径可访问 + 文件具有执行权限 + 进程拥有加载特权（如未启用 DEP/ASLR 保护时更危险）； -
System.exit(0)触发进程终止，其成败取决于操作系统是否允许该进程自行结束——沙箱环境（如 Android App、浏览器 Web Worker）会拦截此类调用。
关键安全边界在操作系统层而非语言层
System 类自身无权限模型，它的安全性完全由运行时环境保障：
- 在 Windows 上，JVM 进程若以 SYSTEM 账户运行，则其调用的 System 方法可访问注册表
HKEY_LOCAL_MACHINE、服务控制管理器等高敏资源；若以普通 User 运行，则受 ACL 和 UAC 限制，多数写操作会被拒绝； - 在 Linux 上，JVM 进程若以 root 启动，
System.loadLibrary()可加载任意路径的 SO；若以非特权用户启动，即使代码尝试 open("/etc/shadow")，也会因内核权限检查失败而返回Permission denied； - 容器或沙箱（如 Docker、Android SELinux 域）进一步收紧边界：即便进程 UID=0，也可能被 seccomp-bpf 拦截
openat或mmap系统调用，使 System 类相关功能直接失效。
开发与部署中的实际防护要点
防范 System 类引发的安全风险，重点不在禁用该类，而在管控其执行环境：
- 避免以 Administrator / root 身份长期运行含 System 调用的应用，尤其处理不可信输入时；
- 对
System.getenv()和System.getProperty()返回值做严格校验，防止路径遍历（如拼接进File构造）、命令注入（如传入Runtime.exec()）； - 禁用不必要的 native 库加载：JVM 参数
-Djna.nosys=true、-Djna.loaded=true可限制 JNA 行为；生产环境应移除未签名的.dll/.so； - 启用操作系统级审计：Windows 事件日志记录
Process Creation和Registry Modification；Linux 启用 auditd 监控execve和openat调用，追踪 System 类背后的真实系统行为。
System 类只是入口，真正的权限闸门始终在操作系统内核和安全策略引擎里。
