Записки IT специалиста

​​Про бумажки

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

Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?

Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик ила работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват.

Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку.

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

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

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

А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.

Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору…

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

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

Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас.

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

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

Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны.

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

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

Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях.

Поэтому – просто не работайте с чудаками на букву «м».

​​За героизм нам не платят

Сегодня, на фоне обсуждений в комментариях, хочется поговорить о производственном «героизме». А именно, когда мы начинаем выполнять задачу не в обычном рабочем режиме, а в состоянии аврала или близком к нему.

Данный героизм можно разделить на два типа: добровольный и вынужденный. Начнем с последнего. Вынужденный героизм – это всегда результат просчета, вашего или не только вашего.

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

В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.

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

Что такое авральная ситуация? Это когда все бегают по потолку и ищут там пятый угол, а заодно мучительно думают кого бы назначить крайним.

Сложная, но контролируемая ситуация выглядит так: у нас утрачена рабочая копия сервера и локальное хранилище копий. Чтобы запустить основные функции надо получить 40 ГБ бекапов из внешнего хранилища, это займет примерно час. За это время переустановим сервер, потом еще час-полтора на запуск. Туда-сюда, через три -четыре часа взлетим.

В чем разница? В том, что в первом случае это чистый «героизм», мы превозмогаем, самозабвенно бьемся с обстоятельствами, пытаемся пропетлять между струями дождя и т.д. и т.п.

Во-втором – планомерная и слаженная работа в сложной ситуации, когда мы понимаем, что со всеми допущениями и закладками на прочие «сюрпризы» за три – четыре часа мы систему гарантированно поднимем.

А теперь подумаем, что могло стать причиной перерастания сложной ситуации в авральную? Не было внешнего хранилища? Было, но процесс копирования в него никто не контролировал? Контролировал, но не проверял сами копии?

Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.

Второй вид героизма – добровольный. Тут все проще и не так трагично. Просто мы вызываемся поработать во внерабочее время, в плотном графике, без необходимых ресурсов и т.д. и т.п.

Обычно это начинается так: нам нужно…

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

Начинается все это безобидно: давайте задержимся после работы, выйдем в ночь, пока сделаем так, а там докупим…

Заканчивается по-разному. Самый безобидный сценарий, это когда вам первый раз пожали руку, сказали спасибо и выдали премию, второй раз просто пожали руку, третий раз забыли про спасибо, а потом еще и посетовали, что что-то вы как-то плохо работали.

В результате подобный «героизм» входит в рутину и от вас его уже ожидают по умолчанию. Ну если нравится человеку работать по ночам без дополнительной оплаты…

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

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

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

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

А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.

В общем – не надо так делать. Как говорил один мой первый руководитель, когда я проявлял ненужную инициативу – за героизм нам не платят.

​​Зависимости DEB-пакетов

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

Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является dpkg, именно он занимается распаковкой и установкой пакетов. Упрощенно говоря, установка пакета состоит из двух этапов: распаковки и настройки.

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

Если в процессе настройки dpkg обнаруживает неудовлетворенные зависимости, то он прекращает настройку и пакет остается распакованным, но не настроенным, мы можем попытаться удовлетворить зависимости и заново попытаться настроить пакет.

Но так как разрешение зависимостей дело непростое, то были придуманы высокоуровневые инструменты, такие как apt-get и apt, задача которых – построить дерево зависимостей, скачать их все и передать для установки тому же dpkg.

Посмотреть зависимости можно командой:

apt-cache depends package_name

И чтобы правильно понимать ее вывод давайте разберем какие именно типы зависимостей существуют:

▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.

▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.

▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.

▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.

▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.

▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.

▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.

▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.

Как мы уже говорили выше, высокоуровневые менеджеры автоматически разрешают зависимости с типом: предзависит, зависит, конфликтует, заменяет, ломает и предоставляет.

Зависимости типов рекомендует и предлагает предназначены для пользователя. При этом нужно помнить, что не всегда такие зависимости могут быть перечислены в пакете и их наличие следует искать в документации. Хороший пример – пакет шрифтов MS для 1С:Предприятие, их нет в зависимостях пакетов и продукт прекрасно работает без них, но страдает внешний вид текста.

Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.

Так вот, так делать можно, но не нужно. Потому что в этом случае пакеты будут считаться установленными интерактивно и не будут удаляться командой autoremove после удаления основного пакета.

С 1 марта родители могут бесплатно записать своих детей 8–17 лет на программу льготного обучения программированию. 

Цель программы — познакомить школьников с IT-профессиями, обучить разработке на Python, созданию 3D-игры и мультфильмов. Участники получат именные сертификаты, которые помогут при поступлении в вуз и в будущей карьере.

Онлайн-курс проводит федеральная школа программирования Алгоритмика, лауреат премии «Бренд года в России 2024» и участник проекта Сколково. Занятия ведут преподаватели с опытом работы в IT-компаниях, включая Яндекс, Сбер и Иннополис.

