Розділ 15. Capability-безпека

Простий приклад

Уяви, що тобі прислали посилку. Ти йдеш на пошту. Працівник запитує тебе: “Можете показати документи, що це ви?”. Ти показуєш паспорт. Він зіставляє ім’я з посилкою, віддає тобі.

Це — класичний контроль доступу. Система знає, хто ти, і за списком вирішує, що тобі дозволено. Ім’я → права.

Тепер інший варіант. Тобі прислали посилку. Ти йдеш на пошту. Працівник питає: “Маєте номер посилки?”. Ти показуєш: 1234567. Він іде, бере коробку з номером 1234567, віддає тобі.

Це — capability-based доступ. Система не знає і не цікавиться, хто ти. У тебе є квиток (capability) — номер посилки. Хто має квиток — той має право взяти посилку.

Перший варіант — це Unix, Windows, типовий веб-додаток. Користувачі, групи, права на файли, ACL (access control lists). “Хто” → “що дозволено”.

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

Це звучить як деталь архітектури. Але це фундаментально різний підхід до безпеки, з різними наслідками. Один підхід виграв загальне обчислення. Інший — забутий 40 років, але повертається саме зараз, в епоху AI-агентів.

Цей розділ — про забутий підхід.

Народження ідеї

Рік 1966. Джек Денніс та Ерл Ван Горн з MIT публікують статтю “Programming Semantics for Multiprogrammed Computations”. У ній вони пропонують радикально інший підхід до безпеки.

Замість того, щоб ОС запитувала “хто це робить?” перед кожною операцією, нехай у кожного процесу буде набір capabilities — спеціальних токенів, які дають конкретні права на конкретні ресурси. Capability — це, фактично, ключ. Маєш ключ — можеш зайти до кімнати. Не маєш — не можеш. ОС перевіряє лише наявність капабіліті, не “роль” чи “ім’я”.

У 1970-80-х було побудовано декілька реальних систем з capability-моделлю.

KeyKOS (1980-ті, компанія Tymshare). Перша комерційна capability-ОС. Працювала на мейнфреймах IBM. Закрита у 1990-х.

EROS (1990-ті, Університет Пенсильванії, Джонатан Шапіро). Дослідницька. Дала теоретичну основу для подальших систем.

KeyKEAP, Coyotos, CapROS — продовження.

Hydra, CMU’s Cm* — академічні експерименти.

Усі вони були технічно цікаві, але жодна не вижила комерційно. Чому?

Чому Unix переміг

У 1970-х, коли Unix виходив на сцену, capability-системи були технічно красивішими. Але Unix мав інші переваги:

Простота. Файлова система Unix-а з правами rwxrwxrwx (read-write-execute для власника, групи, інших) — проста на тлі складності тогочасних мейнфреймів. Кожен зрозуміє за п’ять хвилин.

Економність ресурсів. Capability-системи потребували значних ресурсів пам’яті для зберігання токенів. У 1970-х це було проблемою. Unix працював на менших машинах.

Зручність для користувача. Користувач міг сказати “дай Іванову право читати мої файли” — це інтуїтивно. Capability-модель вимагала розуміти, що таке “передати капабіліті”.

Соціальна модель. Unix був побудований навколо ідеї користувачів (multi-user). Люди працювали разом, ділилися файлами, мали ролі. Capability-системи краще підходять для процесів, ніж для людей.

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

Чому це раптом важливо знову

З 2010-х відбувається тиха революція. Дві сили зробили capability-моделі критично важливими знову:

Сила 1: Програма більше не “користувач”.

У 1970-х комп’ютер мав користувачів (людей), і безпека зводилась до того, щоб дозволити одному користувачу робити одне, іншому — інше. Сьогодні у тебе на смартфоні сотні додатків. Жоден з них не “ти”. Це окремі програми, кожна з своїми діями.

Як обмежити їх права? Якщо додаток отримує доступ “як користувач Іван”, він може все, що може Іван — у тому числі, наприклад, читати усі контакти, листати галерею, надсилати SMS. Жахливо.

Тому Android, iOS, Wayland на Linux уже багато років використовують capability-подібну модель: кожен додаток має обмежений набір дозволів (camera, location, contacts тощо), і не може вийти за них. Коли додаток просить дозвіл — це, по суті, capability.

Веб-браузери теж. Кожен сайт ізольований у своєму origin — не може читати дані з інших сайтів. Це capability-модель у дії.

Сила 2: AI-агенти.

Це нова, велика сила. У світі, де програми — це AI-агенти, які читають дані, приймають рішення, діють у мережі — питання довіри стає гострим.

Уяви: твій AI-асистент читає твою пошту, відповідає клієнтам, робить покупки в інтернеті. Що, якщо хтось надіслав email з prompt injection-атакою — текстом, який обманує модель і змушує її переказати гроші зловмиснику?

