Могу ли я доверять переменным окружения?

Ответ 1

Короткий ответ:

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

Дольше ответ:

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

• Что и с кем нам нужно защищать?
  • (тесно связанный вопрос: что может сделать наша программа на самом деле и что она может сломать?)
• Как мы это делаем?

Если и до тех пор, пока ваша программа работает под идентификатором пользователя пользователя, запускающего программу, и предоставляя все входные данные (т.е. только тот, кто может монтировать любую атаку), есть только редкие ситуации, когда это имеет смысл в все, чтобы ожесточить программу против атак. На ум приходит защита от копирования и совместное использование высоких баллов, но эта группа вещей касается не только ресурсов, но, вероятно, даже более того, чтобы пользователь не читал код и память. Скрытие кода оболочки script без какого-либо трюка suid/sgid - это я ничего не знаю, как это сделать; лучшее, что я мог придумать, будет скрывать код.

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

Предполагая, что вам нужна защита, вы просто не можете полагаться на переменные среды - и если вы не можете reset вещи, такие как LD_LIBRARY_PATH и LD_PRELOAD, даже вызовы с абсолютными путями, такими как /bin/id или /bin/ls, не будут давать вы надежный ответ, если этот инструмент не статически скомпилирован. Вот почему sudo имеет значение env_reset по умолчанию и почему запуск suid-программ должен игнорировать определенные переменные среды. Обратите внимание, что это означает, что ваша точка, в которой TOOLS_PATH_LIBRARY и PATH в равной степени заслуживает доверия, может быть правдой в вашей ситуации, но не обязательно является истиной в случае с другими ситуациями: sysadmin может reset PATH для sudo использования, но пусть проходят нестандартные переменные среды.

Как указано выше, argv[0] (или его bash эквивалент ${BASH_SOURCE[0]}) не более надежна, чем переменные среды. Пользователь может не только сделать копию или символическую ссылку на ваш исходный файл; execve или bash exec -a foo bar позволяет помещать что-либо в argv[0].

Ответ 2

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

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

Случай-в-точке, посмотрите CVE-2010-3847. При этом недопустимый злоумышленник с доступом для записи в файловую систему, содержащую двоичные файлы setuid или setgid, может использовать этот недостаток для повышения своих привилегий. Он включает переменную среды, изменяемую пользователем.

CVE-2011-1095 - еще один пример и не содержит двоичные коды SUID. Сделайте поиск Google для "среды glibc cve", чтобы увидеть виды вещей, которые люди могли сделать с модификациями переменных среды. Довольно коварный.

Ваши проблемы действительно сводятся к вашему утверждению:

Пользователь может установить TOOLS_PATH_LIBRARY в библиотеку по своему выбору, но утилита будет работать под их uid. Они могли просто запустить свою вредоносную библиотеку напрямую с помощью bash.

Ключевая фраза здесь - запуск их вредоносной библиотеки. Это предполагает, что их библиотека также принадлежит их UID.

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

https://github.com/cormander/tpe-lkm

Модуль останавливает вызовы execve/mmap/mprotect на файлы, которые можно перезаписывать или не принадлежит доверенному пользователю (root). Пока они не могут помещать вредоносный код в файл/каталог, принадлежащий доверенному пользователю, они не могут использовать систему таким образом.

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

Я должен упомянуть, что этот метод проверки доверенного пути защищает прямое выполнение с помощью двоичных файлов и разделяемых библиотек. Он мало чем отличается от интерпретируемых языков, поскольку они анализируют байт-код и не выполняют его напрямую. Таким образом, вам по-прежнему нужна определенная степень осторожности с PYTHONPATH, PERLLIB, CLASSPATH и т.д. И используйте упомянутые вами механизмы безопасности языка.

Ответ 3

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

Почему бы просто не создать нового пользователя, который содержит весь этот важный код. Затем вы можете получить информацию непосредственно из /etc/passwd или использовать синтаксис ~foo, чтобы найти домашний каталог пользователя.

# One way to get home directory of util_user
DIR=$(/usr/bin/awk -F: '$1 == "util_user" {print $6}' /etc/passwd)

# Another way which works in BASH and Kornshell
[ -d ~util_dir ] && DIR=~util_dir


# Make sure DIR is set!
if  [ -z "$DIR" ]
then
   echo "Something wrong!"
   exit
fi