*.so и a-x

сделать секцию кода в раме ro и секцию данных noexec?

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

linux поддерживает DEP начиная с 2000 года, например

> linux поддерживает DEP начиная с 2000 года, например

Еще раз: ты можешь сделать dlopen на любой доступный для чтения файл.

вызов dlopen это тоже «этап динамической линковки», называйте вещи своими именами и вам будут давать корректные ответы. вам, в первую очередь, не угодило явное связывание.

Ну добавь пропущенно слово «его» во фразу «загруженных на этапе динамической линковки библиотек», и всё встанет на свои места.

По первому вопросу:

1. А зачем? 2. Теоретически можно сделать патч для binutils.

Прозреваю, что из-за заявления разработчиков Mozilla о фоновом обновлении браузера?

> А зачем?

Для повышения безопасности. Допустим, есть приложение, которому злоумышленник может подсунуть *.so и заставить выполнить из него код. Т.е. одна дополнительная проверка закроет целый класс уязвимостей в прикладном ПО.

> Допустим, есть приложение, которому злоумышленник может подсунуть *.so

А вот нечего пихать левые^W доступные для записи не-руту папки в LD_LIBRARY_PATH...

ман плагины

Я так понял, уважаемый анонимус хочет знать, как лучше защитить плагинный софт от исполнения кода плагинов? Мне интересно, для чего?

Выделяешь память, открываешь бинарный файл, грузишь код в память, передаешь управление на него. Ясно?

> Выделяешь память, открываешь бинарный файл, грузишь код в память, передаешь управление на него. Ясно?

Ясно, что вы не читаете то, что написано в заглавном посте.

А ты проверил что тебе в том топике нарассказывали?

может проще разрешить линковать только указанные .so а остальное забанить к чертям собачим? Если да - вас ждет патч на ф-цию dlopen, если я не ошибаюсь...

а, ну и в grsec можно реализовать подобное

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

То есть, запретить Firefox-у грузить плагины? Или запретить запускать только код, не помеченный как исполняемый?

1. Почему реализация динамического линковщика в GNU/Linux не проверяет бит исполнимости на файлах разделяемых библиотек? Какие есть теоретические, практические, исторические основания для этого?

Вот мне тоже интересно, почему я могу /lib/ld-linux.so.2 progname, даже если progname имеет права доступа 0666?

> Почему реализация динамического линковщика в GNU/Linux не проверяет бит исполнимости на файлах разделяемых библиотек?

Потому что концептуально «исполнение файла» - это создание нового процесса или замещение кода существующего, ничего такого динамический линковщик не делает.

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

Думаю, что никак. Разве что автоматически ставить бит зашиты от исполнения во все mmap, выполняемые после завершения работы ld.so

Разве что автоматически ставить бит зашиты от исполнения во все mmap

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

> Потому что концептуально «исполнение файла» - это создание нового процесса или замещение кода существующего, ничего такого динамический линковщик не делает.

Сначала придирка: что значит «или»? В юниксе исполнение это _только_ замещение кода существующего процесса.

Теперь по существу. Ты прав. Тогда, если теоретически рассуждать, имеет смысл придумать отдельное право «интерпретации файла как содержащего код». Впендюрить его как расширеный аттрибут. Право на исполнение тогда окажется более узким правом. Если нет права intrprt (сокращение в стиле юникс, ага), то автоматически нет и права exec.

имеет смысл придумать отдельное право «интерпретации файла как содержащего код». Впендюрить его как расширеный аттрибут

А бит Х для чего придуман по твоему?

tailgunner правильно указал: X — это право на exec данного файла.

А в О'Railly-евской книжке «Linux System Programming: Talking Directly to the Kernel and C Library » пишут что в современных системах на 86й архитектуре всё обстоит несколько иначе, обрати внимание на последнее предложение отквоченного:

While POSIX defines four protection bits (read, write, execute, and stay the heck away), some architectures support only a subset of these. It is common, for example, for a processor to not differentiate between the actions of reading and executing. In that case, the processor may have only a single “read” flag. On those systems, PROT_READ implies PROT_EXEC. Until recently, the x86 architecture was one such system.

Of course, relying on such behavior is not portable. Portable programs should always setPROT_EXECif they intend to execute code in the mapping.

The reverse situation is one reason for the prevalence of buffer overflow attacks: even if a given mapping does not specify execution permission, the processor may allow execution anyway.

Recent x86 processors have introduced the NX (no-execute) bit, which allows for readable, but not executable, mappings. On these newer systems,PROT_READ no longer impliesPROT_EXEC.

Так кому следует верить - О'Railly-евской книжке или какому-то там tailgunner-у?

Это всё очевидные вещи. Давай конкретнее:

1. Может ли программа за-mmap-пить файл с правами r-- с битом PROT_EXEC на страницы памяти?

2. Может ли программа за-mmap-пить файл с правами r--, а потом установить бит PROT_EXEC через mprotect?

3. Если может, то как стандарт соотносится с этим поведением? А если не может?

Т.е. если система на х86 даёт процессу возможность установить флаг Exec на область памяти, в которую отображается файл не имеющий атрибута X или вообще на область памяти с произвольными данными - это неправильная, уязвимая система. Грязные хаки нужны на всяких виндовсах, а зачем такое делать в линахе - совершенно непонятно, ведь всю эту функциональность типа плагинов можно реализовать в виде разделяемых библиотек и раздать права соотв. образом, не оставляя процессам лазеек для всяких непредсказуемых выкрутасов.

