Архив метки: Kernel

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы. Каждый раз, когда появляется новость про российский Linux-дистрибутив в комментарии приходят хейтеры с криками "Bolgenos!". Типа это ненастоящий дистрибутив. Вот есть какие-то настоящие, а этот нет. Имею сказать следующее:

1. Даже тот самый мемный BolgenOS Дениса Попова по прошествии лет выглядит как вещь, которая вполне имела право на существование в качестве учебного проекта несколько странноватого, но вполне безобидного 16летнего парня. 🤷‍♂️ Ну сделал он сборку Ubuntu с нескучными обоями и переименованными приложениями (где-то вроде даже копирайты затер 😱). Ну сняли про него дурацкий репортаж на региональном ТВ. Это был повод для травли, вот серьёзно?

2. Если какие-то люди собрали очередной Linux-дистрибутив, допустим, на основе Debian, используют его сами и собираются его кому-то продавать, то они в своём праве. Даже если они (о ужас!) не собирают сами пакеты, а продают ванильный Debian с налепленным своим логотипом. Вот даже тогда. Насколько мне известно, ничто сейчас не запрещает это делать. Ни российское законодательство, ни требования регуляторов, ни даже опенсурсные лицензии.

3. Если с этим Linux-дистрибутивом можно комфортно и относительно безопасно (в смысле оперативного исправления уязвимостей, отсутствия явных закладок, обновления с российских серверов) работать, то в общем-то и норм. Если вдруг почему-то нельзя, то это хорошая тема для предметного обсуждения. Ну ещё неплохо бы бюллетени безопасности в формате OVAL, чтобы уязвимости было удобно детектировать. 😇

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

5. Я не верю в какие-то прям "хорошие Linux-дистрибутивы". Это ВСЕГДА переупакованный ЧУЖОЙ код от апстримов. В этом отношении прилетела ли ко мне программная закладка непосредственно от разработчика (например, XZ Utils или самого Торвальдса) или от Debian-ов мне, как потребителю, как-то пофигу. В возможности всерьёз контролировать апстрим я не верю. Если вы так здорово закладки можете выявлять, почему вы тогда Linux-овые уязвимости не выявляете? Сотни Linux-овых уязвимостей исправляются каждый месяц, что же вы их не выявляете сами раньше разработчиков? 😏 Использование Linux и опенсурсного софта это всегда некоторый компромисс функциональных возможностей и безопасности. Лучше бы, конечно, своё ядро. Лучше бы, конечно, чтобы и системные компоненты свои. И прикладной софт свой. А раз этого всего нет и не ожидается, то и чего щёки надувать, что вы принципиально лучше тех самых "болгеносов"? 😏

Новый выпуск "В тренде VM": 4 горячие уязвимости октября, скандал в The Linux Foundation, социальная "атака на жалобщика", "метод Форда" для мотивации IT-специалистов

Новый выпуск "В тренде VM": 4 горячие уязвимости октября, скандал в The Linux Foundation, социальная "атака на жалобщика", "метод Форда" для мотивации IT-специалистов. Конкурс на лучший вопрос по теме VM-а продолжается. 😉🎁

📹 Ролик на VK Видео, RUTUBE, YouTube
🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Содержание:

🔻 00:43 Уязвимость повышения привилегий в Microsoft Streaming Service (CVE-2024-30090)
🔻 01:53 Уязвимость повышения привилегий в Windows Kernel-Mode Driver (CVE-2024-35250)
🔻 02:43 Уязвимость спуфинга в Windows MSHTML Platform (CVE-2024-43573)
🔻 03:48 Уязвимость удаленного выполнения кода в XWiki Platform (CVE-2024-31982)
🔻 04:50 Скандал с удалением мейнтейнеров в The Linux Foundation, его влияние на безопасность и возможные последствия
🔻 05:28 Социальная "Атака на жалобщика"
🔻 06:41 "Метод Форда" для мотивации IT-специалистов к исправлению уязвимостей: будет ли он работать?
🔻 08:10 Про дайджест, хабр и конкурс вопросов 🎁
🔻 08:34 Бэкстейдж

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть?

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть?

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть? И, соответственно, их проекты стараться обходить стороной.

