Більше подібних запитань із більшою кількістю відповідей, які варті уваги:
ПРИМІТКА. Деякі відповіді там вказують на конкретні рішення, про які ще не йдеться.
Насправді, існує досить багато інструментів, що мають в'язницю з різною реалізацією, але багато з них або не захищені дизайном (як fakeroot, LD_PRELOAD-основано), або не завершені (як fakeroot-ng, ptrace-основано), або потребують root ( chrootабо plashзгадуються підробкою) попереджувальна мітка ).
Це лише приклади; Я подумав перерахувати їх усі поряд, із зазначенням цих двох особливостей ("чи можна довіряти?", "Вимагає кореневих налаштувань?"), Можливо, у Впровадженнях віртуалізації на рівні операційної системи .
Загалом, відповіді там охоплюють повний описаний спектр можливостей і навіть більше:
віртуальні машини / ОС
розширення ядра (як SELinux)
- (згадується тут у коментарях),
chroot
Помічники на основі Chroot (які, однак, повинні бути встановлені кореневим кодом UID, тому що chrootвимагає root; або, можливо, chrootможуть працювати в ізольованому просторі імен - див. Нижче)
[щоб розповісти трохи більше про них!]
Відомі інструменти ізоляції на основі хроту:
- хешер з його
hsh-runі hsh-shellкомандами. ( Хешер був розроблений для створення програмного забезпечення безпечним та повторюваним способом.)
- schroot, згаданий в іншій відповіді
- ...
ptrace
Іншим надійним рішенням ізоляції (окрім заснованого на seccompоснові ) було б повне перехоплення системного дзвінка через ptrace, як пояснено на сторінці сторінки для fakeroot-ng:
На відміну від попередніх реалізацій, fakeroot-ng використовує технологію, яка не залишає простеженому процесу ніякого вибору щодо того, буде він використовувати "послуги" fakeroot-ng чи ні. Статичне складання програми, прямий виклик ядра та маніпулювання власним адресним простором - це всі прийоми, які можна тривіально використовувати для обходу управління, заснованого на LD_PRELOAD, і не стосується fakeroot-ng. Теоретично можна формувати фальсифікацію таким чином, щоб мати повний контроль над відстежуваним процесом.
Хоча теоретично це можливо, це не було зроблено. Fakeroot-ng припускає певні припущення про "добре поведені" про процес, що простежується, і процес, який порушує ці припущення, може мати змогу, якщо не повністю уникнути, то, принаймні, обійти частину "фальшивого" середовища, нав'язаного на нього fakeroot- нг. Таким чином, ви наполегливо застережені від використання fakeroot-ng як інструменту безпеки. Звіти про помилки, які стверджують, що процес може навмисно (на відміну від випадкового) вийти з підробленого керування root-ng або буде закритий як "не помилка", або позначений як низький пріоритет.
Цілком можливо, що в майбутньому ця політика буде переосмислена. На даний момент вас попередили.
Все-таки, як ви можете його прочитати, fakeroot-ngсам по собі не розрахований на цю мету.
(До речі, мені цікаво, чому вони вирішили скористатись seccompпідходом для Chromium, а не на ptraceоснові ...)
З інструментів, не згаданих вище, я зазначив Джорді для себе, тому що мені сподобалось, що контрольна програма написана в Haskell.
Відомі засоби ізоляції на основі ptrace:
seccomp
Один із відомих способів досягти ізоляції - це підхід до пісочниці, який використовується в Google Chromium . Але такий підхід передбачає, що ви пишете помічника, який оброблятиме деякі (дозволені) доступу до "перехопленого" файлу та інші системні дзвінки; а також, звичайно, докладіть зусиль, щоб "перехопити" системні дзвінки та перенаправити їх на помічника (можливо, це означало б навіть таке, як заміна перехоплених системних викликів у коді керованого процесу; отже, це не звучить бути досить просто; якщо вам цікаво, краще прочитайте деталі, а не лише мою відповідь).
Більше спорідненої інформації (з Вікіпедії):
(Останній пункт здається цікавим, якщо потрібно шукати загальне seccompрішення поза Chromium. Є також публікація в блозі, яку варто прочитати від автора "seccomp-nur": SECCOMP як рішення пісочниці? ).
Ілюстрація такого підходу від проекту "медсестра-медсестра" :
"Гнучкий" seccomp можливий у майбутньому Linux?
У 2009 році з'являлися також пропозиції проклеїти ядро Linux, щоб забезпечити більше гнучкості в seccompрежимі - щоб "можна було уникнути багатьох потрібних нам акробатик". ("Акробатика" відноситься до ускладнень написання помічником, який повинен виконувати багато можливих невинних систематичних викликів від імені тюремного в'язничного процесу, а також заміщення можливо невинних системних викликів у в'язничному процесі.) Стаття LWN писала до цього моменту:
Одне з пропозицій, яке з'явилося, було додати новий "режим" для секкомп. API був розроблений з ідеєю, що різні програми можуть мати різні вимоги до безпеки; воно включає значення "режим", яке визначає обмеження, які слід встановити. Був реалізований лише оригінальний режим, але інші, безумовно, можна додати. Створення нового режиму, який дозволив процесу ініціації визначати, які системні дзвінки будуть дозволені, зробить цей інструмент більш корисним у таких ситуаціях, як пісочниця Chrome.
Адам Ленглі (також Google) опублікував патч, який робить саме це. Нова реалізація "режим 2" приймає біт-маску, що описує, які системні дзвінки доступні. Якщо одним із них є prctl (), пісочний код може додатково обмежувати власні системні виклики (але він не може відновити доступ до системних викликів, яким було відмовлено). З урахуванням, це виглядає як розумне рішення, яке може полегшити життя розробникам пісочниці.
Зважаючи на це, цей код ніколи не може бути об'єднаний, оскільки дискусія перейшла до інших можливостей.
Цей "гнучкий seccomp" наблизив би можливості Linux до надання бажаної функції в ОС, без необхідності писати помічники, що ускладнюють.
(Повідомлення в блозі з тим самим вмістом, що і ця відповідь: http://geofft.mit.edu/blog/sipb/33 .)
простори імен ( unshare)
Ізоляція через простори імен ( unshareрішення на базі ) - тут не згадується - наприклад, нерозміщення точок кріплення (у поєднанні з FUSE?) Може бути частиною робочого рішення для того, щоб ви хотіли обмежити доступ до файлової системи ваших ненадійних процесів.
Детальніше про простори імен, тепер, коли їх реалізація завершена (ця методика виділення також відома під nme "Linux Containers" або "LXC" , чи не так? ..):
"Однією із загальних цілей просторів імен є підтримка реалізації контейнерів, інструменту для легкої віртуалізації (а також інших цілей)" .
Можна навіть створити нове простір імен користувачів, щоб "процес міг мати нормальний непривілейований ідентифікатор користувача поза простором імен користувача, одночасно маючи ідентифікатор користувача 0 у просторі імен. Це означає, що процес має повні кореневі привілеї для операцій всередині простору імен користувача, але непривілейований для операцій поза простором імен ".
Щоб дізнатися про справжні робочі команди, дивіться відповіді за адресою:
і спеціальне програмування / компілювання простору користувачів
Але, звичайно, бажані гарантії "в'язниці" реалізуються програмуванням в просторі користувача ( без додаткової підтримки цієї функції з ОС ; можливо, саме ця функція не була включена в першу чергу при розробці ОС ); з більш-менш ускладненнями.
Згадана ptrace- або seccompзаснована пісочницю можна розглядати як деякі варіанти здійснення гарантій в письмовому вигляді пісочниці-помічник , який буде контролювати ваші інші процеси, які будуть розглядатися в якості «чорних ящиків», довільних програм Unix.
Іншим підходом може бути використання методик програмування, які можуть піклуватися про ефекти, які слід заборонити. (Тоді ви повинні писати програми; вони вже не є чорними полями.) Якщо згадати про неї, використовуючи чисту мову програмування (яка змусить вас програмувати без побічних ефектів), як Haskell, це просто зробить усі наслідки програма явна, тому програміст може легко переконатися у відсутності заборонених ефектів.
Я думаю, є такі засоби для пісочниці, які доступні для програмування якоюсь іншою мовою, наприклад, Java.
Деякі сторінки, що накопичують інформацію на цю тему, також були вказані у відповідях: