Є кілька способів убезпечити себе і свою машину під час веб-серфінгу і виконання інших мережевих завдань. Найбільш простий - завести в системі спеціального юзера, від імені якого заходити на безпечні / небезпечні сайти. Інший спосіб - це підняти віртуальну машину, встановивши на неї, наприклад, Hardened Gentoo. Ще можна встановити Qubes OS, але все це занадто надлишкові конфігурації, які можна замінити контейнерної виртуализацией.
За 2011 рік у всіх популярних браузерах сумарно було знайдено 594 уразливості, з яких браузеру Chrome належали 278, а Firefox - 89. 197 вразливостей в Chrome ставилися до класу високого ступеня небезпеки плюс одна критична уразливість, в той час як в Firefox вразливостей з високим ступенем небезпеки виявилося 65. у наступному році в Chrome виявили 125 вразливостей, з яких 68 мали високий ступінь небезпеки, в Firefox співвідношення вразливостей стало 159/99.
Chrome 29, випущений 20 серпня 2013 року, закрив 25 вразливостей, частина з яких мали високий рівень небезпеки. 13 листопада того ж року з'явився Chrome 30 з 12 закритими уразливими, окремі з яких приводили до розкриття особистих даних користувачів. Випущений 2 грудня Chrome 31 закривав 25 проблем безпеки, одна з яких носила критичний статус, а 21 - високий. Chrome 32, випущений 14 січня 2014 року, позбувся 21 уразливості, 16 з яких з високим статусом небезпеки.
Я міг би продовжувати цей нудний список ще довго, але картина вже має бути ясна. Браузери неабияк діряві, і з часом особливо нічого не змінюється, а де є дірки, там є і ті, хто їх експлуатує. Сучасний браузер, який вже почав перетворюватися в повноцінну операційну систему, - це величезна махина з мільйонів рядків коду, і багато хто з них можуть бути потенційно небезпечні.
Якщо зловмисникові вдасться поламати захист браузера і отримати контроль над ним і призначеними для користувача даними, а що ще гірше - вийти за межі браузера в операційну систему, скомпрометовані виявляться не тільки браузер, паролі і облікові записи для різних сайтів, а й взагалі всі призначені для користувача файли і навіть операційна система разом з ядром. Все це призведе до таких забавним наслідків, як, наприклад, викрадення акаунтів, абсолютно прозорий фішинг або перехоплення трафіку, викрадення баз паролів, що зберігаються в іншому місці, прихований Майнінг біткоіни і чорт його знає до чого ще.
Свого часу Іоанна Рутковська, що отримала неофіційно прізвисько Руткітовская, наочно показала, що веб-браузинг може бути досить безпечним тільки в тому випадку, якщо різні інстанції браузера для різних типів сайтів будуть виконуватися в відокремлених віртуальних середовищах, нездатних до взаємодії один з одним. Ідея лягла в основу операційної системи Qubes OS, яка є своєрідним Linux-дистрибутив, побудований на базі технологій Xen.
На превеликий жаль, в силу своєї архітектури Qubes OS виявилася мало придатною для звичайних користувачів, яким від машини потрібні не тільки можливість запускати браузер і офісний пакет, а й можливість встановлювати пропрієтарні драйвери, великий репозиторій софта і купа інших можливостей. Тому в рамках даної статті я хочу показати, як ідею поділу браузера і завдань можна реалізувати в будь-якому Linux-дистрибутиві без будь-яких серйозних обмежень.
Та сама Qubes OS
У Qubes OS Рутковська використовувала Xen, обґрунтувавши свій вибір логічно більш низьким рівнем ізоляції (нижче ядра Linux) і порівняно невеликим обсягом коду гипервизора, знайти помилку в якому за логікою має бути набагато складніше, ніж в ядрі Linux (якщо мова йде про KVM або, наприклад, OpenVZ). Для нас же Xen не дуже вдале рішення, яке створює занадто багато обмежень. KVM також не дуже зручний, а ось контейнерна віртуалізація на кшталт OpenVZ або LXC підійде дуже навіть добре.
Контейнерний тип віртуалізації не так безпечний, як Xen і навіть KVM, але його рівня ізоляції буде більш ніж достатньо для вирішення нашої задачі. Я особисто віддаю перевагу використовувати LXC, але вибір інструменту та дистрибутива тут зовсім не є принциповим. Також я хотів би звернути увагу на надбудову для LXC під назвою Docker, яка істотно спрощує розгортання віртуальних оточень.
Ми скористаємося Docker для того, щоб подивитися, як швидше і простіше всього можна розгорнути віртуальне оточення з браузером всередині. Потім спробуємо використовувати LXC як більш гнучке рішення, що дозволяє створити декілька логічно розділених оточень. Одне буде призначене для «розважального» веб-серфінгу, для сайтів на кшталт YouTube, ivi.ru, Last.fm і відвідування різних блогів і новинних сайтів. Друге оточення буде робочим (документи, таблиці, корпоративний сайт і так далі). Третє - інтернет-банкінг і фінанси: WebMoney, PayPal, Яндекс.Деньги.
Розділивши завдання між різними віртуальними оточеннями, ми вирішимо відразу кілька проблем:
- Компрометація браузера під час серфінгу по різним розважальним сайтам не приведе до витоку робочих і фінансових даних.
- У разі отримання контролю над одним з браузерів / оточень інші два, а також основна система залишаться у безпеці (принаймні до тих пір, поки зломщик не знайде спосіб вийти за межі оточення).
- Для різних типів сайтів ми зможемо використовувати різні браузери і налаштування (в «фінансовому» оточенні, наприклад, немає сенсу встановлювати розширення, а в деяких випадках можна обійтися без JavaScript).
- Ми зможемо робити знімки оточень для швидкого відновлення або перенесення на іншу машину.
Найпростіший спосіб розгорнути оточення на базі LXC - це скористатися Docker. В Ubuntu, Arch Linux і багатьох інших дистрибутивах Docker є в основному репозиторії, тому для його установки досить набрати одну команду:
$ Sudo apt-get install docker # Ubuntu $ sudo pacman -S docker # Arch
Далі запускаємо docker-демон. В Arch / Fedora так:
$ Sudo systemctl start docker
В Debian / Ubuntu так:
$ Sudo service docker start
Тепер ми готові розгорнути нове оточення. Зробити це не складніше, ніж встановити сам Docker:
$ Sudo docker run ubuntu top
Ця команда завантажить базовий образ оточення Ubuntu з сайту проекту, створить новий LXC-контейнер, підніме віртуальний мережевий інтерфейс і запустить команду top всередині нього. Розмір образу - близько 650 Мб, всередині мінімальна система. Для завантаження також доступні Fedora, Debian, мінімалістичний образ з BusyBox і безліч інших. Доступні також і неофіційні образи, найбільш примітний з яких magglass1 / docker-browser-over-ssh. Це вже готова збірка Ubuntu з передвстановленим Google Chrome, Firefox і форвардного X11 через SSH.
Цього разу ми не будемо відразу запускати контейнер, а просто отримаємо потрібний образ:
$ Sudo docker pull magglass1 / docker-browser-over-ssh
Коли образ буде отримано, запускаємо контейнер:
$ Sudo docker run -rm -t -i magglass1 / docker-browser-over-ssh
Після недовгої ініціалізації на екрані з'являться приблизно такі рядки:
IP address: 172.17.0.2 Password: zKksgadv8VbunE5D Firefox: ssh -X [email protected] firefox Google Chrome: ssh -X [email protected] google-chrome --no-sandbox 
Це IP-адреса оточення (він може змінюватися між запусками), рандомно згенерований пароль і команди для запуску браузерів. Тепер досить відкрити другий емулятор терміналу і набрати одну з них. Браузер буде відкритий в окремому вікні. Чи не найзручніший спосіб, зате він має ряд переваг:
- Завдяки особливостям Docker кожен новий запуск браузера відбуватиметься «в чисту». Іншими словами, нам не будуть потрібні різні варіанти оточення для різних завдань. Для того щоб зайти на потенційно небезпечний сайт або інтернет-банк, досить просто запустити нове оточення, виконати роботу і закрити.
- Такий сендбокс легко розгорнути на будь-якій доступній Linux-машині. Головне - наявність інтернету.
- SSH-форвардного дозволяє повністю відрізати контейнер від основної системи.
- Досить висока продуктивність браузера.
З недоліків можна відзначити відсутність мультімедіавозможностей. Відео буде грати не зовсім плавно, а звук не підтримується.
Запускаємо Firefox в контейнері через SSH
Тепер спробуємо створити кілька однотипних оточень для різних цілей. Цього разу скористаємося Ubuntu, чистим LXC і X-сервером Xephyr, останній дозволить нам створити віртуальний X-сервер в гостьовій машині, картинка якого буде відображатися всередині десктопа хостовой системи. Цей варіант не набагато краще проброса по SSH, він просто інший.
LXC у нас вже встановлений як залежність Docker, тому доустанавливать debootstrap і bridge-utils:
$ Sudo apt-get install debootstrap bridge-utils
Тепер створюємо новий контейнер. Назвемо його web-browser:
$ Sudo lxc-create -t ubuntu -n web-browser
Як тільки образ буде викачано по мережі, запускаємо контейнер:
$ Sudo lxc-start -n web-browser
Встановлюємо потрібний софт в контейнер:
$ Apt-get update $ apt-get install xterm openbox firefox
Тепер пишемо невеликий скрипт, який допоможе нам запустити Firefox всередині псевдодесктопа:
#! / Bin / sh # Запускаємо вкладений X-сервер Xephyr -ac: 1 -screen 1024x768 # Запускаємо Openbox і Firefox всередині цього сервера lxc-start -n web-browser - bash -c "export DISPLAY = IP-ХОСТ-СИСТЕМИ : 1; openbox & firefox "
Чи не поспішаємо запускати контейнер, а замість цього клонуємо його для отримання декількох контейнерів з браузером всередині:
$ Sudo lxc-clone -o web-browser -n web-banking $ sudo lxc-clone -o web-browser -n web-other
Так ми отримаємо кілька контейнерів, кожен з яких буде призначений для різних цілей. Скрипт запуску також можна скопіювати плюс написати десктоп-файли для створення відповідних іконок:
[Desktop Entry] Version = 1.0 Name = Firefox Comment = Access the Internet # Шлях до скрипта Exec = / home / ЮЗЕР / bin / web-browser.sh # Шлях до іконки Icon = / usr / share / pixmaps / firefox.png Type = Application Categories = Network; WebBrowser;
Щоб іконка з'явилася на робочому столі, її слід покласти в каталог ~ / Desktop.
Запускаємо контейнер в Docker
У описаних способів запуску браузера в контейнері є один істотний недолік: вони працюють з правами root і розташовуються в кореневій файловій системі. З точки зору безпеки і здорового глузду це не зовсім правильно, тому набагато краще запускати контейнери в просторі користувача.
На жаль, необхідна функціональність доступна тільки в розробляється на момент написання статті Ubuntu 14.4 і ще не вийшов LXC 1.0. Зате інструкція, як це зробити, вже є, і написана вона Стефаном грабер, тим самим людиною, який займається підтримкою пакету LXC в Ubuntu. Ні в якому разі не претендуючи на авторство методу, я приведу тут суть його циклу статей, що буде цікаво і користувачам Ubuntu 14.4, і всім тим, хто хоче дізнатися, на що здатний LXC.
Спосіб створення контейнера з розділу «LXC і Xephyr» гарантовано працює тільки в Ubuntu. В інших дистрибутивах, швидше за все, доведеться самостійно піднімати мережевий міст і формувати образ контейнера.
Отже, контейнери простору користувача використовують так звані user namespaces, що з'явилися в ядрі Linux 3.0.12. Вони дозволяють відображати певні діапазони UID і GID з хост-системи в довільні діапазони UID: GID всередині контейнера, завдяки чому непривилегированного користувача хост-системи можна зробити root'ом всередині контейнера. Вся ця функціональність контролюється ядром плюс кількома модифікованими утилітами начебто нового loginuid і утиліт пакета shadow. Також з'явилася утиліта lxc-user-nic з setuid-бітом, яка дозволяє управляти обмеженим набором мережевих налаштувань від імені непривилегированного користувача. В основному вона використовується для зміни налаштувань мережевого моста.
Спеціально для створення userspace-контейнерів розробники LXC підготували шаблон download, який автоматично викачує з Мережі регулярно оновлювану збірку Debian або Ubuntu і створює на її основі нове віртуальне оточення. Щоб отримати цю збірку (в даному випадку мова йде про Ubuntu 12.04) і створити новий контейнер (назвемо його знову ж web-browser), досить виконати одну просту команду:
$ Lxc-create -t download -n web-browser - -d ubuntu -r precise
Далі необхідно зробити так, щоб в контейнер були проброшени необхідні для виведення картинки файли пристроїв, а також сокет X11. Для цього відкриваємо конфиг контейнера ~ / .local / share / lxc / web-browser / config і пишемо в нього наступне:
# `/ Dev / dri` і` / dev / video0` для доступу до відеокарти lxc.mount.entry = / dev / dri dev / dri none bind, optional, create = dir lxc.mount.entry = / dev / video0 dev / video0 none bind, optional, create = file # `/ dev / sound` для виведення звуку lxc.mount.entry = / dev / snd dev / snd none bind, optional, create = dir # Сокет X11 для створення вікна в запущених в хост-системі іксах lxc.mount.entry = /tmp/.X11-unix tmp / .X11-unix none bind, optional, create = dir
Далі знаходимо в конфіги наступні рядки:
lxc.id_map = u 0 100000 65536 lxc.id_map = g 0 100000 65536
І замінюємо їх на такі, поставивши замість 1000 власні UID і GID в системі:
lxc.id_map = u 0 100000 1000 lxc.id_map = g 0 100000 1000 lxc.id_map = u 1000 1000 1 lxc.id_map = g 1000 1000 1 lxc.id_map = u 1001 101001 64535 lxc.id_map = g 1001 101001 64535
Все це означає, що UID / GID від 0 до 65535 в гостьовій системі дорівнюватимуть хостової 100000- 165535. Винятком буде лише UID: GID 1000 (тобто наш UID в хост-системі), він повинен бути однаковим в обох системах, що дозволить гостю працювати з іксами, відео та аудіодрайвер. Простіше кажучи, хост-система буде сприймати запущений в контейнері браузер як «рідне» додаток.
Далі виправляємо власника домашньої каталогу всередині контейнера на наш UID: GID:
$ Sudo chown -R 1000: 1000 ~ / .local / share / lxc / web-browser / rootfs / home / ubuntu
Встановлюємо Chrome всередину контейнера:
$ C = "web-browsing" $ lxc-start -n $ C -d $ lxc-attach -n $ C - umount /tmp/.X11-unix $ lxc-attach -n $ C - apt-get update $ lxc-attach -n $ C - apt-get dist-upgrade -y $ lxc-attach -n $ C - apt-get install wget ubuntu-artwork ca-certificates -y $ lxc-attach -n $ C - - wget https://dl.google.com/linux/direct/google-chrome-stable_current_i386.deb -O /tmp/chrome.deb $ lxc-attach -n $ C - dpkg -i /tmp/chrome.deb $ lxc-attach -n $ C - apt-get -f install -y $ lxc-stop -n $ C
Пишемо скрипт для запуску хрому в контейнері:
#! / Bin / sh C = "web-browser" STARTED = false if! lxc-wait -n $ C -s RUNNING -t 0; then lxc-start -n $ C -d lxc-wait -n $ C -s RUNNING STARTED = true fi lxc-attach --clear-env -n $ C - sudo -u ubuntu -i env DISPLAY = $ DISPLAY google -chrome --disable-setuid-sandbox if [ "$ STARTED" = "true"]; then lxc-stop -n $ C -t 10 fi
Скрипт перевіряє, чи запущений контейнер, якщо немає, то запускає і стартує всередині нього Chrome. Основна суть усіх цих дій полягає в тому, щоб не запускати вже працює контейнер двічі, а також отримати можливість створення і запуску кількох різних контейнерів. Для цього достатньо клонувати вже готовий контейнер так, як описано в попередньому розділі, і замінити ім'я web-browser на ім'я нового контейнера на початку скрипта.
Як і у випадку зі способом з попереднього розділу, створюємо десктоп-файл для запуску браузера при натисканні іконки:
[Desktop Entry] Version = 1.0 Name = Google Chrome Comment = Access the Internet Exec = / home / ІМ'Я-юзер / .local / share / lxc / web-browser / start-chrome% U Icon = / home / ІМ'Я-юзер / .local / share / lxc / web-browser / rootfs / opt / google / chrome / product_logo_256.png Type = Application Categories = Network; WebBrowser;
На цьому все. Такий контейнер буде кращим рішенням з усіх можливих. Він дозволяє відкривати кілька копій браузера в різних середовищах без всяких обмежень, з можливістю 3D-прискорення, виведенням звуку, плавним відтворенням відео і без зайвих віртуальних робочих столів. До речі, в оригінальному вирішенні Стефана грабер була також передбачена можливість запису звуку за допомогою PulseAudio, але я її прибрав для збереження простоти.
Chrome всередині userspace-контейнера
Контейнерна віртуалізація прекрасно підходить для запуску потенційно небезпечного софту. Вона працює в будь-якому Linux-дистрибутиві, не вимагає збірки додаткових інструментів і накладення патчів на ядро. Вона більш легковажно, ніж повноцінна віртуалізація, більш проста в розгортанні і дозволяє прозоро працювати з командним рядком і файлами всередині гостьової системи. Браузер всього лише один з прикладів додатків, які можна запустити в контейнері.
Корисні посилання
Оригінал статті Стефана грабер: goo.gl/qOa9F3
