Авторские статьи

Графический способ дать разрешения программам snap.


Тихо и незаметно для меня графический инструмент установки софта Ubuntu Software обзавёлся возможностью выдать дополнительные возможности данной программе, а точнее соединить slot с plugs, что раньше мы делали только в консоли. В этом месте я хотел бы вернуться в прошлое и вспомнить как всё это только начиналось.

Графика для механизма соединений в технологии snap

Людям всегда проще всё визуализировать и пока это не представлено в удобном графическом виде, то немногие могут понять зарождающуюся технологию. Что она принесёт? Реально ли она хороша и расцветёт?

С релиза Ubuntu 16.04 нам дали попробовать самодостаточные пакеты snap. И сразу же грязь и выставленные штыки. Всё началось с грамотной технической статьи Мэтью Гаррета (Matthew Garrett), где он указал на очевидное - пока жив и используется X11 (Xorg), безопасность snap не реализуется в полной мере и до конца. Так создан в далёкие годы X11, что любое приложение может инжектировать ему события в потоки ввода-вывода. Сам Мэтью пишет, что такого нет в современных дисплейных серверах Mir и Wayland. Но журналюги всё "лишнее", на их взгляд, выкинули и Интернет запестрел новостями - snap не безопасен, snap атцтой.

Но в те времена, я часто разговаривал со своими коллегами, которые в мире MS Windows обслуживали критически важные ПК, с установленными системами мандатного доступа (mandatory access control, MAC) типа Secret Net или Dallas Lock. Мне были понятны их проблемы и мучения, когда в графической MS Windows на десктопной машине нужно заставить работать софт в ежовых рукавицах. Другими словами, системы подобные Secret Net или Dallas Lock превращали классическую Windows (DAC) в неприступную MAC систему. Приведу пример. В обычной MS Windows (DAC) если вы запустите программу под учётной записью Администратор, то она получит излишние права и сможет сделать всё что угодно. Если будет работать система мандатного доступа, то её профиль (шаблон) будет держать программу в рамках заранее разрешённых правил и возможности DAC не будут решающими. Естественно, в обычной жизни все стараются применять принцип минимальных привилегий (англ. Principle of least privilege), но общую мысль вы, надеюсь, поняли - MAC строже DAC.

Я проводил параллели с установленным по умолчанию AppArmor в моей Убунту и размышлял, а разовьются ли десктопные Linux системы до того, чтобы стать ещё безопаснее и перейти из традиционного мира discretionary access control (DAC) в более суровый MAC? Это просто невероятно сложная задача и мои самостоятельные шаги по созданию профиля для Adobe Reader и Opera это только подтверждали. Сразу было понятно что всё упрётся в человеческий фактор. Сообщество вокруг AppArmor (да и у SELinux) большое, но создавать профиля под +100500 софта и постоянно актуализировать профиля вслед за изменением в функционале софтины - это сизифов труд. Вот почему AppArmor, как пристяжная лошадь, вроде как и есть в системе, но профилями защищает лишь критически важную, но малую часть. Профиля сделаны лишь на основные сетевые службы, слушающие сеть, да браузеры. Можете глянуть на досуге в каталог /etc/apparmor.d/

И тут Canonical предложила формат snap, как решение проблемы с ручным визированием софта в репозиториях, устраняя человеческий фактор при review. Более подробно в статье Процесс загрузки приложения в репозиторий Ubuntu. С самого рождения технологии вводится философия ограничений (security confinement) для snap, которая собственно и позволяет гарантировать автоматическое одобрение софта после вереницы тестов. И главная задумка состоит в том, чтобы снять нагрузку при визировании софта с плеч небольшого количества сопровождающих (maintainer) и перенести на армию авторов-снапкрафтеров. Автор программы точно знает функционал своего детища, а даже если снапкрафтер не является автором, то при упаковке подопечного он будет вынужден разобраться в софте и в декларативной форме описать что необходимо софту от системы в файле snapcraft.yaml. Данные хотелки будут автоматически развёрнуты в правила AppArmor и в системные белые списки seccomp.

В то время я всеми фибрами души прочувствовал эту крутую мысль, что впервые на Linux десктоп идёт своей мощной поступью система мандатного доступа, чтобы стать всеобъемлющей. Перестать быть пристяжной лошадью, а занять место коренной. Тогда не было графического интерфейса к snap даже для установки софта и приходилось лабать в консоли. Но опыты с сетевым сканером nmap, которого одного из первых представили в snap формате, показал как же это всё круто. Если бы я поставил nmap через deb, то он бы обитал в мире традиционных разрешений rwxr-x-r-- и мог бы делать всё что он захочет, получив права доступа от моей учётной записи. Но в мире MAC всё строже и к традиционным разрешениям ещё прилагаются профиля "чуть-влево-чуть-вправо-расстрел-на-месте"

nmap -iL /home/vasilisc/report.txt

Failed to open input file /home/vasilisc/report.txt for reading 
QUITTING! 

