Как разумно настроить политику безопасности в Tomcat 6

Question

Я использую Tomcat 6.0.24 в комплекте с Ubuntu Karmic. Политика безопасности по умолчанию для пакета Tomcat в Ubuntu довольно строгая, но выглядит просто. В /var/lib/tomcat6/conf/policy.d существует множество файлов, которые устанавливают политику по умолчанию.

Стоит отметить в начале:

• Я вообще не менял стандартную установку tomcat - никаких новых jar-файлов в общий каталог (-и) lib, никаких изменений server.xml и т. Д. Размещение .war-файла в каталоге webapps - единственное действие по развертыванию.
• развертываемое мной веб-приложение завершается неудачно с тысячами отказов в доступе в соответствии с этой политикой по умолчанию (как сообщается в журнале благодаря системному свойству -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

Используете ли вы версию Ubuntu с управлением пакетами? Недавно у нас был кошмар с защитой, но мы обнаружили, что при загрузке Tomcat отдельно и использовании этого, проблемы безопасности исчезли.

Подтверждение:

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

Если вы работаете в Ubuntu и хотите использовать контейнер сервлета 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";
}

Если это не сработает, то может случиться так, что некоторый код за пределами того, что покрывает ваша существующая гранта, обращается к этим файлам свойств (например, сервлет или другой код библиотеки).

В качестве обходного пути и для подтверждения, если это так, вы можете сделать прямой грант на .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

Tomcat работает с собственным пользователем tomcat. Файлы war должны быть видны этому пользователю - возможно, стоит сначала проверить это?