The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Тестирование разделения базовой системы FreeBSD на пакеты"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Тестирование разделения базовой системы FreeBSD на пакеты" +/
Сообщение от Дон Ягон (?), 30-Апр-19, 17:30 
> Почему "по-разному собранных частей"? Смысл в том, что тогда есть оф. и одним куском, так как задуманно разработчиками, собранная база. Но благодаря опакечиванию можно не устанавливать пакет с компилятором или пакеты с дебагсимволами.

Для этого нужно не просто побить базу на пакеты. Ещё нужно тестировать работоспособность системы в "кастрированных" конфигурациях и правильно прописать зависимости. Чтобы при удалении чего-то не нужного на твой взгляд у тебя не переставало работать что-то, от этого зависящее. И наоборот: чтобы при установке чего-то нужного доезжало всё необходимое.
А это не так просто, как может показаться. В линуксе это работает из-за другой модели разработки.

> Нет, речь конкретно вот об этом:
> https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAG.../
> FreeBSD-12.0-RELEASE-arm-armv7-RPI2.img.xz  307371508
> Т.е. пожатый исошник весит 307 MB и распаковывается в 2 или 4 GB.

Ну и причём тут ISO-то? Когда ты jail сетапишь, например, он тебе не нужен, скачиваешь базу по ссылке и распаковываешь, куда надо.

> А приведенная в качестве примера кастомная сборка, с компилятором в базе - после установки всего 315МБ.
> Ну и лукавите вы немного с размером в вашем примере:
>> 147 метров, какие 2Gb? На диске побольше будет, да, метров 200-300.
> xz -l base.txz
> Strms  Blocks   Compressed Uncompressed  Ratio  Check  
>  Filename
>     1      33  
>   147,2 MiB    772,5 MiB  0,191
>  CRC64   base.txz
> А на диске под все 800 будут.

Ок, гигабайт на диске. И 147 метров в архиве - столько мы тащим по сети. Это не копейки?

>>> Либо оно не используется, но им может воспользоваться нападающий. Тоже классика жанра.
>> Нападающий воспользуется дырой в не запущенном демоне? Не рассажешь, как например?
> Принципиальные примеры:
> https://gist.github.com/hugsy/5933831 - даже если вы не пользуетесь ping, SUID у него никто не отбирал. Т.е. получаем классическое "privilege escalation" из nobody в рута.

Для этого у nobody должен быть shell на машину. Если он есть, ping автоматически переходит в категорию "используется" и, следовательно, должен обновляться.
Или предполагается, что ты на этапе сборки базы из пакетов-кубиков сможешь предугадать все дыры в ПО в каждом из пакетов и удалить именно их, оставив только неуязвимое?

> Или как сдесь: https://www.opennet.ru/opennews/art.shtml?num=47792
>>  выявлена серия уязвимостей, которые могут быть использованы локальным атакующим для запуска кода с правами ядра через загрузку специально оформленного eBPF-приложения.

Аналогично - нужен локальный shell и права на eBPF для непривилегированных пользователей.

> Про уязвимости в старых драйверах думаю можно не упоминать, а их в GENERIC тоже много загружается.

То, что не используется - не загружается. Но можно загрузить, да. Работать, правда, от этого такой драйвер не начнёт.
В OpenBSD, например, вообще нет загружаемых модулей ядра (хотя кастомизировать его можно, без пересборки - man config), т.е. в дефолтной конфигурации ядро включает в себя если не всё, то очень многое. При этом, одна из целей OpenBSD - "security by default".

> Не противоречит, но акценты расставлены по разному. Грубо говоря, убирание той же zfs-обвязки при неиспользовании zfs и сборка с "-O3" или новейшим компилятором - на мой взгляд две большие разницы.
> И если для второго я в принципе согласен с разработчиками "сначала попробуйте собрать нормально", то вот для первого пересборка всего и вся все же перебор.

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

> Не-не-не. Зачем кирпичики из N баз?
> Речь о кирпичиках в виде готовых пакетов из той самой, одной официальной фряшной базы, собранные так, как представлялось правильным разработчикам.

1) Что мне помешает решить, что я умнее всех и заменить N пакетов на "более свежие" из другой сборки? Или поставить пакеты без вредной на мой взгляд функциональности?
(со всеми вытекающими последствиями)
2) Что мешает мне прописать нужные WITHOUT_* в src.conf и сделать make BATCH_DELETE_OLD_FILES=true delete-old delete-old-libs? Выкину из базы лишнее вообще без пересборки.
3) Я собрал свою версию, скажем, openssl и решил вкорячить её вместо базовой. Как отговорить меня от выстрела в ногу?
На самом деле, так можно очень долго продолжать, но не очень хочется.

> Просто не таскать всегда и повсюду все "кирпичики" (см. дебагсимволы) а только нужную часть.

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

> Что любители экзотики пусть собирают и поддерживают свои хотелки сами, я даже не спорю. Но вот объявлять любой "шаг влево-вправо" (например отсутствие в базе vi или mlxtools или дебагсимволов) экзотикой, как это по факту делается сейчас - это по-моему тоже крайность.

Ну WITHOUT_VI (или как там) - это, ИМХО, плохой повод заворачивать багрепорты, да. Только это вопрос всё равно не про способы пакетирования. Ну будут тебе говорить "доустановите freebsd-base-vi чтобы мы рассмотрели ваш багрепорт" - какая разница?

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Тестирование разделения базовой системы FreeBSD на пакеты, opennews, 29-Апр-19, 23:34  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру