2016-02-15 11 views
2

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

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

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

Похоже, что правильным решением будет поставить параметр командной строки, как это:

-Djava.security.policy=java.policy 

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

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

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

ответ

1

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

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

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

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

+0

Это была бы моя первая мысль, но, поскольку я бегу по малине pi, а память - скудный ресурс, я пытался избежать разворота нескольких JVM. Если элемент модели безопасности не работает, я, вероятно, попробую приложение C, которое сделает только то, что вы говорите, но я бы предпочел java. Есть ли у вас какие-либо конкретные проблемы с моделью безопасности Java? Еще хорошее предложение, я проголосую :) –

+0

Мое предположение заключалось в том, что демон будет написан на C, поэтому его накладные расходы должны быть сравнительно низкими. Разве вам не нужно идти на C для доступа к аппаратным средствам? У меня нет негативных впечатлений, которые я могу процитировать, но я думаю, что если присутствует механизм безопасности на уровне ОС, его следует использовать и подражать ему на уровне приложения - это более низкое решение. Люди, более связанные с этим, говорили мне неформально, что из-за ограничений JVM «легко», но я не компетентен говорить об этом. – 5gon12eder

+0

Доступ к аппаратным средствам осуществляется через/dev/mem и уже реализован в java-библиотеках. Конечно, он также реализован в библиотеках C - и, возможно, даже как услуга какого-то типа, но я бы предпочел остаться с Java, если этот материал защиты памяти действительно работает - менее подвижные части, более простая сборка, и я узнаю что-то новый :) –

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

  • Нет связанных вопросов^_^