Что такое noexec linux

Обновлено: 05.07.2024

Chrome OS добавила логику в поставляемые нами оболочки (например, dash и bash), чтобы определять, когда код запускается из разделов noexec. Это может вызвать проблемы с кодом, который ранее работал или продолжает работать в системах, отличных от Chrome OS.

Здесь мы углубимся в технические детали и способы решения распространенных проблем.

Содержание

Путешествие

Что такое монтирование noexec?

При создании монтирования в Linux вы можете добавить к параметрам noexec, чтобы получить путь, по которому ядро ​​будет отклонять попытки выполнения кода. Вместо этого вы будете получать ошибки EACCES (Отказано в доступе) при каждой попытке.

Зачем нужны монтирования noexec?

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

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

Поэтому мы стремимся иметь только одно место, где код может выполняться: rootfs только для чтения, которые постоянно проверяются криптографически. Все остальные пути в системе монтируются с параметрами noexec.

Теперь, если злоумышленник загружает программы (даже с правами root!) в доступные для записи папки, такие как /var, /tmp или /home , любые попытки запустить этот код будут отклонены.

А как насчет интерпретируемого кода?

До сих пор мы говорили о сценарии, в котором ядро ​​выполняет код. Другими словами, он имеет обработчик исполняемого двоичного формата (также известный как binfmt), который отвечает за прямой анализ и выполнение вещей. Это относится к файлам ELF, но как насчет интерпретируемого кода (также известного как скрипты)?

Хотя ядро ​​будет обрабатывать шебанг в скриптах и ​​корректно применять для них настройку noexec, на этом все останавливается.

Поэтому выполнение скриптов напрямую завершается ошибкой (и это здорово!):

Но косвенное выполнение скриптов по-прежнему работает (что плохо!):

Этот сценарий применим ко всем программам, которые принимают динамический код во время выполнения. Так что не только сценарии оболочки, но и awk, Python, Perl и т.д.

Что означает, что в Chrome OS мы несколько вернулись к тому, с чего начали: злоумышленники могут загружать произвольные сценарии оболочки в доступное для записи место, а затем запускать для них нужный языковой интерпретатор.

Какую защиту могут предложить переводчики?

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

Как Chrome OS справляется с этим в целом?

Начнем с удаления из ОС как можно большего количества интерпретаторов. По умолчанию мы блокируем попытки установить такие пакеты, как Python и Perl.

Для многих инструментов (например, sed и mawk) мы включаем их режим песочницы во время сборки, что позволяет нам оставлять их в системе и выполнять произвольные скрипты, но только как конвейерные инструменты: язык не поддерживает запуск произвольные программы или открытие файлов в системе для чтения/записи. В основном все, что они могут сделать, это прочитать стандартный ввод, преобразовать поток, а затем записать его обратно в стандартный вывод.

Мы понимаем, что полный запрет сценариев оболочки является серьезным препятствием для общей скорости разработки. У нас также есть немного значительного устаревшего кода в системе, который все еще написан в шелл-коде. Таким образом, у нас есть такие политики, как «скрипты оболочки подходят для небольших/тривиальных применений, но если они становятся слишком большими, их необходимо переписать на надлежащем скомпилированном языке».

Как Chrome OS обрабатывает сценарии оболочки?

Теперь мы подходим к сути дела :). Chrome OS исправляет тире и bash, чтобы определить источник кода во время выполнения, прежде чем он действительно выполнит его. Если он обнаружит, что сценарий оболочки находится в разделе noexec, он прервется! Так что теперь мы приближаемся к паритету с остальной системой.

Если мы вернемся к одному из наших предыдущих примеров:

А как насчет пограничного случая?

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

Например, это все еще работает:

Однако наша цель с этими изменениями не обязательно в том, чтобы быть пуленепробиваемым (хотя мы будем расширять и охватывать больше сценариев, когда это возможно), а в том, чтобы выявить множество распространенных и случайных ошибок.Таким образом, тот факт, что мы не обнаруживаем 100 % случаев неправомерного использования, не является хорошим аргументом в пользу того, чтобы никогда не обнаруживать злоупотреблений.

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

