Відстеження виконуваного файлу без дозволу читання

Я знайшов деяку дивовижну поведінку на Ubuntu 14.04 під час користування straceвиконуваним файлом, на який я не мав дозволу на читання. Цікаво, чи це помилка, чи чи якийсь стандарт наказує на цю незрозумілу поведінку.

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

$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>

Далі я спробую виконати виконуваний файл, на який у мене немає дозволу на читання:

---x--x--x 1 root root 26280 Sep  3 09:37 sleep*

Додавання до цього запущеного процесу заборонено:

$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

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

Але якщо я запускаю виконуваний файл у рамках уже відстеженого процесу, мені це дозволяється:

$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0)                                  = 0x9b7a000

Для мене це несподівано. Це помилка в безпеці чи це функція, яку вимагає стандарт?

permissions strace

— касперд
джерело

@ StéphaneChazelas: Справа в тому, що він може промальовувати його, просто використовуючи його в якості аргументу, щоб виправити. Першопричиною, здається, є те, що при execveвикликах дозволи на читання виконаного файлу не перевіряються знову, якщо процес уже простежено. Його питання полягає в тому , чи це помилка безпеки чи функція, на яку покладено обов'язок (якщо останній я все-таки вважав би це помилкою безпеки, просто помилкою безпеки специфікації).

— celtschk

@celtschk, вибачте, я занадто швидко прочитав питання.

— Стефан Шазелас

EPERM, Здається, виходить з get_dumpable()(використовується також для перевірки демпінг чи ядро дозволено, таким чином , «dumpable») викликається з __ptrace_may_access()викликається з ptrace_attach()в kernel/ptrace.c.

— ніндзяль

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

— суперкар

@supercat Наскільки я знаю, налагоджувач має доступ до єдиного кроку через весь виконаний код режиму користувача, включаючи код переселення. З таким рівнем доступу відтворити робочий виконуваний файл не повинно бути надто складно.

— kasperd

Це не відповідь, скоріше збірка посилань та думок на випадок, якщо хтось ще захоче вчитися. Бо це досить цікава річ.

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

Грізна безпека намагалася це виправити опцію конфігурації та сам патч (хоча це, можливо, змінилося з тих пір)

Ця фіксація справді здається, що розробники ядер дійсно дбають лише про скидання бінарних файлів suid.

Але насправді від цього рядка я здогадуюсь, що ядро хоче запобігти скидання нечитабельних двійкових файлів щодо стану SUID. І цей рядок говорить про те, що бінарні файли, які не підлягають розмноженню, не повинні бути простежені.

Тож на перший погляд здається, що ви знайшли помилку в ядрі із наслідками для безпеки. Але я не розробник ядра, тому не можу сказати точно. Я б запитав на LKML.

Редагувати: ще одне висновок щодо налагоджувача, згаданого в коментарях до оригінальної публікації - від швидкого розшарування (знову ж таки) мені здається, що gdb використовує простежені бінарні файли та /proc/<pid>/mem. Як тільки запущений двійковий файл не читається, cat /proc/<pid>/memповертається EPERM. Якщо двійковий файл читабельний, він повертається EIO. (Випробувано це на Ubuntu 14.10, який працює з декількома виправленнями безпеки, тому це може відрізнятися від ядра ванілі. Знову я не маю ванільного ядра, яке працює ніде зручно :()

— Лисиця
джерело