id: Гость   вход   регистрация
текущее время 14:15 29/03/2024
Автор темы: Гость, тема открыта 01/11/2009 20:07 Печать
Категории: софт, инфобезопасность, операционные системы, разграничение доступа
http://www.pgpru.com/Форум/UnixLike/ОсновноеНазначениеОпцииМонтированияNoexec
создать
просмотр
ссылки

Основное назначение опции монтирования noexec


Есть распространённое мнение (заблуждение?), состоящее в том, что монтирование ФС с опцией noexec запрещает выполнение произвольного кода. Однако, существуют конвенциональные способы обхода указанного ограничения посредством perl:

Ой-ой-ой. Как только узнали элитный способ обхода nonexec так тут же побежали дырки все залатали. Ну ничего, для вас есть еще один способ обхода nonexec:
Вместо 1337 там может стоять и __NR_vmsplice (316) ;)

Т.о., суть состоит в том, что существование perl в системе позволяет скормить perl'у произвольный perl'овый код (а он может обладать достаточно богатыми возможностями), т.к. выполняться будет уже сам perl, находящийся в /usr, т.е. на exec-ФС. В вышеприведённом примере используется perl'овый модуль syscall.ph, но, видимо, ничто не мешает прикрутить подобный модуль самому, если на испытуемой ОС с noexec-ФС его нет. Отдельно стоит отметить, что в OpenBSD perl входит в базовую систему вкупе с указанным модулем. Кто-то некогда писал, что noexec имеет смысл не более чем защиты от accidental execution и script kiddies: так ли это на самом деле? Наверняка (полагаю) существуют и другие способы полноценного обхода noexec, тогда для чего он нужен? В принципе подобный механизм бы работал с любым языком программирования, умеющем работать с сишными функциями. Ранее в Linux имелась возможность выполнять произвольный код с noexec-ФС используя стандартный линкер ld-linux.so.2, но позже эту дыру закрыли. Просьба к специалистам прояснить основные интенции тех, кто придумал noexec: зачем оно нужно при столь простом нивелировании? Лишь для защиты от случайных багов линкера?


 
Комментарии
— Гость (01/11/2009 20:20, исправлен 01/11/2009 20:23)   <#>
PS: Ещё можно отметить:
(man mount on Linux)
(man mount on NetBSD)
Тем не менее, остаётся дилемма: либо использование noexec для безопасности – обычное заблуждение, либо misuse после некоторой соответствующей доработки системы защиты.
— SATtva (01/11/2009 20:21)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Кто-то некогда писал, что noexec имеет смысл не более чем защиты от accidental execution и script kiddies: так ли это на самом деле?

Так и есть, вроде Вы это сами и показали. :-) Это не "защита от выполнения произвольного кода", это только запрет на выполнение бинарного кода с данной ФС. Посмотрите описание опции в man mount, там всё белым по чёрному:



(Звёздочки мои.)
— SATtva (01/11/2009 20:23)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
использование noexec для безопасности – обычное заблуждение

Голосую за этот вариант.
— Гость (01/11/2009 20:31)   <#>
Казалось бы, что достаточно забанить все опасные интерпретаторы, и дело в шляпе. Однако, наличие доступа к любой программе, имеющей ошибку с возможностью выполнения произвольного кода от имени запустившего её пользователя (а таких программ навалом почти в любой системе), позволяет выполнить пользователю произвольный код несмотря на noexec ФС, доступной на запись. Потому, пожалуй, вы правы...
— unknown (02/11/2009 08:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Почти оффтопик, но очень похожая проблема: аналогичное заблуждение существует и в отношении chroot. Кажется, Эндрю Мортон (один из ведущих разработчиков Linux ядра) — лень сейчас искать пруфлинк с точной цитатой в рассылке — заявлял, что chroot — не более чем средство например что-то скомпилировать или отладить под другую архитектуру, но это средство не имеет никакого отношения к безопасности.

Под Linux существует так называемый "укреплённый chroot", в составе набора патчей, "повышающих безопасность". но разработчики ядра оценили этот проект как тупиковый и отказались включать его в ядро.

Стандартный ответ: нужна безопасность — используйте Selinux, другие модели по сравнению с ним заведомо ущербны в обмен на простоту использования и чаще всего не обеспечивают никакой реальной безопасности.
— Гость (05/11/2009 00:26)   <#>
Не совсем оффтопик, я в голове это тоже держал, когда создавал тему. Уже есть целый зоопарк "призраков безопасности": chroot, noexec, AppArmor... какой-нить nosuid для ФС возможно из их же числа.

Под Linux существует так называемый "укреплённый chroot", в составе набора патчей, "повышающих безопасность". но разработчики ядра оценили этот проект как тупиковый и отказались включать его в ядро.

Во FreeBSD есть chroot jail. Итересно, применимо ли к нему всё вышесказанное...
— unknown (05/11/2009 09:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Судя по описанию, бээсдэшный jail лучше, чем hardened chroot от grsecurity, но SELinux пока не заменить ничем.

Пока правила политики не компилируются в бинарные модули, а конфиги лежат в виде простых файлов на обычной файловой системе, а доступ к файлам указывается путями, а не по меткам файловой системы, пока у файлов есть только "владелец, группа, другие" + довесок ACL или MAC, а у процессов нет ролей и доменов безопасности и т.п., то хоть чрутьте, хоть ACL используйте — это будет "просто лучше, чем ничего".
— Гость (05/11/2009 17:38)   <#>
Сравнивать с SeLinux не очень уместно, хотя бы потому, что по функционалу SeLinux – гигантский монстр, а jail на фоне него – небольшая примочка. Вопрос лишь в том, насколько легко обойти модель безопасности в jail. Мне говорили, что jail – это самый что ни на есть стандартный chroot, к которому добавили ещё чрутование сетевых сервисов, не более того.
— unknown (05/11/2009 21:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ну вот что grsecurity предлагает против вылезания из своего чрута:

Chroot restrictions

    • No attaching shared memory outside of chroot
    • No kill outside of chroot
    • No ptrace outside of chroot (architecture independent)
    • No capget outside of chroot
    • No setpgid outside of chroot
    • No getpgid outside of chroot
    • No getsid outside of chroot
    • No sending of signals by fcntl outside of chroot
    • No viewing of any process outside of chroot, even if /proc is mounted
    • No mounting or remounting
    • No pivot_root
    • No double chroot
    • No fchdir out of chroot
    • Enforced chdir("/") upon chroot
    • No (f) chmod +s
    • No mknod
    • No sysctl writes
    • No raising of scheduler priority
    • No connecting to abstract unix domain sockets outside of chroot
    • Removal of harmful privileges via capabilities
    • Exec logging within chroot


Зато в jail что-то вроде своего ACL с описанием кому как можно вылезать в сеть.
— Мухтар (05/11/2009 22:06, исправлен 05/11/2009 22:18)   профиль/связь   <#>
комментариев: 155   документов: 20   редакций: 5
У вас странная модель угрозы. Защищать от эскалации привилегий целесообразно сервер. Десктопы лучше защищать с помощью tripwire+LVM(ZFS) snapshots
— Гость (06/11/2009 16:50)   <#>
Ну вот что grsecurity предлагает против вылезания из своего чрута

Если чрутуемый юзер не имеет root-привелегий и не является членом группы wheel, насколько коротким станет список?
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3