Например, разработчики привыкли писать такие вещи, как:

Вы не видите в этом ничего плохого? Ответ заключается в том, что это открывает систему для постоянной эксплуатации и часто для постоянной эксплуатации root, если сценарий оболочки является службой, запускаемой во время загрузки. Если злоумышленнику удастся записать простой текстовый файл по этому пути, то этот код будет полностью выполняться как завершенный сценарий оболочки! Ничего в . команда (которая является тем же источником) говорит, что файл может содержать только переменные. С таким же успехом это может быть exec /bin/sh /var/bad-script.sh, что означает, что остальная часть нашего загрузочного скрипта никогда не будет выполняться!

Прежде чем вы задумаетесь, да, разработчики пытались написать точно такой же код в Chrome OS и предоставить его всем нашим пользователям. Автор просто не представлял, что шелл-код может быть настолько мощным и опасным. К счастью, они обнаруживаются во время проверки кода, но это не гарантируется.

Как исправить код?

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

Это может быть немного сложно, но если у вас возникли проблемы с запуском кода оболочки из раздела noexec, велика вероятность, что ваш сценарий оболочки уже находится в той точке, где вам не следует использовать оболочку. Пожалуйста, внимательно рассмотрите возможность переключения языков, особенно из-за того, что модульное тестирование сценариев оболочки редко возможно. Весь код в Chrome OS должен иметь надлежащее покрытие юнит-тестами, чтобы мы могли с уверенностью предоставлять стабильную и надежную систему миллионам наших пользователей.

Как сохранить/восстановить настройки?

Для людей, которые хотят сохранить и восстановить набор "простых" переменных (обычно со значениями типа "0" или "1", "истина" или "ложь" и т. п.), есть несколько разных возможностей.< /p>

Использовать отдельные файлы.

Вместо записи хранилища ключей и значений в сценарий оболочки используйте файловую систему в качестве хранилища ключей и значений. В конце концов, файловые системы — это «всего лишь» базы данных! Это работает, когда у вас небольшое/ограниченное количество настроек.

Итак, вместо файла, сохраненного в /var/lib/foo/settings, например:

Разделите их на отдельные файлы:

  • /var/lib/foo/settings/VAR будет иметь содержимое 1
  • /var/lib/foo/settings/FOO будет иметь содержимое yes

Затем вы можете читать/записывать их по мере необходимости:

Как запустить код в режиме разработки?

Режим разработки — это когда пользователи берут свое устройство и переводят его в режим, в котором они могут получить полный доступ к своему устройству (т. е. разблокировать его). В этом случае разработчики обычно пишут свои собственные скрипты по путям noexec, а затем пытаются запустить их напрямую. Это больше не будет работать.

Однако в режиме разработки Chrome OS уже гарантирует, что /usr/local будет создан для того, чтобы пользователи могли делать все, что захотят. Это включает в себя монтирование его как исполняемого файла. Поэтому скопируйте туда все ваши сценарии оболочки и без проблем запустите их напрямую.

Мы также добавили /usr/local/bin в $PATH оболочки по умолчанию, так что вы можете помещать туда свои пользовательские скрипты и выполнять их, не используя полный путь.

Как запустить код в образах для разработки или тестирования?

Ответ такой же, как и в режиме разработки: используйте /usr/local для всего произвольного кода.

Исторически мы бы перемонтировали /home и /tmp как исполняемые файлы в тестовых образах, но на это больше нельзя полагаться. Это создает тестовую систему, которая не соответствует поведению кода, который мы отправляем всем нашим пользователям!

Как запустить гренки?

Крутон затрагивается так же, как и любой другой скрипт. Файл README для гренок был обновлен и содержит подробные сведения о новых рекомендуемых шагах.

Параметр noexec предотвращает выполнение кода непосредственно с самого носителя и, следовательно, может обеспечить линию защиты от определенных типов червей или вредоносного кода. Добавьте параметр «noexec» в четвертый столбец «/etc/fstab» для строки, которая управляет монтированием любых разделов съемных носителей.