У світі Unix-моделі агент має усі права користувача — і робить переказ. Атака успішна.

У світі capability-моделі агент має обмежений набір capability. Один capability — читати email. Інший capability — переказати до 100 грн на день на конкретні рахунки. Якщо зловмисник захоче більше — capability немає, ОС не дозволить. Атака провалюється на рівні ядра, не моделі.

Це різниця між “захист на рівні промпта/моделі” (програмний, обхідний) і “захист на рівні ядра ОС” (математично гарантований). Перший — те, що зараз роблять усі. Другий — те, що буде потрібно завтра.

Як capability працює технічно

Подивимось ближче. У seL4 (про яке йшлося у попередньому розділі) уся безпека — capability-based. Це й робить його вибором для критичних систем.

Capability у seL4 — це посилання на об’єкт + права на нього. Об’єкти — це: - Сторінки фізичної пам’яті. - Потоки. - IPC-ендпоінти (для обміну повідомленнями). - Інші capabilities.

Права — це: - Read, Write, Execute (для пам’яті). - Send, Receive (для IPC). - Mint, Revoke (для самих capability — створювати нові з обмеженими правами, відкликати дозволи).

Коли процес створюється, він отримує початковий набір capability. Усе, що він може робити — це з ними. Якщо він хоче передати частину своїх прав іншому процесу — він передає capability через IPC. Якщо хоче дати обмежений доступ — він робить mint — створює нову capability з меншими правами.

Приклад. Процес A керує файлом X. Процес B хоче читати файл X. Процес A створює capability “read-only-access-to-X” і передає B. Тепер B може тільки читати X, не записувати, не видаляти. Якщо A потім вирішує забрати дозвіл — він revoke-ить capability, і B більше не може читати.

Усе це — на рівні ядра, з математичною гарантією. Не “програма B має поводитися добре, ми сподіваємось”. А “ядро не дасть програмі B зробити нічого крім того, що дозволяє її capability”. Якщо B зламано зловмисником — він обмежений тим самим набором capability.

Принцип найменших привілеїв

Тут вступає у дію один з найважливіших принципів інформаційної безпеки — принцип найменших привілеїв (Principle of Least Privilege, POLP). Сформульований Джеромом Сальцером і Майклом Шредером у 1975 році:

Кожна програма і кожен користувач системи повинні мати тільки ті привілеї, які необхідні для виконання поточного завдання — і не більше.

Це звучить очевидно. Але перевір свою систему. Скільки програм у тебе мають root-доступ? Скільки додатків на телефоні мають дозволи, які насправді не потрібні? У Unix-моделі це складно реалізувати, бо там “права прив’язані до користувача”. У capability-моделі це природно, бо ти явно даєш кожному процесу мінімальний набір capability.

Кожна capability — це точне, обмежене, відкличуване надане право. Її можна: - Передати (delegate). - Звузити (mint новий з меншими правами). - Відкликати (revoke). - Експіровувати (expire).

Це фундаментально краща модель безпеки, ніж “права на основі ролі”. Просто індустрія її ігнорує.

Capability у сучасних системах

Подивимось, де ця модель проникає у щоденне використання.

iOS і Android. Дозволи додатків — це capability-подібна модель. Коли додаток просить “доступ до камери”, це capability на камеру. Без неї — не зможе. Хоч і без формальної верифікації, концепція та сама.

Веб-браузери. Same-origin policy, content security policy, cross-origin resource sharing — усе це capability-механізми. Сайт А не може читати дані сайту Б, якщо немає явного дозволу.

Капабіліті в Linux (Linux capabilities). Linux має систему capability як доповнення до традиційної моделі — CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, тощо. Не повна модель, але крок у тому напрямку.

SELinux, AppArmor, seccomp. Це системи мандатного контролю доступу для Linux. Дозволяють робити дрібні обмеження на те, що процес може робити. Складно, але можливо.

Containers, sandboxes. Docker, podman, Firejail — усе це, по суті, capability-механізми, що обмежують те, що можуть робити контейнеризовані процеси.

Capsicum (FreeBSD, частково в macOS). Чисті capability для FreeBSD/macOS. Нечасто використовується, але існує.

WebAssembly + WASI. Один з найгарніших сучасних прикладів. WebAssembly-модулі мають обмежений набір capability (“файлова система — це”, “мережа — те”). Не можуть зробити нічого поза тим. Це робить WebAssembly природно безпечним для запуску ненадійного коду.

Fuchsia (Google). Експериментальна ОС від Google. Capability-based, з мікроядром. Запущена у деяких пристроях Google Nest. Можливо, замінить Android в довгостроковій перспективі (хоча неясно, коли і чи замінить).

Капабіліті і AI: великий розрив

