У JVM есть особенности, чтобы только выполнить белый список файлов?

Из-за проблем безопасности, я должен найти способ ограничить, какими файлами JVM будет управлять. У меня есть приблизительно 5 банок, которыми можно управлять, и ничто иное не должно быть в состоянии работать на JVM. Это происходит из-за некоторых проблемно-ориентированных ограничений, где конкретные разрешения должны быть назначены на JVM, но эти разрешения не должны быть доступны никому, кто хочет написать и выполнить явский файл.

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

Если бы у кого-либо есть какие-либо идеи, которые были бы большими!

7
nl ja de
Вы могли быть более конкретны относительно того, что увеличило разрешения, которые вы назначили на JVM? Вы говорите о создании явского исполняемого файла setuid или чего-то как этот?
добавлено автор Kenster, источник
We' ре используя внешнюю программу, чтобы зашифровать чувствительные части файловой системы. Для моей Явской программы нужны разрешения этой внешней программы, чтобы прочитать зашифрованные файлы. Проблема заключается в том, допуская, что доступ JVM к этим файлам означает, что любая явская программа будет в состоянии прочитать зашифрованные файлы. Таким образом, я хотел бы сказать JVM, только управлять этими БАНКАМИ. Или, только управляйте БАНКАМИ, подписанными с этим свидетельством или чем-то подобным.
добавлено автор Sloppy, источник

2 ответы

Если вы не должны быть в состоянии прочитать код от других БАНОК, можно использовать a SecurityManager предотвратить чтение любой другой БАНКИ или погрузку класса из справочника. Вы захотите ограничить размышления и погрузку общих библиотек также, чтобы предотвратить погрузку классов вручную.

5
добавлено
@Sloppy, Если вы can' t управляют командной строкой, все ставки выключены. Пользователь может управлять примерно чем-либо из командной строки (не просто Ява) я wouldn' t предоставляют доступ командной строки к пользователям, которым не доверяют.
добавлено автор Peter Lawrey, источник
Это что you' ре, взаимодействующее с тем, когда вы создаете java.policy файл?
добавлено автор Alex, источник
Can' t менеджер безопасности быть отвергнутым, посылая аргумент JVM?
добавлено автор Sloppy, источник
@Peter положительная сторона Lawrey, мы на самом деле don' t выделяют доступ командной строки. I' ll должны более тесно посмотреть на SecurityManager.
добавлено автор Sloppy, источник

Я думаю дело не в этом простой... Если вы не управляете терминалом completly, вы не можете защитить Яву с СМ. Например, Исконный classloader классы грузов, которые не подвергаются проверкам СМ и многим другим проверкам... Таким образом, пользователь может добавить lib в bootclasspath, у которого будут все привилегии.... (Например: папка классов или папка lib в явской инсталляции, он может даже отвергнуть Яву.* пакет, если он владеет jvm),

То, что можно сделать:

  • Запутывает ваш код
  • Использование скрытый API к вашему явскому приложению (не 'Ява - банка myapp.jar "/path/to/file/to/encrypt"')

И вы все еще не на 100% безопасны..., весь код может быть перепроектирован и алгоритм, и ключи извлечены, все, что можно сделать, затрудняют достаточно, что это больше не будет привлекательно.

РЕДАКТИРУЮТ

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

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

1
добавлено
Так вы don' t должен изменить разрешения в jvm (that' s, что СМ делает), но, разрешения в рамках этого специального программного обеспечения, чтобы управлять только отобранным jar' s? Тогда it' s до этого способности к программам, если это может быть сделано...
добавлено автор fatfredyy, источник
Спасибо за информацию о classloading я буду иметь это в виду... Шифрование не на самом деле управляемо пользователями, это - сторонний пакет программного обеспечения, который шифрует целые файловые системы и включает систему, чтобы назначить разрешения (чтение-запись) на конкретные программы. Проблема здесь, всеми Явскими программами управляет JVM, таким образом, мы don' t хотят дать полные полномочия JVM, если кто-либо может просто написать их собственную часть Явского кода, чтобы использовать в своих интересах полный доступ.
добавлено автор Sloppy, источник
pro.jvm
pro.jvm
3 503 участник(ов)

Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш сайт: projvm.com projvm.ru Наш канал: @proJVM Вакансии: @jvmjobs Конфы: @jvmconf

Java & Co
Java & Co
2 370 участник(ов)

Можно обсуждать с матом и без всё, что касается жабы, вплоть до холиваров. НЕ ИМЕЕТ ОТНОШЕНИЯ К САЙТУ JAVARUSH.RU ПРАВИЛА - https://t.me/javarush/75723 Вакансии сюда - https://telegram.me/joinchat/B7IzvUCnfo6d8t3yIxKguQ По вопросам - @thedude

learn.java
learn.java
1 888 участник(ов)

Чат для начинающих и не только Статистика: https://combot.org/chat/-1001083535868 Основной чат - @jvmchat

Кибербезопасность АСУ ТП: RUSCADASEC Community
Кибербезопасность АСУ ТП: RUSCADASEC Community
1 389 участник(ов)

Группа открытого независимого сообщества специалистов по кибербезопасности АСУ ТП / RUSCADASEC для интерактивного обмена информацией по теме Подробнее: www.ruscadasec.ru Наш канал для основных новостей и материалов @RUSCADASECnews

secinfosec
secinfosec
697 участник(ов)

Эта группа про информационную безопасность. Целевая аудитория: пентестеры, ресерчеры, ибшники всех мастей. Реклама, криминал, политика и прочая чушь карается родовыми проклятьями. Митапы: https://www.youtube.com/channel/UCagEjp1FmxY9gsVxi6_d4SQ

Linux Security
Linux Security
652 участник(ов)

Данная группа принципиально про безопасность и в частности про безопасность Linux. Прочие темы просим обсуждать в профильных чатах.

Chat Security / ИБач чат
Chat Security / ИБач чат
601 участник(ов)

Чат канала @ibach Обсуждение всего, что касается информационной безопасности Правила: https://t.me/chat_security/65

Java Underground
Java Underground
169 участник(ов)

https://vk.com/javatutorial

Javanese Questions
Javanese Questions
109 участник(ов)

Чат предназначен для обмена знаниями строго в формате в вопрос-ответ. Тема — Java, Kotlin и Android. Вопрос должен быть предварительно прогуглен, понятно и грамотно сформулирован, помечен хэштегами. Ответ — тем более. Куски кода размером в несколько строк можно писать прямо здесь, для больших кусков кода стоит использовать http://gist.github.com/, http://pastebin.com/, https://codeshare.io/ или любой аналогичный сервис. В некоторых случаях можно прикреплять скриншоты. Стикеры и гифки запрещены. Дополнять и уточнять вопросы и ответы — редактированием исходного сообщения. Обсуждения должны приводить к редактированию вопроса/ответа и удаляться. По хештегам можно искать существующие вопросы и овтеты: #вопрос #ответ #git #generics #java #server #awt #javafx #swing #kotlin #anko #tornadofx #ktor #android #recyclerView #performance #arch #network #permissions #storage #async