Nmap не может взять из домашней папки файл, так как я не давал ему разрешения. Точнее говоря, в терминах snap у программы nmap нет connect'а к слоту home системы, а значит в нижележащем слое у AppArmor нет кусков правил, разрешающее такое для данной программы. Разработчики технологии snap все интерфейсы поделили на 2 большие группы: автоподключаемые и нет. Полный список интерфейсов вы можете увидеть в документации Core interfaces reference. Если напротив названия интерфейса в поле Auto-connect стоит yes, то автор программы (и/или снапкрафтер) может попросить в декларативной форме к ним подключиться и при установке программы snap в системе это будет сделано автоматически. А вот подключить программу к интерфейсам, которые Auto-connect = no, до сих пор можно было только в консоли.

И вот теперь товарищи, финальный аккорд! Вишенка на торте! Графический интерфейс к механизмам connect/disconnect в Ubuntu Software.

gui snap connect/disconnect

Сколько уже лет прошло и вот, оглядываясь назад, понимаешь что технология самодостаточных пакетов snap, несмотря на недопонимание и отторжение у части сообщества, начала превращать Linux системы из DAC в MAC. В идеальном будущем, весь софт будет отделён друг от друга и от системы, что позволит провести некоторый "водораздел ответственности", облегчающий труд как системных программистов, работающих над развитием операционной системы, так и труд прикладных программистов, чей софт не будет ломаться всякий раз при изменении в фреймворках/библиотеках/компонентах.

Выиграют все:

  • Системные программисты получат возможность легко и просто изменять операционную систему, не опасаясь что их труд заденет вышестоящий слой прикладных программ. Можно смело менять API/ABI и делать резкие развороты.
  • Прикладные программисты перестают быть зависимыми от системных программистов и от зоопарка Linux систем с их различными версиями фреймворков/библиотек/компонент. Не нужно теперь прилагать огромные усилия, чтобы пропихнуть свою бесплатную программу в официальные репозитория основных linux игроков. Софт, если прошёл вереницу тестов, автоматически визируется и попадает в Store. Прикладной софт может коннектиться к snap пакету конкретной версии фреймворка, что позволит существовать нескольким версиям одной и той же программы, что невозможно в традиционном линуксе.
  • Пользователь получает всегда свежий софт от автора и может быть уверен, что изменения в его системе не сломают софт и vice versa. Более жёсткий контроль над программой позволяет курировать вопросы - что и как может программа? Софт не привязан к версии релиза системы.
  • Сопровождающие из мира deb продолжают свою тяжёлую работу, а количество проверяющих хранилище можно легко удерживать в разумных рамках при росте количества софта. Автоматические тесты и правила AppArmor гарантируют работу софта в рамках профиля. Ручное визирование софта вызывается лишь при любой остановке автоматического теста и обычно это редкое событие, которое вызывает нарекание в сторону снапкрафтера. Мой личный пример доказывает!

Итог

Технология snap с самого своего рождения была создана быть безопасной и решить вопрос с убыстрением попадания свежего софта в хранилище, а из него на столы пользователей. Образно можно сказать что, благодаря snap, вы бесплатно получаете аналог MS Windows + Secret Net. Как пользователь, вы должны радоваться данной технологии, которая быстро и безопасно принесёт вам свежий софт от авторов, гарантируя транзакционное обновление и давая возможность откатов при каких-либо проблемах.

Дополнительные материалы

Многих интересует и интригует новая технология. Задаются вопросы типа таких: а можно ли упаковать зловреда и люди его скачают к себе на ПК? Ответы в статье Доверие и безопасность в Ubuntu Snap Store

Детальное сравнение как работает установка софта и его запуск в системе. Механизмы DAC и MAC во всей красе. Мир Snap против мира Deb

По ряду причин, данный софт никогда не был представлен в удобной форме пользователям. Мои опекаемые в snap пакетах, доступные в Ubuntu Software:
Первый snap пакет. Java программа LanguageTool.
Второй snap пакет. GTK программа DeaDBeeF.
Третий snap пакет. Java программа TuxGuitar.
Четвёртый snap пакет. Java программа Vuze.
Пятый snap пакет. Java программа osddm.
Шестой snap пакет. PAC (Perl Auto Connector).
Седьмой snap пакет. DRAKON (Дружелюбный русский алгоритмический язык, который обеспечивает наглядность).
Восьмой snap пакет. AceStreamPlayer.
Девятый snap пакет. XnSketch.
Десятый snap пакет. XnViewMP.

Дата последней правки: 2018-11-02 13:26:08

RSS vasilisc.com   


Разделы

Главная
Новости
Ворох бумаг
Видео Linux
Игры в Linux
Безопасность
Статьи об Astra Linux
Статьи о FreeBSD
Статьи об Ubuntu
Статьи о Snappy
Статьи об Ubuntu Phone
Статьи о Kubuntu
Статьи о Xubuntu
Статьи о Lubuntu
Статьи об Open Source
Карта сайта