Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
| СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
Менеджер безопасности автоматически не устанавливается, когда приложение работает. Чтобы применить ту же самую политику безопасности к приложению, найденному на локальной файловой системе относительно загруженных апплетов, любой, пользователь, запускающий приложение, должен вызвать виртуальную машину Java с новым "-Djava.security.manager" параметром командной строки (который устанавливает значение java.security.manager свойства), как в
java -Djava.security.manager SomeApp
или само приложение должно вызвать setSecurityManager метод в java.lang. Система class, чтобы установить менеджера безопасности. Возможно определить на командной строке определенного менеджера безопасности, который будет использоваться, следующим "-Djava.security.manager" с равнянием и именем class, который будет использоваться в качестве менеджера безопасности, в качестве в
java -Djava.security.manager=COM.abc.MySecMgr SomeApp
Если никакой менеджер безопасности не определяется, встроенный менеджер безопасности значения по умолчанию используется (если приложение не устанавливает различного менеджера безопасности). Все следующее эквивалентно и результат в использовании менеджера безопасности значения по умолчанию:
java -Djava.security.manager SomeApp
java -Djava.security.manager="" SomeApp
java -Djava.security.manager=default SomeApp
Java 2 SDK включает свойство, названное java. class.path. Классы, которые сохранены на локальной файловой системе, но не должны быть обработаны как базовые классы (например, классы, встроенные в SDK), должны быть на этом пути. Классы на этом пути загружаются безопасным загрузчиком class и таким образом подвергаются осуществляемой политике безопасности. Есть также "-Djava.security.policy" параметр командной строки, использование которого определяет, какие файлы политики используются. Этот параметр командной строки описывается подробно в "Системном и Пользовательском разделе" Файлов Политики значения по умолчанию. В основном, если Вы не будете включать "-Djava.security.policy" на командной строке, то тогда файлы политики, определенные в файле свойств безопасности, будут использоваться.
Можно использовать "-Djava.security.policy" параметр командной строки, чтобы определить дополнительное или различный файл политики, вызывая выполнение приложения. Например, если Вы введете следующий, где ИЗНАНОЧНОЙ ВЯЗКОЙ является URL, определяющий расположение файла политики, то тогда указанный файл политики будет загружен в дополнение ко всем файлам политики, определенным в файле свойств безопасности:
java -Djava.security.manager -Djava.security.policy=pURL SomeApp
Если Вы вместо этого вводите следующую команду, используя двойное равняется, то только указанный файл политики будет использоваться; все другие будут проигнорированы: java -Djava.security.manager -Djava.security.policy==pURL SomeApp
check методы в SecurityManager все еще поддерживаются, хотя большинство их реализаций изменяется, чтобы вызвать новый SecurityManager checkPermission метод, реализация по умолчанию которого вызывает AccessController checkPermission метод. Отметьте, что определенные проверки внутренней безопасности могут остаться в SecurityManager class, если это не может быть параметризовано. Мы не имеем в это время, пересмотренное никакой системный код, чтобы вызвать AccessController вместо того, чтобы вызвать SecurityManager (и проверить на существование classloader) из-за потенциала существующих сторонних приложений, которые разделяют SecurityManager на подклассы и настраивают check методы. Фактически, мы добавили новый метод SecurityManager.checkPermission это по умолчанию просто вызывает AccessController.checkPermission.
Чтобы понять отношение между SecurityManager и AccessController, достаточно отметить, что SecurityManager представляет понятие центральной точки управления доступом, в то время как AccessController реализует определенный алгоритм управления доступом со специальными функциями такой как doPrivileged метод. Совершенствуя SecurityManager, мы поддерживаем обратную совместимость (например, для тех приложений, которые записали их собственные классы менеджера безопасности, основанные на более ранних версиях JDK), и гибкость (например, для кого-то желающего настроить модель обеспечения безопасности, чтобы реализовать мандатное управление доступом или многоуровневую безопасность). Предоставляя AccessController, мы создаем в алгоритме, которому мы верим, является самым рестриктивным, и это освобождает типичного программиста от бремени необходимости записать обширный код в системе защиты в большинстве сценариев.
Мы поощряем использование AccessController в коде программы, в то время как настройка менеджера безопасности (через разделение на подклассы) должна быть последним средством и должна быть сделана с большой осторожностью. Кроме того специализированный менеджер безопасности, такой как тот, который всегда проверяет время дня прежде, чем вызвать стандартные проверки безопасности, мог и должен использовать алгоритм, обеспеченный AccessController всякий раз, когда приспособлено.
Более обширная документация для инструментов может быть найдена в
/docs/technotes/tools/solarisи
/docs/technotes/tools/windowsподкаталоги SDK выпускают каталог (где разделители каталога фактически "\" на системах Windows).
Например, если Java, 2 SDK устанавливаются в каталоге, названном "/j2sdk1.2" на системе Соляриса, то keytool документация для Соляриса и пользователей Windows, соответственно, может быть найдена в
/j2sdk1.2/docs/tooldocs/solaris/keytool.html /j2sdk1.2/docs/tooldocs/windows/keytool.htmlЕсли Java, 2 SDK устанавливаются в каталоге по имени "C:\j2sdk1.2" на системе Windows, то keytool документация для Соляриса и пользователей Windows, соответственно, может быть найдена в
C:\j2sdk1.2\docs\tooldocs\solaris\keytool.html C:\j2sdk1.2\docs\tooldocs\windows\keytool.html
keytool хранит ключи и сертификаты в так называемом keystore. Значение по умолчанию keystore реализация реализует keystore как файл. Это защищает закрытые ключи с паролем.
Цепочки сертификатов X.509 обеспечиваются организациями под названием Центры сертификации, или Идентификационные данные АВАРИИ (включая АВАРИЮ) используют свои закрытые ключи, чтобы аутентифицировать их ассоциацию с объектами (такой как с каналами, которые защищаются, используя SSL), с архивами кода, который они подписали, или (для АВАРИИ) с сертификатами X.509, которые они выпустили. Как инструмент начальной загрузки, может использоваться сгенерированное использование сертификатов-genkey команды, пока Центр сертификации не возвращает цепочку сертификата.
Закрытые ключи в этой базе данных всегда сохранены в зашифрованной форме, чтобы мешать раскрывать эти закрытые ключи неуместно. Пароль обязан доступ, или измените базу данных. Эти закрытые ключи шифруются, используя "пароль", который должен быть несколькими словами долго. Если пароль теряется, те ключи аутентификации не могут быть восстановлены.
Фактически, каждый закрытый ключ в keystore может быть защищен, используя его собственный отдельный пароль, который может или, возможно, не является тем же самым как паролем, который защищает полную целостность keystore.
Этот инструмент (в настоящий момент) предназначается, чтобы использоваться из командной строки, где каждый просто вводит "keytool" как приглашение оболочки. keytool является сценарием, который выполняет соответствующие классы Java и создается вместе с SDK.
Параметры командной строки для каждой команды могут быть обеспечены в любом порядке. Вводя неправильную опцию или вводя "keytool - справка" заставит использование инструмента быть полученным в итоге на устройстве вывода (таком как окно оболочки), как данным ниже.
% keytool -help
KeyTool usage:
-certreq [-v] [-alias <alias>] [-sigalg <sigalg>]
[-file <certreq_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-delete [-v] -alias <alias>
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-export [-v] [rfc] [-alias <alias>] [-file <cert_file>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-genkey [-v] [-alias <alias>] [-keyalg <keyalg>]
[-keysize <keysize>] [-sigalg <sigalg>]
[-dname <distinguished_name>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>]
[-storetype <i>storetype</i>]
-help
-identitydb [-v] [-file <idb_file>] [-keystore <keystore>]
[-storepass <storepass>]
[-storetype <i>storetype</i>]
-import [-v] [-noprompt] [-alias <alias>]
[-file <cert_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-keyclone [-v] [-alias <alias>] -dest <dest_alias>
[-keypass <keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-keypasswd [-v] [-alias <alias>]
[-keypass <old_keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-list [-v | -rfc] [-alias <alias>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-printcert [-v] [-file <cert_file>]
-selfcert [-v] [-alias <alias>] [-sigalg <sigalg>]
[-dname <distinguished_name>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>]
[-storetype <i>storetype</i>]
-storepasswd [-v] [-new <new_storepass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
policytool. Это снова - сценарий, созданный с SDK, который вызывает соответствующие (непубличные) классы реализации. См. документацию PolicyTool для информации об использовании и примеров с актуальными снимками экрана. Документация может быть найдена в policytool.html файл в
/docs/technotes/tools/solaris/или
/docs/technotes/tools/windows/каталог в каталоге, в котором был установлен SDK (где разделители файлов являются фактически наклонными чертами влево на системах Windows).
% jarsigner
Usage: jarsigner [options] jar-file alias
jarsigner -verify [options] jar-file
[-keystore <url>] keystore file location
[-storepass <password>] password for keystore integrity
[-keypass <password>] password for private key (if different)
[-sigfile <file>] name of .SF/.DSA file
[-signedjar <file>] name of signed JAR file
[-verify] verify a signed JAR file
[-verbose] verbose output when signing/verifying
[-certs] display certificates when verbose and verifying
[-internalsf] include .SF file inside signature block
[-sectionsonly] don't compute hash of entire manifest
Снова, этот инструмент является сценарием, созданным с SDK. Отметьте, что ожидается, что этот инструмент и существующий сценарий инструмента фляги могут быть объединены в ближайшем будущем, чтобы сформировать единственную командную строку, примитивную, чтобы создать JAR, или подписанные или без знака.