Запись открыта до конца недели. Для участия нужно выбрать направление по возрасту ребенка и оставить заявку на сайте: https://s.algoritmika.org/1kbt5q5?erid=2W5zFFwHqWG

​​Завершающий слеш в путях Linux

Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.

В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.

Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:

~/video

Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:

~/video/

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

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

Например, в нашем скрипте написано в цикле что-то вроде:

mv -f “$file” /new_path/video

Данная конструкция имеет неопределенность, потому что если мы забудем создать папку video, то все файлы будут перемещены в новый файл video и последовательно его перезапишут. Т.е. мы останемся без видео, у нас сохранится только последний файл.

Если же мы напишем:

mv -f “$file” /new_path/video/

То при отсутствии директории получим ошибку:

mv: невозможно создать обычный файл ' video/': Это не каталог

Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл video, скажем как результат предыдущего ошибочного запуска скрипта, то ошибка будет иной:

mv: не удалось получить доступ к ' video /': Это не каталог

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

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

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

В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?

Поэтому в скриптах такие вещи всегда лучше проверять явно, например:

if ! [ -d /new_path/video/ ]; then
   mkdir /new_path/video
fi

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

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

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

​​И на старуху бывает проруха

Трой Хант (Troy Hunt), известный деятель в области компьютерной безопасности, автор курсов по защите информации, создатель сервиса проверки скомпрометированных паролей "Have I Been Pwned?" и региональный директор Microsoft, раскрыл сведения об утечке базы пользователей собственного списка рассылки. История показательна тем, что даже признанные специалисты в области компьютерной безопасности могут стать жертвами типового фишинга при определённом стечении обстоятельств.

Трою пришло письмо от имени сервиса Mailchimp c предупреждением о приостановке работы его списка рассылки и необходимости выполнения определённых проверок. Трой перешёл по ссылке в письме, ввёл на открывшейся странице параметры учётной записи в Mailchimp, подтвердил запрос двухфакторной аутентификации и страница зависла...., а атакующие получили доступ к пользовательской базе его списка рассылки и выгрузили сведения о email и IP-адресах 16627 подписчиков. Примечательно, что в выгрузку вошли 7535 адресов пользователей, ранее отписавшихся от рассылки, но сервис Mailchimp сохранил их несмотря на отписку и включил в экспортируемые данные.

Трой не стал умалчивать свою оплошность и подробно разобрал инцидент в своём блоге, а также добавил информацию об утечке на свой сервис haveibeenpwned.com. Трой считает, что он не заподозрил подвоха из-за стечения нескольких факторов. Во время получения письма Трой был в поездке, не адаптировался после смены часовых поясов и был сильно уставшим. Письмо было прочитано именно в тот момент, когда бдительность была подавлена.

Вторым фактором стало то, что письмо вначале было просмотрено на iPhone с почтовым клиентом Outlook, который показал только имя отправителя и не отобразил email. Затем, когда письмо было повторно открыто утром на компьютере, Трой не стал перепроверять параметры и не обратил внимание на то, что письмо отправлено с подозрительного адреса "[email protected]".

Текст был стилизован под стандартное сообщение Mailchimp и предупреждал об ограничении отправки рассылки из-за получения жалобы на спам. Информация была подана ровно в той мере, чтобы вызвать беспокойство, но не переусердствовать. В письме предлагалось проверить недавно отправленные рассылки и предпринять действия для разблокировки. По ссылке вместо mailchimp.com открылся сайт mailchimp-sso.com. Менеджер паролей 1Password автоматически не заполнил форму входа, но и это было проигнорировано. После зависания формы аутентификации Трой очнулся и перезашёл на реальный сайт Mailchimp, но было уже поздно - атакующие использовали захваченные учётные данные для получения токена для доступа к API и выполнили экспорт информации.

✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=62964

🖥 Дорогие айтишники и им сочувствующие!

ИТ-индустрия переживает период беспрецедентных изменений. Погрузиться в эту тему и разобраться во всех нюансах гос. регулирования поможет этот профессиональный канал.

🎯 Наш подход:

✓ Только полезная информация с щепоткой юмора и капелькой цинизма
✓ Фокус на реальных кейсах и практических решениях
✓ Профессиональный анализ изменений в отрасли
✓ Конкретные рекомендации для бизнеса (CxO)

📊 Что внутри:

• Анализ изменений / трендов и прогнозы через призму реальности
• Практические рекомендации по адаптации к новым условиям
• Разбор полётов ИЦК, ОЦК, ЦК КПСС (да-да, мы знаем, что это такое, и готовы объяснить вам)
• Серьёзные (мемы) темы про ПДН, ЗОКИИ, ГИС-ы (хотя очень хочется просто запостить мемы)
• Пофессиональное сообщество IT-специалистов (ИТ-реалистов), заинтересованных в развитии отрасли.