Как найти флаг Noexec в Linux?

Запустите Терминал и используйте одну из следующих команд: findmnt -l | grep noexec.

Как узнать, есть ли у меня Noexec на TMP?

<р>1.1. 5 Убедитесь, что для раздела /tmp установлена ​​опция noexec (с оценкой)

Что такое Nosuid в Linux?

nosuid не препятствует запуску процессов root. Это не то же самое, что noexec . Это просто предотвращает вступление в силу бита suid для исполняемых файлов, что по определению означает, что пользователь не может затем запустить приложение, у которого есть разрешение делать то, на что у пользователя нет разрешения.

Что такое Nodev Nosuid Noexec?

Опция nosuid полностью игнорирует биты setuid и setgid, в то время как noexec запрещает выполнение любой программы в этой точке монтирования, а nodev игнорирует файлы устройств. Звучит здорово, но это относится только к файловым системам ext2 или ext3.

Что такое Noexec TMP?

Опция монтирования «noexec» может использоваться для предотвращения запуска двоичных файлов из «/tmp». Добавьте параметр «noexec» в четвертый столбец «/etc/fstab» для строки, которая управляет монтированием «/tmp». Охватывайте, определяйте и поддерживайте нормативные требования онлайн за считанные минуты.

Как найти параметр Noexec?

Как проверить, существует ли флаг «noexec» в ОС Linux?

  1. Запустите Терминал и используйте одну из следующих команд: findmnt -l | grep noexec. …
  2. Использование приведенных выше команд покажет, есть ли точка монтирования с флагом «noexec».
  3. Если в списке есть /var или /usr, вы должны удалить флаг «noexec» с помощью следующей команды:

Как добавить TMP в fstab?

Убедитесь, что вы привязали /var/tmp к /tmp:

  1. Отредактируйте файл /etc/fstab, введите: vi /etc/fstab.
  2. Добавьте следующую строку: /tmp /var/tmp none rw,noexec,nosuid,nodev,bind 0 0.
  3. Сохраните и закройте файл.

Как настроить Nodev на домашний?

Общие меры безопасности. Убедитесь, что параметр nodev установлен в разделе /home. Описание. Злоумышленник может смонтировать специальное устройство (например, блочное или символьное устройство) в разделе /home. Отредактируйте файл /etc/fstab и добавьте nodedev в четвертое поле (параметры монтирования) для раздела /home.

Что такое Linux Dev SHM?

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

Что такое Nodev в Linux?

Описание. Параметр монтирования «nodev» заставляет систему не интерпретировать символы и не блокировать специальные устройства. Выполнение символьных или блочных специальных устройств из ненадежных файловых систем увеличивает возможность для непривилегированных пользователей получить несанкционированный административный доступ. СТИГ.

Что такое Nofail fstab?

<р>4. 52. Во-первых, nofail позволяет продолжить последовательность загрузки, даже если диск не удалось смонтировать. Вот что говорит fstab(5) о nobootwait. Программа mountall(8), которая монтирует файловую систему во время загрузки, также распознает дополнительные параметры, которых нет у обычного инструмента mount(8).

Что такое _netdev в fstab?

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

Что такое дамп и проход в fstab?

Включить или отключить резервное копирование устройства/раздела (дамп команды). Это поле обычно имеет значение 0, что отключает его.

Управляет порядком, в котором fsck проверяет устройство/раздел на наличие ошибок во время загрузки.

Сайт продукта
 Сайт документации

4.10. Правильный монтаж разделов

При монтировании файловой системы Ext ( ext2 , ext3 или ext4 ) есть несколько дополнительных опций, которые вы можете применить к вызову mount или к /etc/fstab . Например, это моя запись fstab для раздела /tmp:

Вы видите разницу в разделах параметров. Опция nosuid полностью игнорирует биты setuid и setgid, в то время как noexec запрещает выполнение любой программы в этой точке монтирования, а nodev игнорирует файлы устройств. Звучит здорово, но это:

