Toolbox: Изолированные среды разработки для защиты от ошибок и вредоносных программ в разрабатываемом коде

Вам нужен постоянный пользовательский контейнер без вашего / home? Просто пытаюсь лучше понять требования / варианты использования. - Скажем, по сравнению со стандартным одноразовым контейнером Fedora?

Рассмотрим учетную запись Unix, которая используется как дома, так и на работе. Для рабочего контейнера я могу предпочесть монтировать в контейнер только мой рабочий каталог.

Рассмотрим ненадежное приложение с графическим интерфейсом. Для загрузки / сохранения файлов может потребоваться только доступ к определенной папке. Ему не нужен доступ к моей папке .ssh и другим несвязанным файлам.

В целях повышения безопасности Chrome OS по умолчанию не передает папки в контейнеры с хоста. Там, если вы хотите предоставить данные в контейнеры из вашего домашнего каталога или с USB-накопителя, вы явно делитесь ими.

Контейнеризация как функция безопасности теряет значительную ценность, если вы по умолчанию передадите ненадежному контейнеру все свои данные!

@juhp Я вижу, вы много работаете с пакетами Haskell. Предположим, что один из пакетов Haskell, которые вы устанавливаете удаленно, был скомпрометирован. Нужен ли пакетам Haskell доступ к вашей папке .ssh или к вашему биткойн-кошельку? Зачем по умолчанию делиться всем в среде разработки Haskell?

Совсем недавно появился модуль NPM, который все еще мог бы локальный биткойн, если бы он был установлен:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

Модуль был популярен, и на самом деле моя команда установила его в наше дерево. Мы не соответствовали другим критериям, позволяющим вызвать кражу биткойнов, но этот риск был бы полностью снижен, если бы наша среда разработки не имела полного доступа к нашим домашним каталогам по умолчанию. Ни один сотрудник не стал бы использовать свой биткойн-кошелек в этой среде разработки.

Это абсолютно верно, но будет сложно.

С практической точки зрения, я думаю, что лучший путь - упростить запуск наборов инструментов в качестве отдельных пользователей (временно создавать новые идентификаторы пользователя, каждый со своими собственными /home ) - для этого требуется привилегированная системная служба.

Теперь, если вы хотите поделиться некоторыми файлами, например, только для чтения - это становится еще сложнее.

Можно ли исключить файлы / каталоги из каталога bind-mount?

Чтобы убедиться, что я понимаю проблему, я вижу, что установка домашнего каталога происходит в одной строке кода.

    --volume "$HOME":"$HOME":rslave

Но проблема здесь по-прежнему заключается в том, чтобы заставить работать приложения с графическим интерфейсом и некоторые другие функции, потому что эти функции ожидают, что пользователь внутри и вне контейнера будет одинаковым?

На самом деле это довольно важная особенность. Я думаю, что по умолчанию можно смонтировать домой, но можно использовать контейнер ненадежным образом. Установка дома в контейнер предполагает, что вы доверяете контейнеру, что в случае одноразового контейнера часто бывает не так. Даже в простых случаях, таких как тестирование какого-либо модуля NPM, я хотел бы быть уверен в том, что он не повредит мою домашнюю папку.

@markstos, может быть, вы можете проверить, что вы можете делать без домашнего монтирования или если просто монтируете определенный каталог (cwd)?

@juhp На самом деле для меня это было остановкой - я перестал оценивать Silverblue, как только столкнулся с этой отсутствующей функцией. Если это решено, я могу еще раз взглянуть на Silverblue. Я также был разочарован, обнаружив, что было непросто понять, как запустить контейнер Ubuntu, а это операционная система, которую я использовал раньше.

Если Fedora хочет приветствовать пользователей из других дистрибутивов Linux, то для начала было бы неплохо упростить запуск их старого дистрибутива в контейнере.

@markstos спасибо - я просто еще один пользователь Toolbox. :-)
Я полностью согласен с тем, что расширение Toolbox для поддержки большего числа операционных систем действительно было бы очень полезно.
Обратите внимание, что Toolbox также работает без Silverblue (то есть в других редакциях Fedora).

@juhp На самом деле для меня это было остановкой - я перестал оценивать Silverblue, как только столкнулся с этой отсутствующей функцией

Что ты делал раньше? Есть ли какой-нибудь другой инструмент / подход, который вы использовали, который не работал с Silverblue?

Ничто совершенно не мешает вам, например, использовать одноразовую виртуальную машину (например, QubesOS) или, если на то пошло, иметь собственный скрипт, который реализует некоторые предложения из этого потока. Возможно, нам следует быть более самоуверенными и встроить в Silverblue функциональность, подобную QubesOS.