👉 Присоединяйтесь по ссылке, пока не приняли закон о запрете присоединения по ссылкам ;)

​​О радиомостах

В свете материала о нормативном регулировании Wi-Fi неизбежно всплывает вопрос о радиомостах.

Бытуют распространенные заблуждения, что радиомосты можно поднимать над своей территорией, только в диапазоне 2,4 ГГц или только в диапазоне 5 ГГц и много всего такого прочего.

Но увы, радиомосты без регистрации незаконны в любом виде. Абсолютно в любом.

Чтобы понять откуда ноги растут вернемся к Постановлению Правительства РФ от 20.10.2021 N 1800 "О порядке регистрации радиоэлектронных средств и высокочастотных устройств", а именно пункту 14 приложения Изъятия из перечня радиоэлектронных средств и высокочастотных устройств, подлежащих регистрации.

Этот пункт прямо гласит, что регистрации не требует:

Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосе радиочастот 2400 - 2483,5 МГц, с допустимой мощностью излучения передатчика не более 100 мВт, в том числе встроенное либо входящее в состав других устройств.

Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосах радиочастот 5150 - 5350 МГц и 5650 - 6425 МГц, с допустимой мощностью излучения передатчика не более 200 мВт, в том числе встроенное либо входящее в состав других устройств.

Начнем с формулировки Пользовательское (оконечное) оборудование, для этого заглянем в Федеральный закон от 07.07.2003 N 126-ФЗ "О связи", статья 2, п. 10:

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

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

Кроме того, п. 14 содержит дополнительную оговорку о малом радиусе действия и ограничивает мощность излучения передатчика.

Таким образом никаких иных оговорок в законе, которые бы предоставляли лазейки нет.

Любой радиомост, который светит за пределы вашего помещения вне закона и требует регистрации.

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

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

В таком случае вас привлекут к ответственности по Статье 13.4. КоАП Нарушение требований к использованию радиочастотного спектра, правил радиообмена или использования радиочастот, несоблюдение норм или параметров радиоизлучения

А именно пункта 2:

Использование без регистрации радиоэлектронного средства и (или) высокочастотного устройства, подлежащих регистрации, -

влечет наложение административного штрафа *на граждан* в размере *от пятисот до одной тысячи рублей* с конфискацией радиоэлектронных средств … или без таковой;
*
на должностных лиц - от одной тысячи до двух тысяч пятисот рублей*;

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

*на юридических лиц - от десяти тысяч до двадцати тысяч рублей* с конфискацией радиоэлектронных средств … или без таковой.

Отягчающими обстоятельствами считаются:

1) совершение длящегося административного правонарушения, продолжительность которого превышает три месяца;

2) создание в результате совершения административного правонарушения радиопомех радиоэлектронным средствам других пользователей радиочастотным спектром.

А дальше каждый решает сам. С одной стороны штрафы не такие большие, но с другой практически всегда это сопровождается конфискацией оборудования и постановкой нарушителя на карандаш.

​​И снова вой на болотах

Начнем с новости:

Начиная с 11 марта встроенный в ОС Windows антивирусный пакет Windows Defender начал блокировать (помещать в карантин) свободный драйвер WinRing0. Драйвер используется для получения доступа из пространства пользователя к различному оборудованию, для которого не предусмотрено другого API в системе.

Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft.

Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979).

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

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

В целом имя данного драйвера наглядно об этом говорит - Ring0 – нулевое кольцо защиты – режим, в котором работает ядро ОС.

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

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

Т.е. уже, даже в легальном сценарии использования мы имеем все шансы ушатать систему из-за ошибки в каком-нибудь стороннем приложении для управления вентиляторами или подсветкой.

Но это еще не все, конструктивной ошибкой данного драйвера было то, что получить к нему доступ могла любая программа в системе, в т.ч. и с низким уровнем целостности (low integrity) т.е. недоверенное приложение. А это уже не просто дыра, это проходной двор.

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

Поэтому решение о блокировке такого драйвера – это не ошибка и не произвол, а вполне взвешенное и обоснованное решение. Наоборот, странно что не случилось этого раньше.

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

Знаю, что многие тут хотят уйти в DevOps. Но не знают где взять информацию и четкий план.

💪 Советую бесплатный мета-курс Devops Roadmap - это расширенный чек-лист, который поможет сориентироваться в мире DevOps и стать крутым спецом.

В мета-курсе перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования в удобном формате.

✔️А еще он будет полезен при подготовке к собеседованиям.

👉 Кстати, бонусом крутой канал о девопс. Там тоже самые свежие IT-новости, полезные советы от DevOps-инженера с 20-летним стажем, эксклюзивные материалы, релизы топовых инструментов, обзоры вакансий и личный взгляд на девопс-сферу.

📌 Ну а тем, кто хочет двигаться под руководством наставника - индивидуальная программа.