Опция noexec предотвращает прямое выполнение двоичных файлов, но ее легко обойти в более ранних версиях ядра:

Однако у многих скрипт-кидди есть эксплойты, которые пытаются создавать и запускать файлы в /tmp . Если у них нет ключа, они упадут в эту яму. Другими словами, пользователь не может быть обманут, чтобы запустить троянизированный двоичный файл в /tmp, например. когда /tmp случайно добавляется в локальный PATH.

Ниже приведен более подробный пример. Замечание: /var может быть установлен как noexec, но некоторые программы [15] хранят свои программы в /var. То же самое относится и к опции nosuid.

4.10.1. Настройка /tmp noexec

4.10.2. Настройка /usr только для чтения

Если вы установите /usr только для чтения, вы не сможете устанавливать новые пакеты в вашей системе Debian GNU/Linux. Вам придется сначала перемонтировать его для чтения-записи, установить пакеты, а затем перемонтировать его только для чтения. apt можно настроить для запуска команд до и после установки пакетов, поэтому вы можете настроить его правильно.

Обратите внимание, что Post-Invoke может завершиться ошибкой с сообщением об ошибке "/usr busy".Это происходит в основном, когда вы используете файлы во время обновления, которое было обновлено. Вы можете найти эти программы, запустив

Остановите или перезапустите эти программы и запустите Post-Invoke вручную. Осторожно! Это означает, что вам, вероятно, придется перезапускать сеанс X (если он у вас запущен) каждый раз, когда вы выполняете серьезное обновление своей системы. Возможно, вы захотите еще раз подумать, подходит ли для вашей системы /usr только для чтения. См. также это обсуждение в debian-devel о режиме только для чтения.

[15] Некоторые из них включают диспетчер пакетов dpkg, поскольку сценарии установки (post,pre) и удаления (post,pre) находятся в /var/lib/dpkg/ и Smartlist

Многие люди (включая Руководство по обеспечению безопасности Debian) рекомендуют монтировать /tmp с набором параметров noexec,nodev,nosuid. Обычно это представляется как один из элементов стратегии «глубокой защиты» путем предотвращения эскалации атаки, которая позволяет кому-то записать файл, или атаки пользователя с законной учетной записью, но без другого доступного для записи пространства.

Однако со временем я стал сталкиваться с аргументами (прежде всего со стороны разработчика Debian/Ubuntu Колина Уотсона) о том, что noexec — бесполезная мера по нескольким возможным причинам:

  1. Пользователь может запустить /lib/ld-linux.so, чтобы получить тот же эффект.
  2. Пользователь по-прежнему может запускать предоставленные системой интерпретаторы сценариев, которые нельзя запускать напрямую

Учитывая эти аргументы, потенциальную потребность в дополнительной настройке (например, debconf любит исполняемый временный каталог) и потенциальную потерю удобства, является ли это целесообразной мерой безопасности? Какие еще дыры, которые позволяют обойти защиту, вы знаете?

@neoice: я слышал, что приложения иногда ломаются, если /tmp не является исполняемым. Хотя я еще не видел, чтобы это произошло. Посмотрите TuxGuitar-1.2. такое случается. Не запустится, если /tmp не смонтирован без параметра noexec, потому что распаковывает там библиотеки, а потом пытается их загрузить.

Я знаю, что утилита сжатия snappy помещает файл .so в каталог /tmp и не может работать, если он смонтирован noexec. (он используется по умолчанию в cassandra и kafka) ИМХО это причина не использовать snappy, а не причина не монтировать /tmp noexec

6 ответов 6

Вот аргументы в пользу полезности, которые я привел:

Современные ядра исправляют дыру в /lib/ld-linux.so, так что он не сможет отображать исполняемые страницы из файловой системы noexec.