Тепер головне питання. У 2024-му з’являється новий клас програм — AI-агенти. Вони: - Читають вхідні дані (тексти, зображення, файли). - Приймають рішення. - Виконують дії — пишуть код, надсилають листи, переказують гроші.

Як забезпечити їх безпеку?

Зараз у всій індустрії використовують програмний захист: - “Системні промпти” — які кажуть моделі: “ти не повинна робити X, Y, Z”. - “Guardrails” — окрема модель, яка фільтрує небезпечні відповіді. - “Tool restrictions” — список дозволених функцій. - “Sandbox” — обмежене середовище виконання.

Але це все можна обійти. Prompt injection — атака, де у вхідному тексті захована інструкція, яка вмовляє модель робити щось, чого не повинна. Це постійна проблема. Кожне нове LLM, кожна нова guardrail-система — і атаку знову знаходять.

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

Capability-based безпека вирішує це принципово. Якщо AI-агент технічно не має capability на переказ грошей більше ніж 100 грн — жоден prompt injection його не змусить це зробити. Бо ядро ОС не пропустить операцію. Це апаратний (точніше, ядерний) захист, а не програмний.

Це найважливіша теза цього розділу: capability-безпека — єдиний відомий метод дати AI-агентам автономність, не втрачаючи довіри.

Без неї майбутнє AI-агентів містить катастрофи. З нею — можна довіряти агентам реальні дії в реальному світі.

Що мала б робити індустрія

Якщо чесно — вона уже починає, дуже повільно.

Anthropic — компанія, що зробила Claude — нещодавно опублікувала Model Context Protocol (MCP), який містить ідеї capability-безпеки. AI-агент має описаний набір “інструментів” з обмеженими правами. Це поки не на рівні ядра, але концептуально правильно.

Google DeepMind експериментує з sandbox-середовищами для Gemini, що нагадують capability.

OpenAI має Function Calling з обмеженнями. Не повна capability-модель, але крок.

Дослідницькі групи в Carnegie Mellon, MIT, Cambridge досліджують capability-machine для AI. Це системи, де агенти запускаються в capability-середовищах (часто на основі seL4 або WebAssembly), і не можуть вийти за межі своїх дозволів.

urbit, Spritely Goblins, MarkM/E-language — спільнота, яка десятиліттями розробляла capability-системи “для людей”. Зараз їхні ідеї стають актуальними.

Прогноз: до 2030-го capability-моделі стануть стандартом для AI-агентів у відповідальних застосуваннях. Без них просто не буде довіри.

Капабіліті — це “забутий ключ”

Чому ми називаємо це “забутим ключем” у назві розділу?

Бо ця ідея — повноцінне рішення фундаментальної проблеми безпеки — існувала з 1960-х. Її знали. Її випробували. Її розуміли.

Але індустрія обрала простіший шлях. Unix виграв, бо простий. ACL виграли, бо інтуїтивні. Capability залишились академічною ідеєю.

Через 50 років наслідки цього вибору видно скрізь: - Тисячі CVE у Linux, Windows, macOS. - Постійні витоки даних з мобільних додатків. - Prompt injection атаки на AI-агенти. - Складність зробити автономні системи безпечними.

Якби індустрія обрала capability у 1970-х — половина цих проблем не існувала б. Не тому що capability “магічно” безпечна, а тому що її модель примушує думати про безпеку правильно. Замість “хто може це робити”, думаєш “які саме права у кого”.

Зараз, в епоху AI, ми повертаємось до забутого ключа. Не з власної волі, а тому що інакше не вийде. Без capability-моделі AI-агенти або занадто обмежені (нічого не можуть робити), або занадто небезпечні (можуть усе).

Що з цього винести

1. Capability-based безпека — модель, де права прив’язані до токенів (capabilities), а не до користувачів (як у Unix).
2. Ідея старіша за Unix (1966-1970-ті), але програла комерційно — Unix виявився простішим.
3. Сучасні системи (iOS, Android, браузери, контейнери, WebAssembly) уже використовують capability-подібні моделі — без того, щоб це формалізувати.
4. Принцип найменших привілеїв — кожна програма має мінімум прав. Природно реалізується через capability.
5. seL4 — найповніша capability-ОС у світі, з математично гарантованою ізоляцією.
6. AI-агенти — найважливіша причина, чому capability повертається. Програмний захист (prompt-системи, guardrails) можна обійти. Capability на рівні ядра — не можна.
7. Прогноз: до 2030-го capability стане стандартом для відповідальних AI-застосунків.

У наступному розділі — фінал. AI зустрічає голе залізо. Ми поговоримо про те, де всі ці ниті — формальна верифікація, мікроядра, capability — сходяться разом. Як зробити AI-системи, яким можна довіряти без застережень. Що для цього треба, що вже є, чого ще немає. І чому це найважливіше технічне завдання нашого десятиліття.

Це питання, на яке ще немає відповіді. Але є контури шляху.