Виконання можливо шкідливої ​​програми в Linux

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

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

Чи може хтось допомогти мені у виборі правильного підходу? Безпека мене викликає велике занепокоєння. З іншого боку, я не хочу вирішити проблему, яка буде надмірна і витрачати багато часу, намагаючись навчитися чогось, що мені насправді не потрібно.

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

• Ще один варіант, для навіть більш високої безпеки, ніж віртуальна машина: завантажте "живий" CD / DVD / pendrive без доступу до жорсткого диска (тимчасово відключіть жорсткий диск в BIOS; якщо ви не можете, принаймні не монтуйте диск / зніміть його, якщо встановити автоматично - але це набагато менш безпечно)

• Докер контейнер трохи менше безпечна альтернатива повної віртуальної машини. Напевно, вирішальною відмінністю (з точки зору безпеки) між цими двома є те, що системи, що працюють в docker, насправді використовують ядро ​​вашої хост-системи.

• Є такі програми, як isolate, які створять особливе захищене середовище - це, як правило, називається пісочницею - вони, як правило, на базі хроту, з додатковим наглядом - знайдіть ту, яка вам підходить.

• Простий chroot буде найменш захищеним (особливо щодо виконання програм), хоча, можливо, трохи швидше, але ... Вам потрібно буде створити / скопіювати ціле окреме кореневе дерево та використовувати прив'язуючі кріплення для /devтощо (див. Примітку 1 нижче!). Таким чином, загалом такий підхід не можна рекомендувати, особливо якщо ви можете використовувати більш захищене, а часто простіше в налаштуванні sandboxсередовище.

Примітка 0: Що стосується "спеціального користувача", як-отnobodyобліковий запис: це майже не забезпечує безпеку, набагато менше, ніж навіть простийchroot. nobodyКористувач може ще файли і програми доступуякі читали і виконувати повноваженнявстановлені для іншого . Ви можете протестуватиsu -s /bin/sh -c 'some command' nobody. І якщо у вас є будь-який файл конфігурації / історії / кешу, доступний будь-кому (помилково чи незначний отвір у захисті), програма, що працює зnobodyдозволами ', може отримати доступ до нього, отримати папку за конфіденційними даними (наприклад, "pass =" тощо) та в багато способів надсилати його через мережу чи будь-що інше.

Примітка 1: Як зазначив Гілль у коментарі нижче , просте середовище Chroot забезпечить дуже низьку безпеку від подвигів, спрямованих на ескалацію привілеїв. Підошва кореневих має сенсзору безпеки, тільки якщо середовище мінімальний, що складається з безпеки підтверджених програм тільки (алеяк і раніше залишається ризик використання потенційних вразливостейрівні ядра), і все ненадійні програмизапущені в ізольованому оточенні працюють як користувач, який не запускає жодного процесу поза chroot. Що Chroot запобігає (з обмеженнями, згаданими тут), це пряме проникнення в систему без ескалації привілеїв. Однак, як зазначив Жилл в іншому коментарі, навіть такого рівня безпеки можна обійти, що дозволить програмі вирватися з хроноту.

Використовуйте віртуальну машину. Все, що менше, не забезпечує великої безпеки.

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

Я рекомендую запустити VirtualBox. Ви можете налаштувати віртуальну машину за пару хвилин, а потім встановити дистрибутив Linux всередині неї. Єдине налаштування, яке я не рекомендую за замовчуванням, - це налаштування мережі: створити інтерфейс “NAT” (для спілкування зі світом) та інтерфейс “тільки для хоста” (щоб ви могли легко копіювати файли на хост і з цього хоста, і ssh в В.М.). Відключити NAT-інтерфейс під час запуску програм учнів your; увімкніть це лише під час встановлення або оновлення програмних пакетів.

Всередині віртуальної машини створіть одного користувача на кожного учня.

¹ _{Ви можете обмежити NAT-інтерфейс у списку користувачів, але це просунутіше, ніж вам потрібно, у простому, точковому налаштуванні.}

ось дуже ґрунтовне пояснення чому використання Chroot все ще є дуже життєздатним варіантом, і чому повна операційна система або повна віртуалізація обладнання особливо непосильні в конкретних сценаріях.

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

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

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

видаліть усі незахищені програми, встановлені бінарні файли, звисаючі символи / посилання без власників. перезавантажте непотрібні папки за допомогою nosuid, noexec та nodev. побудувати останню стабільну версію запущеного демона з джерела. і, головне, забезпечити базову систему!

Я додам це, після закінчення офіційного відповіді на запитання: MAGIC: Зловмисне старіння в мікросхемах / ядрах , яке, на жаль, замикається за платою ACM. Підсумок статті полягає в тому, що дуже мала ширина слідів в схемах, які використовуються сьогодні, старіють під час використання, і врешті-решт руйнуються. Виявивши правильну інструкцію та повторюючи їх знову і знову, зловмисник може старіти, щоб ІС швидко виходили з ладу.

Жодна машина VM, пісочниця, контейнер чи в'язниця Chroot не запобігла б такому зловмисному знищенню обладнання. Автори статті знайшли такі послідовності інструкцій і експериментально старіли апаратне забезпечення до відмови, але вони не дали інструкцій, тому це може не бути реальною загрозою деякий час.

На уніфікованих BSD (включаючи Mac OS X) є об'єкт, який називається sandbox. На сторінці написано

ОПИС
Засіб пісочниці дозволяє програмам добровільно обмежувати свій доступ до ресурсів операційної системи. Цей механізм безпеки призначений для обмеження можливої ​​шкоди у випадку використання вразливості. Це не є заміною для інших елементів контролю доступу до операційної системи.

Це окремо від chrootзакладу, який також є в наявності.