Выполнение произвольного кода на сервере

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

Я немного далек в проект рассмотреть использование другого метода блокировки вниз компьютера (как SteadyState), и все кроме кнопки отключения и ctrl+alt+delete заблокировано вниз, но я буду иметь в виду его для будущего.

Что касается компьютера, являющегося частью домена, нет, это не находится на домене, и пользователь является локальным пользователем.

Я посмотрю на метод, который видят zerrias', предложенные завтра и делает ли он то, в чем я нуждаюсь.

0
задан 27 November 2009 в 23:36
5 ответов

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

4
ответ дан 4 December 2019 в 11:03
  • 1
    Другие сделали это, и это работает. Контроль www.codepad.org :) –  Sinan Taifour 27 November 2009 в 23:31
  • 2
    Сделанный это, да. Работы... не так. I' m вполне уверенный I' ve вытащил достаточно информации из того сервиса для подтверждения дыры, но I' m не один для движения, разрушая машины в прихоти - и I' m даже особенно хороший во вторжении в вещи. –  womble♦ 27 November 2009 в 23:55
  • 3
    Мне интересно видеть то, что Вы нашли. Вы могли связаться с pastie, который Вы выполнили? –  Sinan Taifour 28 November 2009 в 00:00

Я думаю, что рабочие исполняемые файлы в VM являются Вашим лучшим выбором. Например, существует бот на #bash канале IRC, который допускает выполнение произвольного кода оболочки... путем выполнения его в qemu базирующийся VM и затем получения stdout того процесса. UML является, вероятно, довольно хорошим решением.

Новый материал lguest (http://lguest.ozlabs.org/), вероятно, лучше; это - "контейнерный" механизм, а не настоящее решение "для виртуализации"; что-то как Solaris Zones. Я не знаю то, что состояние этого проекта прямо сейчас.

2
ответ дан 4 December 2019 в 11:03

Можно дать попытку librestrict.

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

Одна из красот этой программы - то, что это, chroot () s после системы загрузил все необходимые библиотеки, поэтому если Вы удачливы (это не хочет к dl (), некоторый другой освобождает), можно использовать его с пустым каталогом как chroot () среда.

Хотя, это немного старо и не документировано, можно дать ему попытку, я могу дать Вам руку.

3
ответ дан 4 December 2019 в 11:03
  • 1
    Это небезопасно. Don' t делают это. LD_PRELOAD является запросом, не спросом... произвольный предоставленный пользователями исполняемый файл может легко встроить системные вызовы (интервал 0x80 или подобный), и LD_PRELOAD ничего не узнает. –  duskwuff 30 November 2009 в 08:04
  • 2
    каких системных вызовов Вы боитесь? –  asdmin 30 November 2009 в 20:07

Это должен быть исполняемый файл? Вы могли ограничить загруженные программы, чтобы быть, например, исходным кодом в некотором языке сценариев (Python, рубин), которые имеют некоторую среду выполнения песочницы. Или байт-код для чего-то как C# или Java? По крайней мере, C# и Java создали в механизме защиты для того, чтобы позволить и запретить операции.

Вы могли затем более легко ограничить то, что загруженные программы могут сделать и не могут сделать.

1
ответ дан 4 December 2019 в 11:03
  • 1
    Хорошо да, это может быть язык сценариев. Я на самом деле начался путем разрешения просто Ruby и игры в песочнице его, но я задавался вопросом, как это могло быть обобщено, таким образом дав больше опций моим пользователям. –  Sinan Taifour 28 November 2009 в 15:41

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

0
ответ дан 4 December 2019 в 11:03

Теги

Похожие вопросы