Как вчера выяснилось, главный по разработке ядра, используемого чуть менее чем во всех отечественных ОС, позиционирует себя расовым гекльберрифинном, борцом с "агрессией" и, видимо, большим знатоком зимней войны. И вот чего теперь? На такого буйного опенсурсера реакция вендоров отечественных ОС-ей и ИБ регуляторов будет? 🤔

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux. Поглядел оригинальный тред, темы с обсуждением на Хабре и на OpenNet.

Так-то ничего нового, уже после скандала с Baikal Electronics было понятно, что нормально контрибьютить в ядро Linux российским организациям (да и просто специалистам с российским бэкграундом) не дадут.

Могу только повторить:

"Предсказуемо. Опенсурс-опенсурсом, а Linux Foundation это конкретная американская организация. Как и банящий разработчиков GitHub это Microsoft. Понятно каким регуляциям они подчиняются.

Поэтому ядро Linux должно быть своё. Например, от ИСП РАН. И репозитории должны быть свои. И дистрибутивы Linux. Это породит дополнительную фрагментацию и несовместимость, но это выглядит как неизбежные издержки."

И от термина "Linux" тоже неплохо бы уйти в перспективе. 🤷‍♂️

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

Прожектор по ИБ, выпуск №4 (24.09.2023)

Прожектор по ИБ, выпуск №4 (24.09.2023). Записали вчера очередной эпизод, состав тот же:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

0:35 Как зашёл прошлый эпизод
2:08 Лев и Максим делятся впечатлениями от Kazan Digital Week
7:06 На какие мероприятия по ИБ мы ходим
11:06 Приостановка сертификата ФСТЭК на Dr.Web Enterprise Security Suite
19:04 Cisco покупает Splunk
25:59 Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом".
30:02 Новые подробности инцидента с FDM и скрипт для детекта
32:21 Занятные моменты детектирования Linux уязвимостей на примере CVE-2022-1012, RPM-based дистрибутивы и импортозамещение
44:02 Прощание от Mr. X

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux. Есть уязвимость ядра Linux CVE-2022-1012. Вопрос: вы можете продетектировать эту уязвимость в CentOS/RedHat 7?

Уловка в том, что VM-вендоры, как правило, детектируют уязвимости на основе бюллетеней безопасности Linux-вендоров. Т.е. они могут продетектировать только те уязвимости, для которых уже есть фиксы и понимание какие версии пакетов уязвимы. А для этой уязвимости RedHat пишут, что да, она аффектит дистриб, но они не будут исправлять её в CentOS/RedHat 7. Можно было бы предположить, что 7ая версия, наверное, уже EOL. Но нет, для 7ой версии EOL наступит только в июле 2024 года.

Имеем уязвимость, которая

1. Присутствует в ещё поддерживаемой версии ОС.
2. Не может быть исправлена установкой обновления от Linux-вендора.
3. Не может быть продетектирована, если только VM-вендор специально не озаботился детектом "Will not fix" уязвимостей.

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций. Baikal Electronics проектирует процессоры и системы на кристалле с архитектурой MIPS и ARM. Компания находится под санкциями США, ЕС и ряда других стран.

"Нам некомфортно принимать патчи от вашей организации или относящиеся к hardware произведенному вашей организацией.

Пожалуйста, приостановите networking contributions до дальнейшего уведомления."

В предложенных патчах для сетевого драйвера stmmac была реализована поддержка GMAC и X-GMAC SoC Baikal, предложены общие исправления для упрощения кода драйвера.

Предсказуемо. Опенсурс-опенсурсом, а Linux Foundation это конкретная американская организация. Как и банящий разработчиков GitHub это Microsoft. Понятно каким регуляциям они подчиняются.

Поэтому ядро Linux должно быть своё. Например, от ИСП РАН. И репозитории должны быть свои. И дистрибутивы Linux. Это породит дополнительную фрагментацию и несовместимость, но это выглядит как неизбежные издержки.