Точка переводчика, безусловно, по-прежнему вызывает беспокойство, хотя я думаю, что меньше, чем люди могут утверждать. Причина, которую я могу придумать, заключается в том, что существует множество уязвимостей повышения привилегий, которые основаны на выполнении определенных искаженных системных вызовов. Без злоумышленника, предоставившего двоичный файл, было бы намного сложнее совершать вредоносные системные вызовы. Кроме того, интерпретаторы скриптов должны быть непривилегированными (я знаю, что исторически иногда это было не так, например, с suid perl), и поэтому им нужна собственная уязвимость, чтобы быть полезными в атаке. Судя по всему, можно использовать Python, по крайней мере, для запуска некоторых эксплойтов.

Многие «заготовленные» эксплойты могут пытаться записывать и запускать исполняемые файлы в /tmp , поэтому noexec снижает вероятность атаки по сценарию (скажем, в окне между обнаружением уязвимости и установкой исправления).

Таким образом, монтирование /tmp с noexec по-прежнему дает преимущество с точки зрения безопасности.

Как описано в системе отслеживания ошибок Debian, установка APT::ExtractTemplates::TempDir в apt.conf для каталога, который не является noexec и доступен для root, избавит вас от проблем с debconf.

однако я слышал, что приложения иногда ломаются, если /tmp не является исполняемым. Хотя я еще не видел, чтобы это произошло.

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

Да, noexec — очень хороший дополнительный уровень безопасности, и я не видел, чтобы из-за него что-то ломалось. Установка пакета — это единственное, что можно обойти, как сказано в ответах здесь. В качестве решения у меня есть такой псевдоним: alias update="mount -o exec,remount /tmp && apt-get update && apt-get upgrade && mount -o noexec,remount /tmp"

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

equaeghe: Что это за пакет? Вероятно, об этом следует сообщить как об ошибке. Готов поспорить, что в том, как он это использует, тоже есть уязвимость.

добавьте следующее в /etc/apt.conf или /etc/apt/apt.conf.d/50remount

Многие пакеты Debian требуют, чтобы /tmp был исполняемым для установки пакета. Они часто помечаются как ошибки (серьезности «нормального»/«списка пожеланий»):

Я получил эту ошибку только сегодня при установке обновленного ядра в стабильную ветку.

Похоже, что Debian (и производные?) не готов к монтированию /tmp noexec.

Несмотря на то, что существуют обходные пути для большинства дополнительных мер безопасности, которые вы можете реализовать, даже самые простые меры безопасности (такие как монтирование /tmp noexec или запуск SSH на альтернативном порту) предотвратят автоматические атаки или атаки по сценарию, основанные на по умолчанию для работы. Это не защитит вас от решительного и знающего злоумышленника, но более чем в 99% случаев вы не столкнетесь с решительным или знающим злоумышленником. Вместо этого вы будете защищаться от сценария автоматизированной атаки.

Во-первых, он охватывает множество различных случаев атак. Отключать его, потому что было несколько известных способов обойти это (некоторые из которых даже исправлены), странно. Злоумышленники часто загружают код в /dev/shm или /tmp.

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

  • Это также может быть остановлено пользовательскими ограничениями iptables.
  • Он также может быть остановлен SELinux.
  • Его также нельзя остановить из-за легкодоступного другого эксплойта.

Смысл в том, чтобы максимально легко усложнить задачу и отсечь 99 % атак.

Во-вторых: это предотвращает плохую практику (запуск вещей из temp, выполнение основных установок приложений через /tmp вместо пользовательского tmpdir), оставляя данные в /tmp . Пользовательские установщики обычно понимают TMPDIR. Также: даже если нет: время установки, как действие на определенный момент времени, не является веской причиной для отключения проблемы безопасности навсегда.

В-третьих: принимая во внимание анонимные пространства имен в /tmp ("функция"), вы действительно хотите ограничить то, что туда помещается, и запускать оттуда.

Четвертое. Удобство здесь не играет роли. Предположим, что мы запускаем серверы за деньги и с какой-то целью: мы несем ответственность за все это. «О, я не заблокировал /tmp, потому что тогда мне понадобится еще несколько минут, когда я обновлю свое программное обеспечение в следующем году». Конечно, не только это будет стоять между шантажом и тем, чтобы быть в порядке. Веская причина? Я так не думаю.

