Если вдруг вы не можете запустить контейнер с браузером, возможно в прошлый раз при закрытии не был разлочен файл ~/.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 хеш_или_тег .
Да, конечно. При помощи отображения рабочей папки в файл параметром -v в нашем контейнере оказывается локальная папка, с неё читаем, в неё пишем, на неё выдаём пользователю контейнера права ACL при помощи команды setfacl. Пожалуйста, выполните пошаговую инструкцию, которую представляет собой 1я статья этого цикла - там мы пробрасываем в контейнер папку с нашими проектами. То есть, из контейнера редактируем эти файлы и создаём новые.
Я ни в коем случае не спорю с тем, что запуск в виртуальной машине будет более безопасным для сохранения целостности хостовой ОС. Однако, в качестве стиля повседневного использования графических приложений в Линукс - не подходит. Никто так не будет пользоваться ОС. Даже если мы возьмём Qubes OS - внутри отдельно взятой виртуалки там нет изоляции процессов, а каждую программу запускать в своей виртуалке будет непрактично - мы даже потеряем возможность видеть, что у нас запущено в top. Запуская приложение в отдельном пространстве имён, мы также изолируем его от всех хостовых процессов. Виртуалка, в данном случае, будет иметь много своих хостовых процессов.
Не совсем корректно говорить, что в 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-контейнерами я вижу оптимальным для повседневного использования. У меня на ПК нет браузера вне контейнера, я его удалил.
Спасибо за конструктивный отзыв. Я сам использовал сначала flatpak, а потом snap на Debian, но вскоре отказался от них. Вот, что меня не устроило:
Пакеты flatpak и snap исполняются в том же самом пространстве имён - а это именно тот риск, от которого мы уходили в данном цикле статей.
Скачивая приложения из магазина Canonical Snapcraft, мы получаем пакет, настроенный не так, как нам нужно. Например, как в примере с KeePass2 в данной статье, мы могли бы ограничить доступ в сеть `snap disconnect keepass2:network`, но после обновления приложения эта настройка слетит, и нам нужно будет снова исполнять эту команду. А как этот момент на практике не пропустить?
Используя snap, мы переходим на автоматические обновления, то есть, не от нас даже зависит, когда пакет обновится. Мы можем влиять на частоту обновлений, но это не меняет того факта, что наша система становится, хотя-бы отчасти, rolling release.
Есть общее замечание по безопасности самих пакетов, распространяемых через магазины приложений третьих лиц. Пакеты, которые устанавливаются из репозиториев типа APT, проверяются одной командой, очень надёжной. По сути, у нас никого надёжнее и нет. Образы же snap, напротив, проверяются Canonical не очень тщательно, так как джентельмены верят друг другу на слово.
Магазин приложений snapcraft.io это собственность Canonical. Flathub развивается сообществом. В обоих случаях, тут вопрос менеджмента рисков.
По поводу размеров образов Podman - слои используются повторно для других образов, которые содержат те же самые слои, с начала до первого отличия. То есть, слой занимает место на диске только один раз. Таким образом, если мы создаём новый образ, основывая его на старом, нам выгоднее что-то приписывать в конце, чем улучшать что-то вначале :-)
Ещё мне нравится, когда конфигурация прозрачна для меня, как в случае с нашими контейнерами. Это личное предпочтение
Если вдруг вы не можете запустить контейнер с браузером, возможно в прошлый раз при закрытии не был разлочен файл
~/.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 хеш_или_тег.При помощи отображения рабочей папки в контейнер параметром
-v. ОпечаткаДа, конечно. При помощи отображения рабочей папки в файл параметром
-vв нашем контейнере оказывается локальная папка, с неё читаем, в неё пишем, на неё выдаём пользователю контейнера права ACL при помощи командыsetfacl. Пожалуйста, выполните пошаговую инструкцию, которую представляет собой 1я статья этого цикла - там мы пробрасываем в контейнер папку с нашими проектами. То есть, из контейнера редактируем эти файлы и создаём новые.Исправил на "Линукс"
Я ни в коем случае не спорю с тем, что запуск в виртуальной машине будет более безопасным для сохранения целостности хостовой ОС. Однако, в качестве стиля повседневного использования графических приложений в Линукс - не подходит. Никто так не будет пользоваться ОС. Даже если мы возьмём Qubes OS - внутри отдельно взятой виртуалки там нет изоляции процессов, а каждую программу запускать в своей виртуалке будет непрактично - мы даже потеряем возможность видеть, что у нас запущено в
top. Запуская приложение в отдельном пространстве имён, мы также изолируем его от всех хостовых процессов. Виртуалка, в данном случае, будет иметь много своих хостовых процессов.Не совсем корректно говорить, что в 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-контейнерами я вижу оптимальным для повседневного использования. У меня на ПК нет браузера вне контейнера, я его удалил.
Да, верно. Чтобы не быть мне душным, может просто "Линукс" писать? Просто "ОС семейства Линукс" для глаз долго
Спасибо за конструктивный отзыв. Я сам использовал сначала flatpak, а потом snap на Debian, но вскоре отказался от них. Вот, что меня не устроило:
Пакеты flatpak и snap исполняются в том же самом пространстве имён - а это именно тот риск, от которого мы уходили в данном цикле статей.
Скачивая приложения из магазина Canonical Snapcraft, мы получаем пакет, настроенный не так, как нам нужно. Например, как в примере с KeePass2 в данной статье, мы могли бы ограничить доступ в сеть `snap disconnect keepass2:network`, но после обновления приложения эта настройка слетит, и нам нужно будет снова исполнять эту команду. А как этот момент на практике не пропустить?
Используя snap, мы переходим на автоматические обновления, то есть, не от нас даже зависит, когда пакет обновится. Мы можем влиять на частоту обновлений, но это не меняет того факта, что наша система становится, хотя-бы отчасти, rolling release.
Есть общее замечание по безопасности самих пакетов, распространяемых через магазины приложений третьих лиц. Пакеты, которые устанавливаются из репозиториев типа APT, проверяются одной командой, очень надёжной. По сути, у нас никого надёжнее и нет. Образы же snap, напротив, проверяются Canonical не очень тщательно, так как джентельмены верят друг другу на слово.
Магазин приложений snapcraft.io это собственность Canonical. Flathub развивается сообществом. В обоих случаях, тут вопрос менеджмента рисков.
По поводу размеров образов Podman - слои используются повторно для других образов, которые содержат те же самые слои, с начала до первого отличия. То есть, слой занимает место на диске только один раз. Таким образом, если мы создаём новый образ, основывая его на старом, нам выгоднее что-то приписывать в конце, чем улучшать что-то вначале :-)
Ещё мне нравится, когда конфигурация прозрачна для меня, как в случае с нашими контейнерами. Это личное предпочтение
Сделал
То, что вы сдизайнили, в качестве системы реального времени - вполне промышленный вариант!