Но в любом случае существующие виртуальные машины и контейнерные технологии есть. Фактически, toolbox сегодня - это действительно набор скриптов, которые заставляют podman намеренно размываться с хостом. Если вам не нужна интеграция, вы можете начать с podman run ... так как это значение по умолчанию.

@cgwalters Я начал использовать Chrome OS на своем личном ноутбуке и оценил безопасность работы моей среды разработки (и почти всего остального) в контейнере в виртуальной машине через проект
url
Вместо этого я пробовал использовать аналогичные решения на своем рабочем ноутбуке. Одним из вариантов может быть Cloudready от Neverware - ОС Chrome с открытым исходным кодом для оборудования ПК. Иногда случаются порты, с которыми Crostini вылетает, данные теряются и необходимо начинать заново. По этой причине я не решаюсь удвоить сейчас ChromeOS / Crostini.

Silverblue также выглядел убедительно, пока я не обнаружил, что он, похоже, не поддерживает контейнеры Ubuntu из коробки, и он чрезмерно делится моими личными данными с контейнерами, которым я не собираюсь доверять. Я также посмотрел на Clear Linux. Он имеет ту же концепцию запуска почти всего в контейнерах. Я не в восторге от тесных связей с Intel и x86. Это также не в первую очередь настольная ОС. Последний вариант (по умолчанию?) - придерживаться Ubuntu в качестве рабочего стола и переносить больше моих разработок в контейнеры LXD, которые использует Chrome Crostini. Я должен иметь возможность копировать контейнеры LXD между моим рабочим и личным ноутбуками, даже если операционная система хоста отличается. Используя шаблоны LXD, я смогу настроить общий доступ шаблонов к контейнерам для поддержки Wayland.

примечание: Спасибо за все годы поддержки Rhythmbox!

Возможно, я неправильно понимаю миссию toolbox . Из README:

.. Эти системы предназначены для предотвращения установки программного обеспечения на хост.

Почему? По умолчанию все ваши личные данные передаются в контейнер по умолчанию, я не думаю, что можно требовать повышения безопасности.

Оставшаяся потенциальная выгода - изоляция, чтобы вы могли устанавливать конфликтующие версии программного обеспечения бок о бок.

Если поведение постоянного общего доступа сохраняется, было бы полезно обновить документы, пояснив, что toolbox разделяет весь ваш домашний каталог с контейнерами, что поведение нельзя отключить и его не следует использовать с ненадежными контейнеры.

Я понимаю, что могу использовать podman напрямую, но меня интересовало контейнерное решение с интеграцией с графическим интерфейсом. При поиске того, как добиться этого с помощью podman , рекомендуется использовать toolbox :

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos Если вам интересно, я создал PR # 298, который собирает образ Ubuntu 19.04.

Думаю, тут какая-то путаница.

Наша README.md немного выросла и изменилась за месяцы, и, вероятно, ее немного сложнее понять. Раньше он просто говорил: « Взломать Fedora на основе OSTree» .

Если вы установите Silverblue (или любую другую ОС на основе OSTree), сложность отладки ОС или настройки среды разработки становится очевидной. Набор инструментов существует для решения этой проблемы.

.. Эти системы предназначены для предотвращения установки программного обеспечения на хост.

Почему? По умолчанию, по умолчанию все ваши личные данные помещаются в контейнер, я
не думаю, что можно требовать улучшения безопасности.

Безопасность - это перегруженное слово. Toolbox не делает никаких заявлений по этому поводу.

В течение многих десятилетий любой процесс, выполняемый как ваш UID, мог просматривать ваши личные криптографические ключи, документы, фотографии и т. Д. И даже передавать их на полпути через планету без вашего ведома. Это статус-кво клиентских ОС с бесплатным программным обеспечением.

Flatpak меняет это, разделяя каждое графическое приложение и операционную систему на свои собственные домены безопасности. Silverblue укрепляет это разделение, затрудняя установку программного обеспечения непосредственно внутри образа хост-ОС. Итак, для удобного взаимодействия с пользователем вам действительно нужно использовать приложения, поставляемые как Flatpaks.

Однако, как я уже упоминал выше, этот заблокированный образ ОС представляет собой собственный набор проблем. То, как мы их решаем, - это компромисс между удобством и безопасностью. Чем более радикальным будет решение, тем сложнее будет для существующих пользователей Linux принять Silverblue.

