JVM отладочный соединитель внутренности и безопасности - программирование

JVM отладочный соединитель внутренности и безопасности

Недавно я столкнулся с вопросом: отладка Java-приложения без запуска JVM с аргументами отладки.

Читая больше о различных соединителях и транспортных средствах, предлагаемых JVM по адресу https://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html, я сейчас пытаюсь найти ответы на следующие вопросы:

Документы говорят, что для SADebugServerAttachingConnector и SAPIDAttachingConnector:

Отлаживаемый процесс не нужно запускать в режиме отладки (т.е. С -agentlib: jdwp или -Xrunjdwp)

Так:

1) Почему параметры отладки, такие как Xrunjdwp существуют в первую очередь?

2) Как работает SADebugServerAttachingConnector, не принимая номер порта в аргументах?

3) В документации ничего не сказано о требовании root-прав. Разве это не серьезная уязвимость повышения привилегий, позволяющая произвольной отладке экземпляров jvm, не запущенных в режиме отладки, непривилегированными пользователями?

4b9b3361

ОТВЕТЫ

Ответ 1

Я сосредоточусь на случае SADebugServerAttachingConnector.

Вот еще несколько цитат из Java 11-версии документа, на который вы ссылаетесь:

Соединительный соединитель отладочного сервера SA

Этот соединитель может использоваться приложением отладчика для отладки файла процесса или файла ядра на компьютере, отличном от компьютера, на котором работает отладчик.

Этот соединитель использует RMI для связи с "сервером отладки", запущенным на удаленном компьютере. Перед вызовом метода attach() в этом соединителе необходимо запустить сервер отладки на удаленном компьютере и указать, какой процесс или файл ядра должен быть отлажен.

Отлаживаемый процесс не обязательно должен запускаться в режиме отладки (т.е. С -agentlib: jdwp или -Xrunjdwp).

1) Почему параметры отладки, такие как Xrunjdwp, существуют в первую очередь?

Метод SA Debug Server позволяет вам отлаживать процесс Java, когда вы либо не хотели запускаться с агентом (например, по соображениям безопасности), либо у вас не было предвидения для этого.

И наоборот, агентский подход предназначен для случаев, когда вы не хотите, чтобы установка SA Debug Server отлаживала ваше приложение Java.

Это "лошади для курсов"... как говорится.

2) Как работает SADebugServerAttachingConnector, не принимая номер порта в аргументах?

Ваш отладчик использует порт RMI по умолчанию для связи с SA Debug Server. Сервер отладки SA подключается к целевой JVM с помощью механизма, который известен серверу и цели. Скорее всего, это будет механизм под ОС. Например, в Linux он может использовать API-интерфейсы ptrace(2). Сетевые сокеты и порты не должны быть задействованы.

3) В документации ничего не сказано о требовании root-прав. Разве это не серьезная уязвимость повышения привилегий, позволяющая произвольной отладке экземпляров jvm, не запущенных в режиме отладки, непривилегированными пользователями?

В документации говорится, что вам необходимо специально установить связь между SA Debug Server и целевой виртуальной машиной. Это делается, когда вы запускаете SA Debug Server.

Элементы управления доступом на уровне ОС не позволят серверу отладки SA без полномочий root использовать (например) системные ptrace доступа к процессу Java, принадлежащему другому пользователю/идентификатору пользователя. И ОС не позволит вам запустить корневой отладочный сервер SA, если у вас уже нет привилегии root. Таким образом, повышения привилегий не происходит ни в корневых, ни в некорневых случаях.

(По модулю любые нераскрытые или не исправленные ошибки эскалации корневого уровня на уровне ОС... конечно.)