> Т.е. если система на х86 даёт процессу возможность установить флаг Exec на область памяти, в которую отображается файл не имеющий атрибута X или вообще на область памяти с произвольными данными - это неправильная, уязвимая система.

Назови пример правильной системы, ну.

Похоже я был неправ.. Вот погуглил - там похоже ещё хуже чем казалось: http://thexploit.com/secdev/testing-your-shellcode-on-a-non-executable-stack-... - программа может за ммапить память с правами для запуска, написать туда чего ей воссрётся и передать управление.. Я просто не понимаю - зачем разработчики процессоров делают многочисленные кольца защиты, атрибуты для таблиц дескрипторов, потом бит NX реализовали если на это всё кладётся такой жирный болт? Ведь в LDT в 386й модели изначально существовал флаг, обозначающий можно ли запускать эти байты, на которые указывает дескриптор. Все на него клали. Когда в результате начались исполнения зловредного кода в результате переполнения стека - разработчикам ос дали ещё бит NX - на стек его вроде теперь выставляют. Но блин зачем разрешать мапить память с правами executable!?

> Назови пример правильной системы, ну.

Да понятия не имею! Венда должна тоже быть уязвима в этом плане. Что у нас есть ещё на 86й архитектуре ? В принципе ничего больше и нету. Зачем разработчики ОС делают это когда сам процессор казалось бы намекает им как надо поступать с памятью - непонятно.

Что бы их исполнять? )) Как ты себе иначе этот процесс представляешь?

Что бы их исполнять? )) Как ты себе иначе этот процесс представляешь?

Как? Ну, в идеале вся память, что мапится в адресное пространство процесса непосредственно по заявке процесса не должна иметь привелегий для запуска. Если же программа хочет какие-то байты исполнить - эти байты должны находиться в системе в виде исполнимого файла или разделяемой библиотеки, которым администратором назначены права для исполнения данным юзером. Разделяемая библиотека может размещаться в памяти и инициализироваться по вызову прикладным процессом функции dlopen() - вот внутри этого вызова система и должна размещать память с правами executable. А непосредственно прикладным программам давать возможность размещать какую-либо память с правами запуска и записи туда - не нужно и опасно.

Ну, впринципе наверное да. Можно пробовать впихнуть в сам сискол mmap проверку прав. В SELinux afair как то так и делается

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

Кстати говоря - верный способ утихомирить фокс и его разработчиков.

IMHO, только ld.so должен быть исполняемым, ибо это как #!... для ELF

И отправить миллионы жабо-дотнето-кодеров на улицы? :))))

я так понимаю, что надо как-нибудь в make.conf указать --enable-static --disable-shared --disable-dynamic-loading и пересобрать мир. только, боюсь, что не все приложения могут нормально работать в состоянии статического связывания или я не прав? и соберутся ли они? и реально ли не будет после этого возможности сделать LD_PRELOAD?

если отвечать по поводу: есть такая штука в SELinux, называется textrel_shlib_t . Если этот атрибут безопасности не будет стоять на библиотеке и будет дефолтная политика безопасности, то у тебя вообще не загрузятся динамические библиотеки.

Пример использования:
https://www.centos.org/docs/5/html/5.4/technical-notes/ch04s29.html
http://tanso.net/selinux/ «Making new file label rules on RHEL5»
Пример работы:
http://admin-wolf.blogspot.com/2011/10/blog-post.html

Если найдешь официальное описание - скинь ссыль.
И если тебя интересует безопасность, то есть секьюритилаб и забугорные ресурсы. в этом разделе только быдлохакеры сидят, сколько себя помню :(

Из этого http://www.gentoo.org/proj/en/hardened/selinux-faq.xml?style=printable#portag... следует, что LD_PRELOAD точно можно блочить.

http://blog.siphos.be/2011/04/selinux-and-noatsecure-or-why-portage-complains...
вот тут касаемо того, как SELinux переписывает приложению переменные окружения. но ты говорил именно о подгрузке файлов самим приложением. очень было бы интересно, если бы затсестил, т.к. представлененная выше инфа о запрете подгрузки через атрибуты файла, т.к. она говорит именно об shared библиотеках.
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

Для тупых: запрет загрузки динамически связанных общих библиотек без спец атрибута файла и рафинизация переменных окружения - это две НИКАК не связанных РАЗНЫХ технологии безопасности SELinux. мало того, мне кажется, что Вы не совсем понимаете модель угрозы:
Если у злоумышленника есть возможность сделать LD_PRELOAD, то он явно будет обладать достаточными правами, чтобы сделать chmod +x ..., если, конечно, Вы не используете SELinux и там явно не указали, что процессу/юзеру нельзя +x делать.
Если злоумышленник может подгрузить код на лету через экспойт (в частности переполнение буфера), то тем более пофиг, тут не будут в 99% случаев никакие либы фигурировать, а защитит только hardened toolchain.
Если Вы хотите оградить приложение от законной подгрузки им своих же либ, то это не приведет ни к чему хорошему. Если есть сомнения в их (либ) истинности (что их не подменили), то извольте юзать hardened gentoo и средства проверки хэшей файлов.
Если паранойя, всё же, заставляет Вас запрещать приложению заниматься законными вещами, то см. выше:
1. Статическая компиляция (но я хз, насколько это от LD_PRELOAD спасёт)
2. Selinux
3. Selinux