Какой вред программа C / asm может нанести Linux при запуске непривилегированным пользователем? - PullRequest
5 голосов
/ 01 марта 2012

Я думал о сценарии, где можно позволить пользователям (может быть кому угодно, возможно, с дурными намерениями) представить код, который запускается на ПК с Linux (назовем его эталонным узлом). Цель состоит в том, чтобы создать своего рода автоматизированную среду для тестирования однопоточных подпрограмм. Допустим, веб-сайт публикует некоторый код на прокси. Этот прокси передает этот код узлу бенчмарка, а у узла бенчмарка есть только соединение Ethernet с прокси, а не сам интернет.

Если разрешить запускать любой пользовательский код C / asm на эталонном узле, с какими проблемами безопасности он столкнется? Следующие предположения сделаны:

  • Программа запускается как непривилегированный пользователь
  • Прокси будет иметь возможность уничтожить процесс на узле тестирования (например, сценарий бесконечного цикла)
  • Прокси-сервер может перезапустить узел эталонного теста (если он отвечает ...)

Итак, возможно ли на практике, что эта программа пользовательского пространства может вызвать сбой ОС или сделать машину недоступной для прокси-сервера? Со сборкой программист может делать в основном все, что он хочет (например, манипулировать указателем стека), и мне интересно, насколько строгим / устойчивым является Linux в этом отношении. Я также знаю о возможности для процессов запрашивать области совместно используемой памяти с другими процессами (shm), что также может сыграть здесь роль?

Любая литература или статьи на эту тему приветствуются.

Решения «песочницы» также могут быть интересны, но важно, чтобы ЦП выполнял 100% от того, на что он способен во время теста (по крайней мере, на ядре, на котором выполняется тест).

Ответы [ 5 ]

5 голосов
/ 01 марта 2012

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

  • Работа с файловой системой: удаление или перезапись файлов, принадлежащих пользователю, процесс запускается как
  • Отслеживание всех видов данных, найденных в системе (файлы, иногда сетевой трафик того же пользователя)
  • Уничтожение других процессов пользователя
  • Использование памяти до тех пор, пока OOM Killer не начнет убивать случайные процессы или (если вывключить обмен) до тех пор, пока машина не замедлится до сканирования
  • Генерация большого количества операций ввода-вывода для замедления системы
  • Выполнение эксплойтов по желанию (вы почти наверняка имеете некоторые незапатченные привилегииэскалация уязвимость где-то)
  • Небо это предел ...

Звучит не очень хорошая идея.

3 голосов
/ 01 марта 2012

Итак, возможно ли на практике, что эта программа пользовательского пространства может вызвать сбой ОС или сделать машину недоступной для прокси-сервера?

Ну, теоретически у вас должен бытьТрудно заставить ОС рухнуть.Однако существует много сообщений об ошибках, в которых говорится, что на практике это более возможно, чем хотелось бы.

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

Со сборкой программист может делать в основном все, что он хочет (например, манипулировать указателем стека), и мне интересно, насколько ограничительным/ Надежный Linux в этом отношении.

Однако мы намного лучше этого.Если бы все, что вам нужно для повышения привилегий, это «беспорядок с указателем стека», то в качестве поля была бы полная шутка.Ядро предназначено для написания , чтобы ни одна программа, несмотря ни на что, не могла вызвать сбой ядра.Как уже отмечалось, он несовершенен.

Мораль этой истории в том, что вы действительно не хотите запускать ненадежный код на компьютере, который вам небезразличен.Обычным ответом здесь будет виртуальная машина с контрольной точкой: запустите виртуальную машину, запустите ненадежный код на виртуальной машине, а затем по завершении или по истечении времени ожидания уничтожьте виртуальную машину.Таким образом, постоянный ущерб невозможен.Что касается других злоупотреблений, ваш прокси-сервер не позволит им размещать грязные интернет-сервисы, и это хорошо.В зависимости от ситуации с вашей виртуальной машиной могут быть хорошие инструменты для ограничения потребления ресурсов ЦП и сети, что поможет исключить другие возможности отказа в обслуживании.

Вы упоминаете, что ЦП должен работать на полную мощность.Аппаратная виртуализация довольно хороша , и производительность должна разумно отражать то, что было бы в реальной системе.

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

edit: Если вы действительно настаиваете на запуске напрямую на оборудовании, то:

  • загрузка с устройства только для чтения(livecd или жесткий диск с блокировкой записи)
  • не имеют записываемых носителей в системе
  • Добавить сервер отключения, который может принудительно перезагрузить машину по запросу прокси-сервера в случае отказа в обслуживании;для этого существуют коммерческие решения

Это, по сути, дает вам возможности решения VM, но на аппаратном уровне.

3 голосов
/ 01 марта 2012

Итак, возможно ли на практике, что эта программа пользовательского пространства может вызвать сбой ОС или сделать машину недоступной для прокси-сервера?

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

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

В Linux есть ulimit, который может защитить от некоторых из них, см. Ограничение памяти и процессора, доступных для пользователя в Linux И вредоносная сетевая активность также может быть заблокирована. Вы также можете отключить swap и chroot программу в tmpfs mount. Но некоторые неприятности все же будут возможны.

1 голос
/ 01 марта 2012

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

Тот факт, что программист может использовать сборку, не имеет значения - атакиможет быть закодирован на разных языках - скомпилирован или иным образом.

Основная проблема - неизвестные проблемы безопасности или 0-дневные уязвимости.Разрешение на запуск любой неавторизованной программы является риском, и если кому-то удастся использовать проблему, которая позволяет повысить привилегии, вы облажались.

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

0 голосов
/ 01 марта 2012

Программная группа может оказывать давление на память, приводя к тому, что машина перестает отвечать на запросы (особенно, когда происходит переключение на диск).Пример кода: perl -e '$_.="x"x1000000 while fork'

...