Могу ли я использовать файл политики Java для безопасного запуска ненадежного приложения с помощью sudo

Я запускаю приложение J2SE, которому доверяют (Minecraft), но которое, вероятно, будет содержать полностью ненадежные (и, вероятно, даже некоторые враждебные) плагины.

Я хотел бы создать плагин, который может получить доступ к контактам GPIO на Raspberry PI.

Каждое решение, которое я видел, требует, чтобы такому приложению были предоставлены sudo-superpowers, потому что доступ к gpio осуществляется через прямой доступ к памяти.

Похоже, правильное решение — предоставить параметр командной строки следующим образом:

-Djava.security.policy=java.policy

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

По сути, вы, кажется, даете Java полномочия «sudo», а затем доверяете модели безопасности java только для предоставления соответствующих полномочий различным классам. Я предполагаю, что это делает приложение безопасным для работы с sudo - это правильно?

Забавно, что я использую Java почти каждый день с версии 1.0 и никогда не нуждался в этом раньше... Каждый день узнаешь что-то новое.


linux java raspberry-pi minecraft java-security
person Bill K    schedule 15.02.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

[Отказ от ответственности: я не очень уверен в модели безопасности Java.]

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

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

Сокеты домена Unix, вероятно, лучший выбор, но если вы хотите chroot() приложение Java, может понадобиться сокет TCP/IP.

person 5gon12eder    schedule 15.02.2016
comment
Это было бы и моей первой мыслью, но, поскольку я работаю на Raspberry pi, а память — дефицитный ресурс, я пытался избежать запуска нескольких JVM. Если модель безопасности не работает, я, вероятно, попробую приложение C, которое делает именно то, что вы говорите, но я бы предпочел java. Есть ли у вас какие-либо конкретные проблемы с моделью безопасности Java? Все еще хорошее предложение, я проголосую за него :) - person Bill K; 16.02.2016
comment
Мое предположение заключалось в том, что демон будет написан на C, поэтому его накладные расходы должны быть сравнительно низкими. Вам все равно не нужно идти на C для доступа к оборудованию? У меня нет негативного опыта, который я могу процитировать, но я думаю, что если присутствует механизм безопасности на уровне ОС, его следует использовать, а имитировать его на уровне приложения — худшее решение. Люди, более вовлеченные в это, неофициально сказали мне, что обойти ограничения JVM «легко», но я не компетентен говорить об этом. - person 5gon12eder; 16.02.2016
comment
Доступ к оборудованию, похоже, осуществляется через /dev/mem и уже реализован в библиотеках Java. Конечно, это также реализовано в библиотеках C - и, возможно, даже как некий сервис, но я бы предпочел остаться с Java, если эта защита памяти действительно работает - меньше движущихся частей, более простая сборка, и я могу чему-то научиться. новый :) - person Bill K; 16.02.2016