Как насчет этого:

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

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

Получите полный доступ к Взломам сетевой безопасности и более чем 60 000 другим играм с бесплатной 10-дневной пробной версией O'Reilly.

Есть также прямые онлайн-мероприятия, интерактивный контент, материалы для подготовки к сертификации и многое другое.

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

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

опция монтирования — это флаг, управляющий доступом к файловой системе. Он передается коду ядра операционной системы, когда файловая система подключается к сети. Параметры монтирования можно использовать, чтобы предотвратить интерпретацию файлов как узлов устройств, запретить выполнение двоичных файлов и запретить влияние бита SUID (с помощью флагов nodev, noexec и nosuid). Файловые системы также можно монтировать только для чтения с помощью параметра ro.

Эти параметры задаются из командной строки при запуске mount с флагом -o. Например, если у вас есть отдельный раздел для /tmp, который находится в третьем разделе вашего первого жесткого диска IDE, вы можете выполнить монтирование с флагами nodev, noexec и nosuid, которые включаются выполнением следующей команды:

Эквивалентная запись в файле /etc/fstab будет выглядеть примерно так:

Внимательно изучив свои требования и разделив хранилище на несколько файловых систем, вы можете использовать эти параметры монтирования, чтобы увеличить объем работы, которую придется выполнить злоумышленнику, чтобы еще больше скомпрометировать вашу систему. Быстрый способ сделать это — сначала разделить дерево каталогов на области, которым требуется доступ на запись для работы системы, и те, которые этого не требуют. Вам следует рассмотреть возможность использования флага только для чтения в любой части файловой системы, содержимое которой не изменяется регулярно. Хорошим кандидатом для этого может быть /usr , в зависимости от того, как часто производятся обновления системного программного обеспечения.

Очевидно, что многие каталоги (такие как /home ) должны быть смонтированы для чтения и записи.Однако маловероятно, что пользователям средней многопользовательской системы потребуется запускать двоичные файлы SUID или создавать файлы устройств в своих домашних каталогах. Следовательно, можно создать отдельную файловую систему, смонтированную с параметрами nodev и nosuid, для размещения домашних каталогов пользователей. Кроме того, если вы определили, что вашим пользователям не нужно запускать программы, хранящиеся в их домашних каталогах, вы также можете использовать параметр монтирования noexec. Подобные ситуации также возникают при просмотре /tmp и /var , где крайне маловероятно, что какой-либо процесс будет законно нуждаться в выполнении двоичных файлов SUID или не-SUID или доступе к файлам устройств. Это помогает предотвратить возможность того, что злоумышленник оставит троянскую программу в общих каталогах, таких как /tmp или домашний каталог пользователя. Злоумышленник может установить программу, но на самом деле она не может работать, с соответствующими битами chmod или без них.

Есть несколько способов, которыми злоумышленник может обойти эти ограничения на монтирование. Например, параметр noexec в Linux можно обойти, используя /lib/ld-linux.so для выполнения двоичных файлов, находящихся в таких файловых системах. На первый взгляд может показаться, что это можно исправить, сделав ld-linux.so неисполняемым, но это сделало бы неисполняемыми все динамически связанные двоичные файлы. Таким образом, если все программы, на которые вы полагаетесь, не связаны статически (вероятно, нет), то опция noexec малопригодна для Linux. Кроме того, злоумышленнику, уже получившему привилегии суперпользователя, не будут сильно мешать файловые системы, смонтированные со специальными параметрами, поскольку их часто можно перемонтировать с помощью параметра -o remount. Но с помощью флагов монтирования вы можете легко ограничить возможные атаки, доступные враждебному пользователю, прежде чем он получит привилегии суперпользователя.

Получите инструкции по сетевой безопасности прямо сейчас с онлайн-обучением O’Reilly.

Члены O’Reilly проходят онлайн-обучение в режиме реального времени, а также получают книги, видео и цифровой контент от более чем 200 издателей.

Читайте также: