Читаючи це , я знайшов наступний подвиг:

% cp /usr/bin/id ~
% chmod -x ~/id
% ls -al ~/id
-rw-r--r-- 1 edd edd 22020 2012-08-01 15:06 /home/edd/id
% ~/id
zsh: permission denied: /home/edd/id
% /lib/ld-linux.so.2 ~/id
uid=1001(edd) gid=1001(edd) groups=1001(edd),1002(wheel)

Цей фрагмент показує, що ми можемо тривіально виконувати дозволи на виконання файлової системи як звичайний непривілейований користувач. Я запустив це на Ubuntu 12.04.

Хоча завантажувач Linux є спільним об'єктом згідно з файлом (1), він також має точку входу, що дозволяє виконувати його безпосередньо. При виконанні таким чином завантажувач Linux працює як інтерпретатор бінарних файлів ELF.

На моїй машині OpenBSD цей подвиг не ефективний, оскільки ви не можете виконувати завантажувач як програму. На сторінці керівництва OpenBSD сказано: "ld.so - це сам спільний об'єкт, який спочатку завантажується ядром."

Спробуйте це на Solaris 9, і ви отримаєте сегмент за замовчуванням. Я не впевнений, що відбувається деінде.

Тому мої запитання:

• Чому завантажувач Linux (при безпосередньому виконанні) не перевіряє атрибути файлової системи перед інтерпретацією бінарних файлів ELF?
• Навіщо реалізовувати механізм, який призначений для заборони виконання файлів, якщо він настільки тривіально убік? Я щось пропустив?

Мета executeдозволу - не перешкоджати виконанню в цілому . Потрібно (1) вказати прогресам, які файли мають бути виконані, і (2) запобігти виконанню в якості привілейованого користувача , коли вказаний біт setuid (тощо).

Злом хакера є менш експлуатованим, ніж здається. Ви можете виконати будь-який невиконаний файл, у якого ви маєте права читати ще простіше:

$ cp unexecutable_file ~/runme
$ chmod +x ~/runme
$ ~/runme

Дивіться цю дискусію на форумі Arch Linux .

Підсумовуючи:

Позначення файлів, які слід виконати

Коли ви пишете сценарій оболонки, ви можете позначити його як виконуваний файл chmod +x. Це натякає вашій оболонці, що ви маєте намір її виконати (інакше для всіх знань оболонки це лише ще один звичайний текстовий файл). Після цього оболонка може відображати її на завершенні вкладки під час введення ./Tab.

Аналогічно: something.dкаталоги (наприклад init.d) містять сценарії запуску або керування оболонки, які, як правило, автоматично виконуються демонами. Ви можете поставити коментар або файл README у каталог у вигляді простого текстового файлу. Або ви можете тимчасово відключити один із сценаріїв. Це можна зробити, очистивши біт виконання для конкретного файлу. Це говорить демону пропустити через нього.

Запобігання привілейованому виконанню

У setuidбіт означає , що при виконанні файлу, він виконаний у вигляді зазначеного користувача (наприклад , корінь).

Повідомлення на форумі це добре пояснює:

Ви хочете, щоб виконуваний файл був налаштований для якогось користувача, але ви хочете, щоб люди з певної групи могли виконати його як налаштування. Вони все ще можуть виконати його, скопіювавши, але встановлений прапор втрачається, тому вони будуть виконувати його як самі, а не користувач, який володів оригінальним файлом.

Якщо ви прочитали доступ до файлу, ви завжди можете зробити його копію.

Якщо ви можете зробити особисту копію, ви завжди можете позначити цю копію як виконану.

Це не пояснює поведінку ld-linux, але вказує на те, що це може бути не дуже корисною лазівкою безпеки.

Якщо ви хочете посилити безпеку, розгляньте SELinux

Дивлячись на питання дещо інакше: як каже Mechanical Snail, дозвіл на виконання файлу не призначений для запобігання виконанню. Однак опція файлової системи "noexec" перешкоджає виконанню, і її не так просто обійти (підтримується не всіма файловими системами, але, безумовно, найбільш популярними Linux). Якщо адміністратор хотів заборонити користувачам запускати власні програми, вони могли вказати опцію noexec у домашніх та tmp-каталогах та будь-яких інших, де користувачі можуть мати можливість створювати файли.

$ mount -o noexec /dev/sdd1 /test
$ cd /test
$ cp /usr/bin/id .
$ ./id
-bash: ./id: Permission denied

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

З http://linux.die.net/man/8/mount :

noexec

Не допускайте прямого виконання будь-яких бінарних файлів у змонтованій файловій системі. (До недавнього часу можна було запустити бінарні файли в будь-якому випадку за допомогою команди на зразок /lib/ld*.so / mnt / binary. Цей трюк виходить з ладу з Linux 2.4.25 / 2.6.0.)