2016-09-28 4 views
0

Как проверить, вводится ли javaagent в JVM или отключить присоединение javagents? Я пытаюсь предотвратить изменение моего приложения во время выполнения из-за соображений безопасности.Как предотвратить javaagent от прикрепления?

Я знаю, как предотвратить загрузку javaagent при запуске, но мне не удалось найти способ предотвратить динамическое присоединение VirtualMachine API.

У кого-нибудь есть идеи?

+0

В [java.lang.instrument] (http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html) указаны довольно строгие условия для возможности динамически присоединить javaagent - см. «Стартовые агенты после запуска VM» Мне кажется, что ответ может быть: «не выполнив хотя бы одно такое условие - предпочтительнее всего». Каков ваш опыт? (как получилось, что у вас все еще есть javaagents?) –

+0

@Adrian Colomitchi Читая требуемые условия, кажется, что я могу управлять только одним (загрузчиком классов). Я не слишком уверен в Classloaders, поэтому писать мой собственный загрузчик классов, который предотвращал добавление контейнеров агентов в путь к классам, кажется сложной задачей. В частности, я буду беспокоиться о том, чтобы запретить добавление законных библиотек. У вас есть какие-то советы по этому поводу? – Stoud

+0

Зачем вам это нужно? «В частности, я буду беспокоиться о том, чтобы запретить добавление законных библиотек». Конечно. Итак, кто, но клиент, находится в лучшем положении, чтобы заботиться о том, что является законным или не легитимным использованием дополнительных библиотек? Другими словами, почему подчеркнутый абзац в документации о «как и что» будет недостаточным? Вы пишете приложение безопасности? Если нет, я думаю, что безопасно допускать эту ответственность с вашими пользователями, просто документировать ее и позволять им заботиться. –

ответ

0

На HotSpot вы можете установить -XX:+DisableAttachMechanism и на J9, вы можете отключить вложение через -Dcom.ibm.tools.attach.enable=no, но нет способа отключить его для любой виртуальной машины. То, что вы могли бы сделать, было бы инструментом любого класса с помощью метода premain(String, Instrumentation, чтобы он не передавался фактическим экземпляром интерфейса инструментария или null. Я бы, однако, не рекомендовал, это нарушит общий контракт API API.

Однако ничто из этого не повышает безопасность. Вложение требует, чтобы другой процесс с привилегиями для доступа к вашему JVM-процессу выполнялся на одном компьютере. Если это так, и этот другой процесс является злоумышленником, API-интерфейс инструментария - последняя проблема, о которой вы должны беспокоиться. Кроме того, если вы поддерживаете библиотеку, пользователь вашей библиотеки уже имеет полный доступ к вашему коду и возможность его изменения до запуска вашего кода.

Поэтому, несмотря на то, что может отключить вложение, нет никакой выгоды в этом, чтобы «повысить безопасность».

+0

Я не уверен, что согласен, я всегда могу проверить, что все хэши соответствуют тому, что должно быть, поэтому я могу помешать им изменить библиотеку. – Stoud

+0

Если я могу изменить вашу библиотеку, я могу изменить свои хеши. Лучшее, что вы можете здесь сделать, это безопасность от неизвестности. Если VM может запустить ваш код, я могу его извлечь. –

+0

За исключением изменения хэшей вы изменяете сохраненную программу, которую может также проверить работающая программа. Пока существует непрерывный процесс с немодифицированной средой выполнения, я думаю, что было бы довольно сложно обойти. – Stoud

Смежные вопросы