CGroups
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Контрольні групи Linux, або cgroups, є функцією ядра Linux, яка дозволяє виділяти, обмежувати та пріоритизувати системні ресурси, такі як ЦП, пам'ять та дисковий ввід/вивід серед груп процесів. Вони пропонують механізм для управління та ізоляції використання ресурсів колекціями процесів, що корисно для таких цілей, як обмеження ресурсів, ізоляція навантаження та пріоритизація ресурсів серед різних груп процесів.
Існує дві версії cgroups: версія 1 та версія 2. Обидві можуть використовуватися одночасно в системі. Основна відмінність полягає в тому, що версія cgroups 2 вводить ієрархічну, деревоподібну структуру, що дозволяє більш тонке та детальне розподілення ресурсів серед груп процесів. Крім того, версія 2 приносить різні покращення, включаючи:
На додаток до нової ієрархічної організації, версія cgroups 2 також представила кілька інших змін та покращень, таких як підтримка нових контролерів ресурсів, краща підтримка застарілих додатків та покращена продуктивність.
В цілому, cgroups версія 2 пропонує більше функцій та кращу продуктивність порівняно з версією 1, але остання все ще може використовуватися в певних сценаріях, де важлива сумісність зі старими системами.
Ви можете перерахувати cgroups v1 та v2 для будь-якого процесу, переглянувши його файл cgroup у /proc/<pid>. Ви можете почати з перегляду cgroups вашої оболонки за допомогою цієї команди:
Вихідна структура виглядає наступним чином:
Числа 2–12: cgroups v1, де кожен рядок представляє різний cgroup. Контролери для них вказані поруч з номером.
Число 1: Також cgroups v1, але виключно для управлінських цілей (встановлений, наприклад, systemd) і не має контролера.
Число 0: Представляє cgroups v2. Контролери не вказані, і цей рядок є ексклюзивним для систем, які працюють лише з cgroups v2.
Назви є ієрархічними, схожими на шляхи файлів, що вказує на структуру та взаємозв'язок між різними cgroups.
Назви, такі як /user.slice або /system.slice, вказують на категоризацію cgroups, де user.slice зазвичай призначений для сеансів входу, керованих systemd, а system.slice для системних служб.
Файлова система зазвичай використовується для доступу до cgroups, відхиляючись від інтерфейсу системних викликів Unix, традиційно використовуваного для взаємодії з ядром. Щоб дослідити конфігурацію cgroup оболонки, слід перевірити файл /proc/self/cgroup, який показує cgroup оболонки. Потім, перейшовши до каталогу /sys/fs/cgroup (або /sys/fs/cgroup/unified) і знайти каталог, що має таку ж назву, можна спостерігати різні налаштування та інформацію про використання ресурсів, що стосуються cgroup.
Ключові інтерфейсні файли для cgroups мають префікс cgroup. Файл cgroup.procs, який можна переглянути за допомогою стандартних команд, таких як cat, перераховує процеси в cgroup. Інший файл, cgroup.threads, містить інформацію про потоки.
Cgroups, що керують оболонками, зазвичай охоплюють два контролери, які регулюють використання пам'яті та кількість процесів. Щоб взаємодіяти з контролером, слід звертатися до файлів з префіксом контролера. Наприклад, pids.current буде використано для визначення кількості потоків у cgroup.
Вказівка max у значенні свідчить про відсутність конкретного обмеження для cgroup. Однак, через ієрархічну природу cgroups, обмеження можуть бути накладені cgroup на нижчому рівні в ієрархії каталогів.
Процеси призначаються cgroups шляхом запису їх ідентифікатора процесу (PID) у файл cgroup.procs. Це вимагає прав root. Наприклад, щоб додати процес:
Аналогічно, модифікація атрибутів cgroup, таких як встановлення обмеження PID, виконується шляхом запису бажаного значення у відповідний файл. Щоб встановити максимальну кількість 3,000 PID для cgroup:
Створення нових cgroups передбачає створення нової підкаталогу в ієрархії cgroup, що спонукає ядро автоматично генерувати необхідні файли інтерфейсу. Хоча cgroups без активних процесів можна видалити за допомогою rmdir, будьте обережні з певними обмеженнями:
Процеси можуть бути розміщені лише в листових cgroups (тобто, найбільш вкладених у ієрархії).
Cgroup не може мати контролер, відсутній у його батька.
Контролери для дочірніх cgroups повинні бути явно оголошені у файлі cgroup.subtree_control. Наприклад, щоб увімкнути контролери CPU та PID у дочірньому cgroup:
root cgroup є винятком з цих правил, дозволяючи пряме розміщення процесів. Це можна використовувати для видалення процесів з управління systemd.
Моніторинг використання ЦП в межах cgroup можливий через файл cpu.stat, який відображає загальний час використання ЦП, що корисно для відстеження використання серед підпроцесів служби:
Книга: Як працює Linux, 3-е видання: Що повинен знати кожен суперкористувач, автор Брайан Уорд
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
