探索 Java 應用程式安全需求：自訂 SecurityManager 實戰剖析

前言：安全防禦的多層次策略

維護應用程式安全非易事，但可採取措施緩解風險。網路工程師專注分區與封包過濾，C 語言開發者防範緩衝區溢位，而 Java 開發者則依賴安全管理器在運行時強制執行權限控制。每種情況下，皆以領域最佳實踐對抗非預期系統故障。本文聚焦 Java 安全架構的核心子集——java.lang.SecurityManager，探討如何透過自訂安全管理器剖析應用程式真實安全需求。

Java 安全管理器核心機制

• 繼承自 java.lang.SecurityManager 或其子類
• 運行時檢查應用程式操作權限（檔案讀寫、網路連線、系統屬性存取等）
• 僅允許安全策略檔案明確許可的操作
• 單一 JVM 參數 `-Djava.security.manager` 即可啟用
• 策略檔案為純文字，任何文字編輯器即可建立

預設安全管理器的限制實測

// PrintHome.java
public class PrintHome {
    public static void main(String[] argv) {
        System.out.println(System.getProperty("user.home"));
    }
}

$ javac PrintHome.java
$ java -Djava.security.manager PrintHome
Exception in thread "main" java.security.AccessControlException: 
    access denied (java.util.PropertyPermission user.home read)

預設策略禁止讀取 `user.home`。需建立策略檔 `policy.txt`：

grant codeBase "file:/home/cid/Projects/CustomSecurityManager/" {
    permission java.util.PropertyPermission "user.home", "read";
};

$ java -Djava.security.policy=policy.txt -Djava.security.manager PrintHome
/home/cid

痛點：策略制定的「黑盒」困境

編寫策略檔不難，工具（如 Policy Tool）亦可輔助。但高階語法捷徑（遞歸目錄 URL、通配符）掩蓋了真實細粒度資源需求。開發者往往授予過度權限（最小權限原則違背），或遺漏關鍵權限導致運行時異常。核心挑戰：如何程式化、精確地發現應用程式的真實安全需求？

解決方案：ProfilingSecurityManager 設計與實作

設計理念

• 繼承 SecurityManager，但不執行策略阻擋
• 假設應用程式有權存取其請求的所有資源
• 記錄每次權限檢查請求，輸出策略規則草稿
• 應用程式完成運行後，整理輸出為最終策略基準

核心實作要點

// 關鍵邏輯：過濾自身產生的權限檢查，避免干擾
if (url.toString().equals(thisCodeSourceURLString)) {
    return null; // 忽略自身代碼庫產生的檢查
}

編譯打包為獨立 JAR (`psm.jar`)，啟動方式：

java -cp .:lib/psm.jar -Djava.security.manager=secmgr.ProfilingSecurityManager ...

搭配 Perl 腳本 `parsecodebase.pl` 聚合、格式化、按代碼庫分類輸出規則。

實戰驗證：PrintHome 程式的安全畫像

$ java -cp .:lib/psm.jar -Djava.security.manager=secmgr.ProfilingSecurityManager PrintHome
/home/cid

輸出策略規則（經腳本處理）：

grant codeBase "file:/home/cid/Projects/CustomSecurityManager/" {
    permission java.util.PropertyPermission "user.home", "read";
};

完美還原真實需求，零冗餘、零遺漏。

進階應用場景與價值

1. 遺留系統安全遷移：無文件舊系統，運行剖析器自動生成基準策略
2. 第三方元件安全評估：隔離運行可疑 Jar，分析其權限需求決定是否引入
3. 最小權限原則落地：以剖析結果為起點，人工審核精簡為生產策略
4. 安全回歸測試：版本升級前後對比權限畫像，偵測非預期權限擴張
5. 開發階段即時反饋：IDE 整合剖析器，編碼時即見權限需求

技術深度：Reflection API 的必要性與風險

• 需存取 Sun JSE 5 JVM 內部私有成員（如 `ProtectionDomain` 內部結構）
• 使用 Reflection 破壞封裝，導致剖析器與特定 JVM 版本緊耦合
• 可接受權衡：剖析器屬開發工具而非產品組件，生產環境使用生成的標準策略檔，可在任何現代 JVM 運行

現代化延伸：Java 17+ 的安全模型演進

注意：Java 17 標記 `SecurityManager` 為棄用，Java 21 移除。現代替代方案：

• 模組系統封裝：`module-info.java` 控制封裝開放度
• 原生存取控制：`java.lang.foreign` 替代 JNI
• 容器級沙箱：gVisor、Kata Containers、WebAssembly 運行時
• 供應鏈安全：SBOM、簽名驗證、可重現建構

但剖析思維永不過時：無論機制如何演進，「觀察真實行為、推導最小權限」的方法論持續適用。

結語

ProfilingSecurityManager 展示了「觀察優於推測」的安全工程哲學。透過自訂安全管理器記錄真實權限請求，我們將策略制定從「經驗猜測」轉為「數據驅動」。雖然 Java 安全模型正在演進，但最小權限原則與行為剖析方法論，將持續指引我們構建更安全的系統。