На данный момент Toolbox склоняется к принятию, а не к безопасности; потому что, независимо от того, используете ли вы Toolbox или нет, Silverblue действительно значительно улучшает состояние клиентских ОС со свободным программным обеспечением, и передача его в руки пользователя будет положительным шагом.

Кроме того, речь идет не только о безопасности. Это еще и стабильность.

Обычный дистрибутив Linux очень сложно протестировать. Пакеты и зеркала всегда обновляются случайными участниками на случайных зеркалах по всему миру - комбинаторным взрывом можно управлять только с помощью сложной системы зависаний. Когда что-то идет не так, а это происходит, пользователю также очень сложно отменить обновление, и такие вещи, как отключение электроэнергии в середине обновления, могут безвозвратно сломать систему.

ОС на основе OSTree все меняет.

Я понимаю, что могу использовать podman напрямую, но меня интересовало контейнерное решение с графическим интерфейсом.
интеграция. При поиске того, как добиться этого с помощью podman, используйте набор инструментов.
рекомендуемый подход:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

Вопрос в том, почему вы хотите использовать Podman для запуска графических приложений? :)

В общем, Podman (или контейнер OCI) - плохой вариант для запуска приложений с графическим интерфейсом. Вот и вся причина, по которой существует Flatpak, а Toolbox с ним не конкурирует.

Однако есть совпадение в том смысле, что контейнеры Toolbox имеют некоторую интеграцию с рабочим столом, и есть некоторые случаи, когда возможность запускать приложение с графическим интерфейсом без Flatpaked чрезвычайно полезно в ближайшей краткосрочной перспективе. Возможно, приложение, которое вы хотите, еще не было Flatpaked, или, возможно, в версии Flatpaked отсутствуют некоторые функции. Возможно, вы работаете над какой-то библиотекой, которая используется графическими приложениями, и хотите быстро запустить разовую тестовую программу, чтобы убедиться, что ваша библиотека работает должным образом.

Toolbox действительно может помочь в таких случаях, но это отличается от того, чтобы сказать, что основная цель Toolbox - контейнеризация графических приложений. Основная цель Toolbox - дать вам возможность взломать ОС на базе OSTree.

Теперь, если бы вы использовали встроенную в контейнер IDE, такую ​​как GNOME Builder , которая поставляется как Flatpak, и автоматически настраивает контейнер для сборки и запуска программного обеспечения, над которым вы работаете, тогда вам вообще не понадобится Toolbox.

Однако не все используют GNOME Builder, и самые популярные IDE, такие как Visual Studio Code, не являются контейнерными. Следовательно, Toolbox.

@debarshiray Спасибо за вдумчивый и обстоятельный ответ. Пример, который я привел выше, не относился к графическим приложениям, которые могут быть покрыты Flatpak. Я привел пример разработки Node.js. Недавно в цепочке зависимостей Node.js появилась настоящая вредоносная программа, которая могла украсть из локального криптокошелька. Ключи SSH могут быть украдены так же легко. В то время как README говорит, что проект нацелен на разработчиков, общий доступ к контейнерам по умолчанию не защищает разработчиков от такого рода атак.

Toolbox не обеспечивает защиту от кражи личных файлов при разработке интерфейса командной строки с любыми ненадежными зависимостями. Учитывая сложность современного программного обеспечения с открытым исходным кодом, обязательно должны быть некоторые части дерева зависимостей, которым нельзя доверять.

Я считаю, что текущий README вводит в заблуждение: запуск «полностью непривилегированных в контейнере» звучит как безопасность, но это всего лишь театр безопасности - все личные файлы доступны в контейнере. Выше вы поясняете, что Toolbox не намерен делать никаких заявлений о безопасности. Я думаю, что это было бы полезным заявлением для включения в README, чтобы пояснить, что, несмотря на использование контейнеров, это инструмент для удобства, а не безопасности.

@debarshiray Спасибо за вдумчивый и обстоятельный ответ. Пример, который я привел
Вышеупомянутое не предназначалось для графических приложений, которые могли быть покрыты Flatpak. Я дал
пример разработки Node.js. Недавно в Node.js было настоящее вредоносное ПО.
цепочка зависимостей, которая может украсть из локального криптокошелька. Ключи SSH могут быть украдены
так же легко. В то время как README говорит, что проект нацелен на разработчиков,
share-with-container-by-default не защищает разработчиков от такого рода атак.

Да, в настоящий момент Toolbox просто пытается воспроизвести традиционную среду на основе пакетов в ОС на основе образов.

