Комментарии 15
Можете отражать и в заголовках этого цикла, какая это часть по номеру? Например, эта вторая.
В Ubuntu браузеры Chromium и Firefox по-умолчанию уже ставится через snap, что и есть ещё одна разновидность контейнеров. Они уже настроены и изолированы от хостовой системы. Ещё бывает flatpak.
Так что запускать их в Docker - разве что как учебная задача или пример для других приложений.
Очень режет глаз простыня слоёв с RUN echo
- почему бы не объединить слои? И вообще - это просто создание двух файлов - создайте их заранее и просто положите через COPY?
Makefile и build-essentials - это, конечно, на любителя, но, мне кажется, это как из пушки по воробьям. Здесь подойдёт обычный bash-скрипт.
Впрочем, это всё мелочи. В целом - довольно неплохо всё разобрано, спасибо. Только учтите, что заворачивая всё в контейнеры, вы создаёте довольно большие имиджи на диске.
Спасибо за конструктивный отзыв. Я сам использовал сначала flatpak, а потом snap на Debian, но вскоре отказался от них. Вот, что меня не устроило:
Пакеты flatpak и snap исполняются в том же самом пространстве имён - а это именно тот риск, от которого мы уходили в данном цикле статей.
Скачивая приложения из магазина Canonical Snapcraft, мы получаем пакет, настроенный не так, как нам нужно. Например, как в примере с KeePass2 в данной статье, мы могли бы ограничить доступ в сеть `snap disconnect keepass2:network`, но после обновления приложения эта настройка слетит, и нам нужно будет снова исполнять эту команду. А как этот момент на практике не пропустить?
Используя snap, мы переходим на автоматические обновления, то есть, не от нас даже зависит, когда пакет обновится. Мы можем влиять на частоту обновлений, но это не меняет того факта, что наша система становится, хотя-бы отчасти, rolling release.
Есть общее замечание по безопасности самих пакетов, распространяемых через магазины приложений третьих лиц. Пакеты, которые устанавливаются из репозиториев типа APT, проверяются одной командой, очень надёжной. По сути, у нас никого надёжнее и нет. Образы же snap, напротив, проверяются Canonical не очень тщательно, так как джентельмены верят друг другу на слово.
Магазин приложений snapcraft.io это собственность Canonical. Flathub развивается сообществом. В обоих случаях, тут вопрос менеджмента рисков.
По поводу размеров образов Podman - слои используются повторно для других образов, которые содержат те же самые слои, с начала до первого отличия. То есть, слой занимает место на диске только один раз. Таким образом, если мы создаём новый образ, основывая его на старом, нам выгоднее что-то приписывать в конце, чем улучшать что-то вначале :-)
Ещё мне нравится, когда конфигурация прозрачна для меня, как в случае с нашими контейнерами. Это личное предпочтение
> flatpak и snap исполняются в том же самом пространстве имён - а это именно тот риск, от которого мы уходили
В них ещё используются механизмы apparmor и selinux, так что не всё так плохо.
Но если вопрос безопасности критичен и есть желание достичь более высокого уровня изоляции, чем это реализовано в flatpak/snap, может тогда не размениваться по мелочам, а запускать критичные/опасные приложения в kvm/qemu?
Я так и делаю, если мне нужно запустить какую-то незнакомую бяку. Это конечно более накладно по ресурсам, но зато уровень изоляции ещё выше.
Не совсем корректно говорить, что в snap/flatpak есть механизмы AppArmor и SELinux. Менеджер пакетов snap управляется службой snapd, а она, в свою очередь, интегрируется с механизмами мандатного управления доступа (MAC) AppArmor и/или SELinux, которые могут присутствовать или отсутствовать на хосте. Например, в Debian AppArmor включён по умолчанию, из коробки. Профили приложений для AppArmor и SELinux вам также своими руками нужно прописывать. Например, для установленного через snap пакета example-app, профиль будет находится по пути
/var/lib/snapd/apparmor/profiles/example-app.app
. Допустим, вы его отредактировали, как вам нужно. И что же - после обновления, вам придётся делать это заново, так как мандатные профили поставляются с пакетами snap. А как этот момент на практике не пропустить?Ни AppArmor, ни SELinux не помогут запускать процессы с разными UID. Они представляют собой ещё один слой прав доступа над файлами (в Линукс всё файл), подобно тому, как ACL над POSIX.
Запускать вирусы только на виртуалке - это так и надо делать, конечно. Но мы в этой статье решаем другую задачу. Контейнер - это не виртуальная машина, а процесс. Мы добиваемся изоляции обычных приложений для повседневной работы, небольшими усилиями - создать такой контейнер и менеджить параметры его запуска, как показано в данной статье, не сложнее, чем следить за профилями snap-пакетов. А изоляция - впервые настоящая (по пространству имён), да и скрипты запуска у нас перед глазами - мы значительно контроллируем ситуацию.
Каждый запуск podman-контейнера с параметром
--rm
уничтожает контейнер по завершении процесса. И при следующем запуске, он будет воссоздан из образа, чья целостность гарантирована хэш-суммой (их можно увидеть вpodman images
). Вы удаляете образ своей виртуалки каждый раз с закрытием приложения? Безопаснее ли виртуалка - вопрос дискуссионный :-)У меня открыто всегда несколько контейнеров. Например, сейчас три - chromium, keepass2 и Telegram Desktop. Они работают так же быстро, как если бы были хостовыми. Запускаются чуть дольше, да. Но они запускаются с ярлыков на рабочем столе! А виртуалка под каждое приложение - это было бы просто нежизнеспособно для повседневного использования. И не нужно, с точки зрения безопасности.
На сегодня, изложенное тут решение с podman-контейнерами я вижу оптимальным для повседневного использования. У меня на ПК нет браузера вне контейнера, я его удалил.
Каждый запуск podman-контейнера с параметром
--rm
уничтожает контейнер по завершении процесса. И при следующем запуске, он будет воссоздан из образа, чья целостность гарантирована хэш-суммой (их можно увидеть вpodman images
). Вы удаляете образ своей виртуалки каждый раз с закрытием приложения?
В виртуалках есть снапшоты и клонирование, то есть воссоздать исходный образ виртуалки или создать её клон достаточно просто.
Я ни в коем случае не спорю с тем, что запуск в виртуальной машине будет более безопасным для сохранения целостности хостовой ОС. Однако, в качестве стиля повседневного использования графических приложений в Линукс - не подходит. Никто так не будет пользоваться ОС. Даже если мы возьмём Qubes OS - внутри отдельно взятой виртуалки там нет изоляции процессов, а каждую программу запускать в своей виртуалке будет непрактично - мы даже потеряем возможность видеть, что у нас запущено в top
. Запуская приложение в отдельном пространстве имён, мы также изолируем его от всех хостовых процессов. Виртуалка, в данном случае, будет иметь много своих хостовых процессов.
Для повседневного пользования бывает необходимо открыть в браузере локальный файл. Получится ли это с контейнеризированным браузером? С виртуальной машиной без дополнительных усилий это тоже просто так не выйдет, но это одна из причин, по которой я не пользуюсь контейнеризированным браузером в Убунте и заменяю его на deb-версию.
Да, конечно. При помощи отображения рабочей папки в файл параметром -v
в нашем контейнере оказывается локальная папка, с неё читаем, в неё пишем, на неё выдаём пользователю контейнера права ACL при помощи команды setfacl
. Пожалуйста, выполните пошаговую инструкцию, которую представляет собой 1я статья этого цикла - там мы пробрасываем в контейнер папку с нашими проектами. То есть, из контейнера редактируем эти файлы и создаём новые.
При помощи отображения рабочей папки в контейнер параметром -v
. Опечатка
Linux это не OC, а ядро :)
Если вдруг вы не можете запустить контейнер с браузером, возможно в прошлый раз при закрытии не был разлочен файл ~/.config/chromium/SingletonLock
. Так как папка .config
отображается в контейнер строчкой -v /opt/${IMG_NAME}/config:/home/${USRNME}/.config:rw
, то просто удалите этот файл командой rm /opt/chromium/config/chromium/SingletonLock
. После этого, должно запуститься.
Если вы собираете разные образы, экспериментируете и вдруг начинаете получать ошибки, каких ранее не получали, то подмана можно привести в консистентное состояние командой podman system migrate
. Это приведёт к остановке всех контейнеров.
Периодически стоит проверять, не осталось ли 'бесхозных' контейнеров с прошлых запусков командой podman ps --all
с целью поудалять их podman rm хеш_или_тег
.
Подмания: запускаем графические приложения в контейнерах. Часть 2