В инструментарии для создания самодостаточных пакетов Flatpak выявлена уязвимость (CVE-2021-21261), позволяющая обойти режим sandbox-изоляции и выполнить произвольный код в окружении основной системы. Проблема устранена в версиях 1.10.0 и 1.8.5, но позднее в исправлении всплыло регрессивное изменение, вызывающее проблемы при сборке на системах с прослойкой bubblewrap, установленной с флагом setuid. Регрессия устранена в выпуске 1.10.1 (обновление для ветки 1.8.x пока недоступно)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54461
Уязвимость в Flatpak, позволяющая сделать ненужное нужным?
Уязвимость в Flatpak, позволяющая сделать из установщика изолированых пакетов просто установщик пакетов в себе.
Уязвимость во Flatpak, позволяющая сделать из установщика изолированых пакетов просто установщик дыр.
Так и есть, в общем-то. Зависимости третьей стороны в каждом пакете свои, неизвестно кто собирает, а то и просто чужие готовые бинари.Если исходники нужного приложения ещё можно посмотреть/пересобрать, например. То зависимости - трудоёмко.
Выходит, тащишь в систему непроверяемый/неизвестный код третьей стороны. А вот классическое устройство дистрибутива позволяет легко получить и собрать все части - apt get install *src*deb
>А вот классическое устройство дистрибутива позволяет легко получить и собрать все части
>aptНе позволяет.
Депенденси Хелл протухшие либы и конфликты зависимостей.
Таких проблем не существует.
Типа того.В инфраструктуре дистра собрать удавалось с меньшими трудозатратами. Чем разбежавшийся зоопарк третьей стороны.
Может потому как дистр славен своей системой контроля качества. Бывают и другие, да.
Именно поэтому, я за NixOS!
Snap нужнее не стал.
Почему? Ставить всякий прикладной софт через snap нежели из пакетов, самое оно, когда каждая софтина живёт в своём snap-окружении (и она не может попортить/почитать конфиги соседних приложений одного юзера из его .config папки, и другие не могут, т.к. монтируется snapfs с целоостностью бинарников.Всякие телеграмы, хромы, прочая снедь, ей самое место в снап, так надёжнее и дешевле чем заводить lxd или kata-containers для каждого.
У известных пакетов типа apache, mysql я понимаю по своему юзер/группе и это решается стандартными правами.
Но заводить по юзеру на каждое прикладное? И как оно в десктопе, в контексте одного $home жить будет?
Умных все корчат и вторят ернуду.
А ещё в snap унифицирован контроль над ресурсами приложению, можно в один чих дать или нет интернет/сеть приложению, дать или нет соединению с другими, микрофон, камера, все все видно что потребляет приложение и можно дать/забрать.
> когда каждая софтина живёт в своём snap-окруженииКак и во флатпак
> А ещё в snap унифицирован контроль над ресурсами приложению
Как и во флатпак. А еще во флатпаке есть разделяемые рантаймы
Но как видим, это все не спасает, и в снапе найдут дыры когда-нибудь
Охотник на оленей поймал оленя за рога
Разумеется, ведь snap и flatpak сестринские проекты, flatpak моложе, у флетпака свои фишки есть.
> Как и в FlatpakДадад snap и flatpak это две палочки Твикс, но как сказал человек где-то выше
> Когда нибудь найдут дыру и в snap
Ну вообще методологию эшелонированой защиты никто не отменял, и как правильно сказал человек выше, любая дырявось в flatpak превращает "изолированные" flatpak приложения в обычные "из папки opt" (как у 99% оленей сейчас, которым "ненужное не нужно")
Вот вангую что через года 2 каноникал выбросит свой снап. И перейдет на flatpak...
Неее, через пару лет всё это выкинут и напишут флетснапак.
системд-флетснаппакд
к тому времени все перейдут на фрю
>телеграмывеб-версия
>хромы
chromium из под su, смысл его песочить, самый секурный браузер )
>прочая снедь
еда? может просто совсем не устанавливать откровенное гомно?
"...каждая софтина живёт в своём snap-окружении (и она не может попортить/почитать конфиги соседних приложений одного юзера из его .config папки,..."
Смешно. На днях по приколу поставил snap chromium и он автоматом подтянул в себя все настройки и расширения из установленного Chromium.
Нет, только AppImage.
> несмотря на наличие в описании пакета метки "sandboxed"Шедевр, девляпсы!!!
смузихлебы
растофаны
Может быть, следующие рекомендациям отдела кадров - дерзай, дерзай... Но вот как правильно дерзать - этому, почему-то, уже не учат в кадрах. Т.к. это дело ВУЗ'а/Универа.
FlatHub пакеты не дают доступ к домашнему каталогу, нужно переопределение доступов.
у некоторых пакетов прописан доступ к домашнему каталогу по дефолту. Например, хромиум не умеет в порталы, так что электроноподелкам для работы нужен доступ к домашнему каталогу, или они становятся бесполезными.
Ты немного бред говоришь. Flatpak умеет подсовывать фейковый /home для програм, и поделия на електроне прекрасно работают без доступа вообще ко всему.
Плюс никто не мешает отредактировать права доступа по умолчанию, если разработчик пакета неможет в сандбокс. Там одну строку изменить.
> Ты немного бред говоришь. Flatpak умеет подсовывать фейковый /home для програм, и
> поделия на електроне прекрасно работают без доступа вообще ко всему.
> Плюс никто не мешает отредактировать права доступа по умолчанию, если разработчик пакета
> неможет в сандбокс. Там одну строку изменить.Как только попытаешься открыть файловый диалог без доступа к /home, увидишь, что файловый диалог ничего не видит
Ммм, файловый диалог видит вообще-то все, если он системный. И еще и может передать ОДИН файл в прогу. Обнови flatpak дружище.
А еще. если совсем все плохо да. можно сделать вот так
mkdir /home/user/fakehome_forapp
HOME=/home/user/fakehome_forapp flatpak run com.garbageapplication
> Ммм, файловый диалог видит вообще-то все, если он системный. И еще и
> может передать ОДИН файл в прогу. Обнови flatpak дружище."системный"... файловый диалог предоставялет тулкит, что ты имеешь в виду под системным? Есть, конечно, портальный, но его хромиум/электрон как раз и не умеют.
Ну и сам флатпак на это влиять не может, только версия рантайма, с которой приложение собрано и версия порталов в системе.
ПОдожди а что должен увидеть файловый диалог в /home/username если он фейковый и пуст... пропиши проге папку в настройках /home/username/appfolder и дай доступ из flatpaka.
Мануалы же читать надо. А не в GUI сидеть. Нет для флатпака нормального бекенда со всеми возможностями. Надо ставить и настраивать из консоли, или будут проблемы.
> ПОдожди а что должен увидеть файловый диалог в /home/username если он фейковый
> и пуст... пропиши проге папку в настройках /home/username/appfolder и дай доступ
> из flatpaka.
> Мануалы же читать надо. А не в GUI сидеть. Нет для флатпака
> нормального бекенда со всеми возможностями. Надо ставить и настраивать из консоли,
> или будут проблемы.Ох, ты сам же мануалы-то и не читал, тогда бы знал, что приложение должно юзать xdg-desktop-portal в флатпаке для диалогов.
https://github.com/electron/electron/pull/19159
> ПОдожди а что должен увидеть файловый диалог в /home/username если он фейковый
> и пуст... пропиши проге папку в настройках /home/username/appfolder и дай доступ
> из flatpaka.
> Мануалы же читать надо. А не в GUI сидеть. Нет для флатпака
> нормального бекенда со всеми возможностями. Надо ставить и настраивать из консоли,
> или будут проблемы.Портальный диалог может ходить по хостовой системе (часть системы же) и пробрасывать файлы в песочницу. Ничего руками делать не должно быть нужно.
Суидные бинарники, опять суидные бинарники. И почему меня никто не слушает?
Ах да, про порталы я уже тоже ныл. Порталы это тупик, как ни крути.
Это только в Debian'е, там user namespaces отключено. В Arch'е бинарники без SUID.
По со вершенно непонятному стечению обстоятельств практичеки все хипсторы страдают от недуга "напихай по больше про безопастнось и непофтормые фичи твоего смузи продукта даже не понимая смысла использованных терминов"
отягощенного транспозицией головного мозга и седалища.
Потому то хипстоподелки видимо и напоминают разваливающиеся китайские игрушки из 90х.
зачем ты пишешь чушь на опеннете?
Почему чушь? В результате транспозиции межушный ганглий перестаёт быть межушным.
Как хорошо, что все лучшие разработчики мира собрались в комментах на опеннете, так мне спокойней за любимый сайт.
Дык они ж на нем комментят а не кодят :)
Хороший программист умеет грамотно и понятно написать комментарий и пишет их много
Без ФэтФака как-то надёжней было.
На самом деле нет.
На самом деле, да. Не было иллюзии безопасности.
Ну кто бы мог подумать! Дырявые линуксконтейнеры опять показали себя во всей красе.Но опенвзлевое использовать не будем. Там патчи не шапкины.
И опять дырка в Дубасе.. но копрофаги будут дальше уплетать за обе щеки.
Очередная адовая дырка у смузихлёбов?
Как-то уже привычно и обыденно.
А в обычных deb/rpm пакетах вообще нету никакой изоляции, т.е. по уровню защиты deb/rpm соответствует дырявой версии flatpak. Вот только во flatpak ошибку исправили и теперь порядок, а deb/rpm как соответствовали дырявыми версиями flatpak, так и останутся такими навсегда
В каком пакете идёт сам flatpak?
> А в обычных deb/rpm пакетах вообще нету никакой изоляции, т.е. по уровню защиты deb/rpm соответствует дырявой версии flatpak.Ну это теория. На практике неочень.
Вот ставишь ты Flatpak пакет криптовалютного кошелька. А его естественно делает левый пионер, не связанный с основным проектом (это обычное явление во Flathub).
Он попионерит, и забьёт, а ты будешь с дырявой версий сидеть с возможностью пенетрации.
Ну или вообще захочет вредонос встроить — сложности не составит. Особых уж проверок нет.
В пакете из дистрибутива есть цепочка доверия к мэйнтейнеру и жёсткий контроль сообщества, а во Flathub пакеты публикует непойми кто и проверяют непойми как. Поэтому изоляция запуска содержимого во flatpak должна быть обязательной и полной, но её каждый второй автор пакета отключает. Как следствие, если на пакет не ссылается основной проект как заслуживающий доверия, риски при запуске flatpak мало чем отличаются от запуска первого попавшегося в интернете бинарника.
Возможность отключить изоляцию, создаёт проблемы с безопасностью, не спорю. Имхо, могли бы запилить какой-нибудь режим повышеной безопасности, не позволяющий устанавливать пакеты со слабой изоляцией...А насчёт доверия мейнтейнеру - можно, на доверии всё человеческое общество устроено, но я бы всё же предпочёл доверять алгоритму, а не людишкам (компьютеры ненадёжны, люди - ещё ненадёжнее -- из законов мерфи)
Через deb/rpm не едет неизвестно как и кем собранный блоб в комплекте с устаревшими дырявыми зависимостями.
> GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity и VLCВот он, набор ненужного!) Ну кроме Audacity может быть.
Опять какой то анонимный хрен в интернете лучше других знает, кому что нужно
Естественно! :)> кому что нужно
А мне это не интересно, чего там может быть нужно какой-то обезьянке.
Во флатпаке - точно не нужно.
VLC не тронь
GIMP не тронь
Octave не тронь
> GIMP, Inkscape, Audacity и VLCЭти апликухе есть и в виде AppImage
Base OS + pkg/ports = profitЗачем они городят какие-то костыли?
Вот хочу я на debian stable установить новый libreoffice. Или не хочу засырать систему стимом. Или хочу чтоб у меня работал последний месенджер, разрабы которого постоянного обновляют его.
Вот и нужно сделать, как в нормальных ОС: базовая система и программы отдельно. Windows, macOS, FreeBSD так и работают. Там всегда самый новейший софт при том, что сама система от него вообще никак не зависит.
Это в которых до 2021 года в \system32 кладутся левые общие либы при установке, а для реализации принципа разделяемых библиотек есть папочка \winsxs, где, подумать только, лежат хардилнки на все библиотеки, которые только есть в системе, и без работы с дисмом расплывшуюся до неприличных размеров после пары кумулятивок хрен сожмешь (удалая ненужные обновления, лишая себя возможности отката системы)?
До-до, нам в лянуксах такого шедевра костылестроения только не хватало.
А у вас негров линчуют.(c)
> Это в которых до 2021 года в \system32 кладутся левые общие либы
> при установке, а для реализации принципа разделяемых библиотек есть папочка \winsxs,Это в которых можно вот так:
# mount -o exec /tmp
$ pkg fetch gcc48
# pkg --rootdir /tmp/test add --accept-missing -f /var/cache/pkg/gcc48-4.8.5_13.txz
Installing gcc48-4.8.5_13...
pkg: Missing dependency 'binutils'
pkg: Missing dependency 'gmp'
pkg: Missing dependency 'indexinfo'
pkg: Missing dependency 'mpc'
pkg: Missing dependency 'mpfr'
Extracting gcc48-4.8.5_13: 100%
...
Unsupported by upstream since 2015. Use GCC 10 or newer instead
$ /tmp/test/usr/local/bin/gcc48 -v
Using built-in specs.
COLLECT_GCC=/tmp/test/usr/local/bin/gcc48
COLLECT_LTO_WRAPPER=/tmp/test/usr/local/bin/../libexec/gcc48/gcc/x86_64-portbld-freebsd12.1/4.8.5/lto-wrapper
Target: x86_64-portbld-freebsd12.1
Configured with: /wrkdirs/usr/ports/lang/
...
/info/gcc48 --build=x86_64-portbld-freebsd12.1
Thread model: posix
gcc version 4.8.5 (FreeBSD Ports Collection)
но да, можно вместо этого попетросянить о венде и заявить "нищитаица!!1"
> На дебиан-стейблНаркоман.
Зачем пихать в сервер-ориентед ор критикал-воркстайшн (с заранее известной смесью рабочих приложений) но-гуй-бест-вей сборку дебиана, ради которой и затевается вся это мура с фильтрацией sid-unstable-testing, патчами и заморозками мокрокисечный софт. Ну или околопрориентарь, вроде стимов/мессенджеров?
Нет, просто ход мыслей непонятен.
Ну ок, какой дистр мне поставить, в котором я могу заиметь несколько версий нужной мне проги одновременно, ну или просто взять ту, которая нужна, не важно, новая она или старая?
Специально под такие потребности есть хипстерские зборачки, вроде никос.
Зачем тянуть в специально стабилизированную систему проприентарь?
> хипстерские зборачки, вроде никосКоторый ничем не лучше флатпака
> Зачем тянуть в специально стабилизированную систему проприентарь?
Потому что хочу. Ну надо.
> Вот хочу я ... новый ...Но не получится, ибо новый требует либо libc, которой у тебя нет в системе, либо libc вшита в пакет, но требует новое ядро. И нифига в этом фэтфаке у тебя не работает.
Пользователь debian stable не хочет устанавливать НОВОЕ каждые 5 секунд. Он для того такой дистр и выбрал.
я не хочу чтобы что-то ВНЕЗАПНО отваливалось, поэтому и выбирал такой дистр (точнее одна из причин). А вот новое оно или нет, мне как-то без разницы в большинстве случаев.
Попробуйте Guix!
Он решит все ваши проблемы.
Не надо в нормальных системах этого костыля. Когда один и тот же софт нужно обновлять размыми несовместимыми способами, системный openssl конфликтует с портовым, и в системе всегда есть сендмейл и прочее никому ненужное говно которое простым способом не удалить. FreeBSD переедет целиком на пакеты рано или поздно.
Балин, это получается шобы безопасно пользоваться контейнерами Linux нада сам Linux в контейнере виртуалки запускать, а лучше ещо пару вложеных контейнера в контейнере?
Контейнер на линуксе в гипервизоре контейнеризованного линукса, внутри линуксовой виртуалки на линуксовом гипервизоре.
Базарю, хакеры сами тебе денег отсыпят, лишь бы перестал так упарываться
А если бы написать на Раст...
равносильно x10 росту дыр + утечка памяти.
> атакующему для выполнения своего кода достаточно изменить файл ~/.bashrcТок баш? Или zsh или рыбку по аналогии?
Хоть что.
Можно и скриптов в пользовательский авторан засунуть.
А может просто не нужно всякую не внушающую доверия ерунду себе устанавливать? В Android вот есть изоляция приложений и разграничение прав, и что, мало малвари на Гуглплее? Только видимость безопасности и больше защита интересов издателей, а не пользователей.Может лучше не изолировать, а интегрировать? Ущербна сама концепция "приложений". ОС должна быть расширяемой, дополняться новыми функциями, которые можно произвольно сочетать для решения своих задач. А сейчас мы имеем коллекцию виртуальных устройств: вот вам программа-калькулятор, а вот печатная машинка, и что-то для рисования: можно использовать одно или другое — они как отдельные предметы, которые лежали на физическом рабочем столе, только переключаться между ними стало немного легче. Юникс и ГНУ/Линукс были именно расширяемыми системами, но для графического интерфейса взяли коммерчески-ориентированный десктоп с приложениями, унаследованный от Мака и Виндовс, вместо того, чтобы ориентироваться на изначальные (еще не извращенные) идеи графического интерфейса PARC.
> В Android вот есть изоляция приложений и разграничение правА толку от этого, если любая уважающая себя ведрограмма запрашивает доступ на всё на свете, иначе отказывается работать.
Открываешь для себя fdroid
@
Оказывается, что софт может работать с минимумом разрешений
Наивный чукотский мальчик, оказывается, что софт может НЕ работать с минимумом разрешений.
А так что вы хотите от проекта, где инструкцию на сайте поменять в два предложения - это целое дело, требующее серьёзного разбирательства: "а как же это? а кто этим занимается? как это сделать?".
Эта ссылка должна была быть в первом же комментарии про flatpak: http://flatkill.org/2020/NixOS и GNU Guix System - наше всё.
Guix был бы хорош, если они сделали как в NixOS, где можно указать опцию и у тебя есть non-free, а так приходится собирать самому ядро с доступом к firmware, без которых AMD карты - тыквы.
Вы можете гуикс на любой линукс установит.
Ос же на основе гуикса называется GuixSD.
Но я согласен что нужна нонфри версия. Ну или возможность это легко включить.
Системы все так же отжирают собой все доступное место, спасая диск от юзерских файлов?
Что то, что это — сплошная пионерия на палках и этом самом.