Я считаю, что текущий README вводит в заблуждение: запуск "полностью непривилегирован в контейнере"
звучит как безопасность, но это всего лишь театр безопасности - все личные файлы доступны в
контейнер. Выше вы поясняете, что Toolbox не намерен делать никаких заявлений о безопасности.
Я думаю, что это заявление было бы полезно включить в README, чтобы пояснить, что, несмотря на
использование контейнеров, это инструмент для удобства, а не безопасности.

Коммит c047659c1d85ca982374da5c58ee7a24ba3847bd - это место, где была добавлена ​​эта строка. Я считаю, что @cgwalters намеревался сказать, что у вас есть доступ только к своему собственному UID внутри контейнера панели инструментов, а настоящий корень (например, UID 0 на хосте) не задействован и не доступен для вас.

У меня тоже такая же проблема. Я установил Silverblue в надежде, что смогу запускать программное обеспечение, которому я не могу полностью доверять, не беспокоясь о том, что оно крадет мои SSH-ключи и другую конфиденциальную информацию.

Осознание того, что набор инструментов не позволяет мне это сделать, было огромным разочарованием и заставило меня с самого начала пересмотреть использование Silverblue. Лично меня не волнует установка основной ОС. Я всегда могу переустановить это. Информация, которую я хочу сохранить отдельно, находится в моем домашнем каталоге.

Можно ли с большей степенью детализации указать, какие именно части домашнего каталога используются совместно? Если бы можно было занести в белый список только те каталоги, которые необходимы для панели инструментов (возможно, те, которые относятся к конфигурации рабочего стола и т. Д.), Это решило бы множество проблем.

Теперь я прекрасно осведомлен о проблемах с безопасностью. Поскольку я использую Qubes OS несколько лет, проблема изоляции является сложной. Даже если вы защитите домашний каталог, этого будет недостаточно, поскольку программа, работающая внутри контейнера, всегда может воспользоваться другими средствами связи между контейнерами, такими как буфер обмена. Я знаю об этом и готов принять некоторые из этих рисков в обмен на удобство чего-то вроде набора инструментов по сравнению с полной установкой Qubes.

Обходной путь опубликован здесь .

Обходной путь использует тот факт, что toolbox реализован как сценарий bash, который ссылается на переменную среды $HOME во всех случаях, когда необходимо найти путь к /home/user . Таким образом, установка переменной окружения $HOME для конкретного вызова toolbox приводит к тому, что каталог, отличный от всего вашего домашнего каталога, заполненный ценными личными файлами, будет передан потенциально ненадежному контейнеру.

Исходя из этого, похоже, вы можете поделиться пустым каталогом, содержащим только конфигурацию панели инструментов, запустив панель инструментов с оболочкой примерно так:

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

Если бы этот сценарий был назван toolbox и поместил в ваш $ PATH перед системным toolbox , то, похоже, он решил бы эту проблему. Это решение не проверено.

Эта функция теперь работает в форке tlbx : https://gitlab.com/uppercat/tlbx/issues/3

У меня тоже такая же проблема. Я установил Silverblue в надежде, что смогу
запускать программное обеспечение, которому я не могу полностью доверять, не беспокоясь о том, что оно крадет мой SSH
ключи и другая конфиденциальная информация.

Эмм ... это кажется обманчивым. Если вы хотите запускать ненадежное программное обеспечение как пользователь, Flatpak уже снижает ваши опасения по поводу потери конфиденциальной информации. Другое дело, если вам нужны изолированные среды разработки.

Кроме того, все это никоим образом не связано с Silverblue. Проблемы существуют десятилетиями, и их решения не относятся к Silverblue - они работают и с традиционными операционными системами на основе пакетов.

Обходной путь использует тот факт, что toolbox реализован как сценарий bash, который
ссылается на переменную среды $HOME во всех случаях, когда путь /home/user
нужно искать. Итак, установив переменную окружения $HOME для конкретного
вызов toolbox вызывает каталог, отличный от всего вашего домашнего каталога, полный ценных
личные файлы для совместного использования с потенциально ненадежным контейнером.

Да, это отличная хитрость. :)

Однако основная цель проекта Toolbox состоит в том, чтобы дать возможность настраивать широкий спектр сред разработки в операционных системах на основе образов (в частности, на основе OSTree) с примерно такими же усилиями, которые необходимы для их аналогов на основе пакетов. Сделать эти среды разработки более безопасными, безусловно, является обоснованным желанием, но это не то, что нужно сделать в ближайшем будущем, потому что проблема не нова и существует с тех пор.

Кроме того, Silverblue не обязательно связан с безопасностью. Я считаю это скорее улучшением стабильности и надежности операционной системы. Тем не менее, он поощряет использование Flatpaks, поэтому в этом смысле косвенно повышает безопасность.

