如何在Tomcat中合理配置安全策略6

Question

我使用的是爲Ubuntu Karmic打包的Tomcat 6.0.24。 Ubuntu的Tomcat包的默認安全策略非常嚴格，但看起來很簡單。在/var/lib/tomcat6/conf/policy.d中，有多種文件可以建立默認策略。

值得注意的開始：

• 我沒有改變股票的tomcat安裝在所有 - 沒有新的罐子到其共同的lib目錄（IES），無server.xml變化等把。 webapps目錄中的war文件是唯一的部署操作。
• 我正在部署的Web應用程序失敗，在此默認策略下有數千個訪問拒絕（由於系統屬性爲-Djava.security.debug="access,stack,failure"，因此被報告給日誌）。
• 完全關閉安全管理導致沒有錯誤無論如何，和適當的應用功能

我希望做的是應用特定的安全策略文件添加到policy.d目錄，這似乎是建議的做法。我說這policy.d/100myapp.policy（作爲起點 - 我想授予權限，最終修剪回只什麼應用程序的實際需要）：

grant codeBase "file:${catalina.base}/webapps/ROOT.war" { 
    permission java.security.AllPermission; 
}; 

grant codeBase "file:${catalina.base}/webapps/ROOT/-" { 
    permission java.security.AllPermission; 
}; 

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/-" { 
    permission java.security.AllPermission; 
}; 

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/lib/-" { 
    permission java.security.AllPermission; 
}; 

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/-" { 
    permission java.security.AllPermission; 
}; 

注意顛簸各地試圖找到合適的codeBase聲明。我認爲這可能是我的根本問題。

無論如何，以上（真的只有前兩個贈款似乎有任何效果）幾乎作品：成千上萬的訪問拒絕消失了，我剩下的只有一個。有關堆棧跟蹤：

java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat6/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt read) 
    java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) 
    java.security.AccessController.checkPermission(AccessController.java:546) 
    java.lang.SecurityManager.checkPermission(SecurityManager.java:532) 
    java.lang.SecurityManager.checkRead(SecurityManager.java:871) 
    java.io.File.exists(File.java:731) 
    org.apache.naming.resources.FileDirContext.file(FileDirContext.java:785) 
    org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:206) 
    org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:299) 
    org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1937) 
    org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:973) 
    org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1108) 
    java.lang.ClassLoader.getResource(ClassLoader.java:973) 

我敢確信，多數民衆贊成觸發拒絕的實際文件是不相關的 - 它只是一些配置文件，我們檢查可選的配置參數。有趣的是：

1. 它不會在這方面
2. 的事實，文件不存在，最終拋出一個安全異常，而不是java.io.File.exists()簡單地返回false（雖然我認爲這只是存在這是讀取權限的語義問題）。

另一個解決方法（除了剛剛禁止Tomcat中的安全管理器）是一個開放式的許可添加到我的政策文件：

grant { 
    permission java.security.AllPermission; 
}; 

我想這是功能上等同於關閉安全管理器。

我想我必須在我的贈款中獲得codeBase聲明微妙的錯誤，但我目前沒有看到它。

Answer 1

Tomcat以自己的tomcat用戶運行。戰爭檔案需要對使用者可見 - 可能值得首先檢查嗎？

Answer 2

您是直接部署到ROOT目錄嗎？

通常當你在webapps文件夾中打一個戰爭，比如說100myapp.war，它會解壓到一個名爲100myapp的文件夾。那麼不應該在這個新文件夾而不是ROOT文件夾中完成授權嗎？

Answer 3

您可能需要單獨授予文件訪問權限。試着改變被授予您的應用：

grant codeBase "file:${catalina.base}/webapps/ROOT.war" { 
    permission java.security.AllPermission; 
    permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/-", "read, write"; 
} 

如果不工作，那麼它可能是你現有的補助金支付外什麼一些代碼訪問這些屬性文件（如servlet或其他庫代碼） 。

作爲一種變通方法，並確認，如果是這樣的話，你可以做對的.properties直批這是造成你的問題：

grant { 
    permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt", "read, write"; 
} 

看來其實後者可能是因爲堆棧跟蹤顯示了Tomcat上下文加載器中的代碼。如果.properties上的直接授權有效，您可能希望將授權鎖定到org.apache.naming.resources.FileDirContext。

你是否獲得了特定於你自己的代碼的任何堆棧跟蹤？

Answer 4

您是否使用Ubuntu的軟件包管理版本？我們最近用惡意軟件進行了惡夢，但發現通過單獨下載Tomcat並使用它，安全問題就消失了。

佐證：

http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/

如果您正在運行Ubuntu，並希望使用Tomcat servlet容器，你不應該使用的版本從倉庫，因爲它只是不能正常工作。相反，您需要使用我在這裏概述的手動安裝過程。