Основное назначение опции монтирования 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: зачем оно нужно при столь простом нивелировании? Лишь для защиты от случайных багов линкера?
(man mount on Linux)
(man mount on NetBSD)
Тем не менее, остаётся дилемма: либо использование noexec для безопасности – обычное заблуждение, либо misuse после некоторой соответствующей доработки системы защиты.
комментариев: 11558 документов: 1036 редакций: 4118
Так и есть, вроде Вы это сами и показали. :-) Это не "защита от выполнения произвольного кода", это только запрет на выполнение бинарного кода с данной ФС. Посмотрите описание опции в man mount, там всё белым по чёрному:
(Звёздочки мои.)
комментариев: 11558 документов: 1036 редакций: 4118
Голосую за этот вариант.
комментариев: 9796 документов: 488 редакций: 5664
Под Linux существует так называемый "укреплённый chroot", в составе набора патчей, "повышающих безопасность". но разработчики ядра оценили этот проект как тупиковый и отказались включать его в ядро.
Стандартный ответ: нужна безопасность — используйте Selinux, другие модели по сравнению с ним заведомо ущербны в обмен на простоту использования и чаще всего не обеспечивают никакой реальной безопасности.
Во FreeBSD есть chroot jail. Итересно, применимо ли к нему всё вышесказанное...
комментариев: 9796 документов: 488 редакций: 5664
Пока правила политики не компилируются в бинарные модули, а конфиги лежат в виде простых файлов на обычной файловой системе, а доступ к файлам указывается путями, а не по меткам файловой системы, пока у файлов есть только "владелец, группа, другие" + довесок ACL или MAC, а у процессов нет ролей и доменов безопасности и т.п., то хоть чрутьте, хоть ACL используйте — это будет "просто лучше, чем ничего".
комментариев: 9796 документов: 488 редакций: 5664
Зато в jail что-то вроде своего ACL с описанием кому как можно вылезать в сеть.
комментариев: 155 документов: 20 редакций: 5
Если чрутуемый юзер не имеет root-привелегий и не является членом группы wheel, насколько коротким станет список?