Следовательно, есть смысл в обеспечении паритета функций с пакетными дистрибутивами Linux, даже если он сохраняет некоторые из их существующих проблем. Лучше решить некоторые проблемы и сделать решения доступными для существующей базы пользователей, чем ничего не решать. :)

Я собираюсь закрыть эту проблему, чтобы список открытых проблем не вышел из-под контроля и продолжал примерно отражать элементы, которые находятся в текущем списке дел. Тем не менее, он все еще будет доступен для использования в будущем.

Я согласен с тем, что наш README.md должен быть более читабельным.

Хм, я не понимаю этого аргумента. Просто потому, что проблема старая и существует всегда, просто не решайте ее ?? ИМХО, это не лучшая точка зрения.
И, как вы говорите, Flatpak делает это: он шаг за шагом повышает безопасность и изолирует приложения. Они также не сказали: «Хм, мы всегда поставляли приложения в виде пакетов rpm, зачем нам решать эту проблему?», Они просто решили ее.

Я не вижу причин, по которым набор инструментов не должен изолировать, по крайней мере, и домашний каталог. Думаю, обсуждение в любом случае можно продолжить на https://github.com/containers/toolbox/issues/348 .

Я думаю, что участники и сопровождающие Toolbox воспринимают эту ветку как резкую критику идеи и работы, которая вкладывается в проект. Я думаю, это следует воспринимать как особенность, которая требуется многим людям, увлеченным этой идеей. Я не сопротивляюсь работе над функцией, которая позволяет монтировать рабочий каталог, отличный от $ HOME. Это функция, которая может значительно улучшить функциональность и возможности использования, что также улучшит принятие и интерес.

Я был тем, кто предложил изменить переменную $ HOME в # 348. Это хакерское решение, потому что оно вызывает проблемы, когда вы хотите работать с двумя несколькими контейнерами с разными каталогами $ HOME. Я опасаюсь, что даже это не сработает, когда набор инструментов будет переписан с помощью go.

Многие люди просят об этой функции, и для многих это стало препятствием для внедрения наборов инструментов, rpm-ostree и silverblue. Даже если речь идет не о безопасности, это функция, которая откроет множество возможностей для работы с наборами инструментов.

Я готов помочь в этом вопросе, если смогу, и я думаю, что другие тоже захотят. Я надеюсь, что эта функция не станет предметом споров и не будет включена в будущие выпуски набора инструментов. На мой взгляд, это единственное, чего в нем сейчас не хватает. Это все равно что получить dnf в марафоне из-за того, что бросил последние 10 метров. (предназначен каламбур :))

Для меня это было нарушением сделки. Я отказался от набора инструментов и Silverblue после
найти этот недостаток.

Просто потому, что проблема старая и была всегда,
просто не решай ?? ИМХО, это не лучшая точка зрения.

Отсутствие чего-то в ближайшем списке дел - не то же самое, что не решать его . Есть такое понятие, как приоритет .

И как вы говорите, Flatpak делает это: он шаг за шагом повышает безопасность и
изолирует приложения. Они также не сказали "хм, мы поставляем приложения как
rpm пакеты навсегда, почему мы должны решать эту проблему? ", они только что
реши это.

Мне нравится, как вы употребляете слово « они» .

Хорошо, хорошо, так что, если я правильно интерпретирую, это все еще может быть идеей на будущее, только не в вашем «списке ближайших дел»? (хотя я думаю, что это легко реализовать, особенно если вы можете просто выбрать несколько патчей из вилки ) *

Если так, может быть, просто оставьте эту проблему открытой и пометьте ее как «требуется помощь» - хотя вам действительно не нужна помощь, не знаю… что мешает вам реализовать это? Думаю, вам просто нужно сказать, что вы принимаете PR по этой теме, и это будет реализовано.
Я не вижу ничего, что вам мешало бы - и вы все еще можете добиться паритета функций или около того, что угодно ... это действительно лишь второстепенная функция. : мышление:

* Да, я вижу и знаю, что теперь это было переписано в Go, но, возможно, это все еще помогает или что-то в этом роде - не знаю. По крайней мере, это показывает, что это легко реализовать.

Здесь немного поработаем над этой проблемой на случай, если кто-то из участников захочет проверить и оставить отзыв о моем прототипе на https://gitlab.com/bkhl/etui.

Он предназначен как альтернатива Toolbox, когда вам нужен более строго ограниченный контейнер для разработки.

@bkhl Спасибо! Добавлен в закладки.