Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит. Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении. Всё, что докер даёт сверх этого - это "дополнительная фича", а не "урезанный вариант того что доступно для виртуалок".
Как вариант, ставите на сервак netdata (можно тоже в докере), и получаете обзервабилити выше крыши, включая и для контейнеров докера.
И как это может навредить безопасности? Докер же крутится в той же виртуалке, безопасность которой Вас устраивает. Значит за ядром в виртуалке Вы уже следите. А в остальном разницы никакой нет, просто базовые образы тоже надо обновлять - ровно так же, как и виртуалки.
для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
Что значит "нужно"? Кому нужно и для чего? Обычно эти штуки берут как раз для усиления безопасности (чем меньше в образе лишних приложений тем меньше возможных векторов для атаки). Но если ваш ИБ считает что у "контейнерных штук" безопасность хуже, то он может вместо них брать и ubuntu:latest. Размер образа будет больше, но в остальном особой разницы нет.
Ну, статически собранные бинарники тоже можно деплоить не докерами. Докер вообще придумали не для "статики". Но в большинстве проектов есть не только статика. Впрочем, если у Вас весь проект состоит исключительно из статики фронта, то докер действительно может быть ненужен.
И почему это проблема ИБ, а не бизнеса? Если бизнесу ИБ не нужен - пусть накрутят дичь. Если бизнесу ИБ нужен, и дичь неприемлема - почему бизнес не выделяет ИБ необходимые для "сделать нормально" ресурсы? Тут где-то что-то явно не стыкуется:
или начальник ИБ не в состоянии донести до бизнеса то, что необходимо выделить ресурсы под эти задачи,
или бизнесу это на самом деле не нужно а ИБ просто удовлетворяет собственный синдром вахтёра,
или от ИБ бизнес требует создать видимость работы дёшево, но тогда не надо доказывать адекватность этой видимости работы с технической точки зрения на хабре,
или бизнес просто не осознаёт реальную цену излишних запретов ИБ.
"Решать" проблемы тупо запрещая что можно и что нельзя - этот приём активно используется в политике. Может в политике он и работает, не могу судить. Но в бизнесе этот подход совершенно точно вредит бизнесу.
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи )
Может ни одной задачи отдела ИБ это и не решает, а вот задачи разработчиков - очень даже решает. Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
Так что если ИБ не делает свою работу полноценно "потому что за это не заплатили" но при этом навязывает запреты "на всякий случай", то нужно понимать, что бизнесу эти запреты обходятся значительно дороже, чем оплата времени ИБ на придумывание и внедрение этого запрета. Безопасность и удобство обычно находятся по разные стороны, а неудобство - это лишние затраты времени, а время - деньги.
Поэтому лично я против театра безопасности. Когда что-то делается для усиления ИБ - это должно быть оправдано реальными нуждами/рисками/ситуацией текущего бизнеса и делаться это должно с пониманием - пониманием как технических аспектов так и цены для бизнеса (в которую входит и неудобство разработчиков в том числе).
В докере чуть больше рисков, чем в виртуализации. Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов. Это вопрос баланса. И в докере есть достаточно много способов ограничить контейнеры, чтобы в большинстве случаев более высокими рисками по сравнению с виртуализацией можно было спокойно пренебречь. Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
Вы всё говорите правильно, и я с этим не спорю. В компаниях где реально внедрены любые стандарты ИБ есть адекватный аудит, и там отключать PermitRootLogin действительно есть смысл. Но помимо таких компаний есть те, которые до этого уровня зрелости ещё не доросли - их намного больше, и в них зачастую процветают карго-культы и театры безопасности вместо реальной ИБ.
вы самостоятельно расследовали инциденты по логам? я вот да
Я тоже да. Поэтому и говорю, что надеяться на это нельзя - пока процессы аудита не были поставлены и протестированы всегда есть высокая вероятность, что в логах будет что-то бесполезное вроде локального IP или вообще не будет нужного или сами логи будут удалены. Иными словами, я не против отключения PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации. Хотя бы на минимальном уровне: адекватно настроенный sudoers, наличие алертов на sudo bash сотоварищи которые кто-то реально получает и на которые обязательно реагирует, проведённый анализ логов показывающий возможность отследить кто и что делает, хоть какая-то защита логов от удаления.
главный риск такой чтобы сервис был не взломан, если взломан то минимально поврежден, если поврежден сильно то был быстро восстановлен с закрытием дырок через которые он был скомпроментирован.
Это типичная точка зрения технаря. С точки зрения бизнеса всё не так однозначно - ущерб вполне может оказаться застрахован либо "лечь" на того, кого "не жалко". Концепция "нам надо только точно знать кто виноват в инциденте" тоже имеет право на жизнь, если это требование необходимо для того, чтобы обеспечить гладкое получение той же страховки, например, или просто перенос ответственности чтобы какого-нибудь топа не назначили виноватым за инцидент. Мы работаем на бизнес и для бизнеса, закрываем его потребности, и они далеко не всегда совпадают с идеальными техническими решениями - к сожалению.
А чем это поможет в скрипте? ProxyJump нужен чтобы пройти через периметр, но никак не поможет в скрипте обойтись без пароля или беспарольного сертификата.
Когда процесс переписывает эту инфу всегда есть промежуток времени, когда он уже запустился, но ещё не переписал - он не очень большой, но во-первых может тупо повезти, а во-вторых если мониторить запуск чужих процессов скриптом то шанс увидеть оригинальные аргументы сильно увеличивается.
реалистичные сценарии есть такие о которых вы не догадаетесь
Есть. Но это не повод для карго-культа и театра безопасности. Предпринимая какие-то действия "для безопасности" стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают. Тупо механически выключать везде PermitRootLogin просто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.
если в логах написано
Как я с самого начала говорил, если в компании настроен полноценный аудит - то PermitRootLogin действительно нужно отключить, иначе он этому аудиту будет мешать. Но - это далеко не единственное, что нужно сделать, потому что sudo bash этому аудиту будет мешать ровно так же. И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".
Вообще, я в эту сторону давненько не смотрел, но вроде были какие-то способы логировать все exec-и на уровне сисколов. Если аудит делать на этом уровне, а не надеяться на "непробиваемый" /etc/sudoers, то и PermitRootLogin может аудиту не особо мешать - кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.
sudo решает (частично) вопрос аудита, не более того. Если в компании полноценного аудита нет - то PermitRootLogin yes может быть даже безопаснее, потому что sudo создаёт дополнительный вектор атаки (напр. вот, эскалация привилегий месячной давности: CVE-2025-32463).
Но, кстати, лет 15 назад у меня было сделано подобным образом. Тогда я зачем-то решил бэкапы со всех серверов сначала собрать на одном, и уже с него заливать в облако бэкапы всех серверов. Если не путаю, изначальная идея была в том, чтобы меньше зависеть от облаков и всегда иметь бэкапы локально на выделенном под это дело сервере. Но сейчас в этом особого смысла нет (а может и тогда тоже не было).
Да нет, с бэкапом всё просто - у меня сервера его сами делают и заливают в облако, ssh тут вообще не нужна. Я в общем случае про задачу "ssh в скрипте", для которой обычно и используются беспарольные ключи - когда такая задача триггерится не на самом сервере (как возможно сделать в случае с бэкапами) а снаружи.
это усложнение атаки на сервис, одно дело когда злоумышленник попал на сервер сразу рутом и другое когда ему надо искать способ поднять привелегии
Это традиционный контр-аргумент. Проблема в том, что он больше теоретический, нежели практический - в теории чем больше уровней защиты тем лучше. А на практике первым возникает вопрос: а каким конкретно способом злоумышленник попал на сервер через ssh не под рутом? И дальше обычно выясняется, что в реалистичных сценариях у него в любом случае будет рут, если рут есть у владельца текущего аккаунта.
и вообще под рутом в принципе нечего делать на любых машинах в корпоративной инфраструктуре, никому, даже самымглавнымадминам
Ну так не кладите ключи в /root/.ssh/authorized_keys2 и их там не будет. А если серьёзно, то, опять же, в теории это возможно, но на практике даже при использовании IaaC изредка всё-равно нужен прямой доступ под root - когда случается что-то нештатное (железо частично поломалось, нужно отлаживать какие-то серьёзные странности в поведении ядра, нужно разобраться с идущей прямо сейчас атакой или провести расследование последствий атаки, etc.). И в таких случаях PermitRootLogin no просто мешается под ногами, без какой-либо пользы от него ни в этот момент ни в остальное время (потому что полноценного аудита при котором от него польза может быть на практике даже в средних компаниях почти не встречается).
Это не про усиление безопасности в контексте текущей статьи. Это скорее про аудит - при условии, что он настроен, что его логи кто-то смотрит, и что никто не использует `sudo bash` и аналоги (впрочем, помним про то, что выйти в шелл можно из многих других приложений, включая vim, так что это не панацея и желающие выполнить команды мимо аудита всё-равно смогут это сделать). В остальном большой пользы от этой настройки нет.
А что, матом можно только в ответ на мат? А откуда тогда по этим правилам возьмётся первое матерное сообщение?
Даже если у человека не хватает профессиональных навыков, то это не значит что нет общения на профессиональном уровне. Ну или если хотите, то можете использовать прилагательное "деловом".
Я не могу говорить за Торвальдса, но из его ответа вполне можно предположить, что у него нет желания продолжать общаться на профессиональном уровне или иметь какие-то дела с автором этого PR. Скажите, если желания иметь общие дела нет - всё-равно все обязаны соблюдать деловой этикет в коммуникации?
Я вообще не понимаю зачем нужно ругаться матом.
Это не проблема. И конкретно Вас - никто не заставляет использовать мат. Проблема - что Вы считаете, что и другие этого тоже не понимают. Проблема - что Вы считаете себя вправе рассказывать другим, что они не должны использовать мат ни в каких ситуациях.
Все слова (включая и мат) в языке появились потому, что у людей в них есть необходимость. И да, в разных условиях и у разных людей есть необходимость в разных словах. Но это не значит, что ненужные лично Вам слова нельзя или нет смысла использовать другим.
Ну так а почему нельзя на работе болтать кому-то перед носом своими гениталиями? Или вы считаете что это можно и такое поведение тоже не нужно оправдывать.
Это некорректный пример. Просто потому, что, с одной стороны, есть прямо запрещающие это законы, а, с другой стороны, существуют такие люди как нудисты - их намного больше, чем Вам кажется (погуглите - изумитесь!), и они не видят в этом ничего плохого или нуждающегося в оправданиях.
Как минимум если мы говорим про айтишников или там вообще инженерные профессии.
Прекрасная оговорка. Т.е. Вы всё-таки отдаёте себе отчёт, что для начальника IT профнепригодность это использование мата, а для начальника строителей профнепригодность это не использование мата.
Давайте тогда и рукоприкладтство сразу запишем в "нормальные методы общения на работе". Ну если кому-то так проще доносить свои мысли до коллег и подчинённых.
Объективно, есть люди, которые словами - просто не понимают, и до них без рукоприкладства "не доходит". Да, обычно эти люди работают не в IT, но они совершенно точно есть, и их тоже довольно много. И да, рукоприкладство тоже плохой пример, потому что прямо запрещено законом - в отличие от мата.
Все Ваши примеры пытаются выставить мат чем-то очень плохим и сравнимым с нарушением законов - но это некорректно. Мат - это способ передать сильные эмоции (не только, но это одна из основных задач). Запрещать людям испытывать сильные эмоции - бессмысленно, мы это не контролируем. Запрещать людям эффективно сообщать другим, что они испытали сильные эмоции… ну, как минимум это довольно сомнительная идея, цели, задачи и эффективность которой неясны.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит. Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении. Всё, что докер даёт сверх этого - это "дополнительная фича", а не "урезанный вариант того что доступно для виртуалок".
Как вариант, ставите на сервак netdata (можно тоже в докере), и получаете обзервабилити выше крыши, включая и для контейнеров докера.
И как это может навредить безопасности? Докер же крутится в той же виртуалке, безопасность которой Вас устраивает. Значит за ядром в виртуалке Вы уже следите. А в остальном разницы никакой нет, просто базовые образы тоже надо обновлять - ровно так же, как и виртуалки.
Что значит "нужно"? Кому нужно и для чего? Обычно эти штуки берут как раз для усиления безопасности (чем меньше в образе лишних приложений тем меньше возможных векторов для атаки). Но если ваш ИБ считает что у "контейнерных штук" безопасность хуже, то он может вместо них брать и ubuntu:latest. Размер образа будет больше, но в остальном особой разницы нет.
Ну, статически собранные бинарники тоже можно деплоить не докерами. Докер вообще придумали не для "статики". Но в большинстве проектов есть не только статика. Впрочем, если у Вас весь проект состоит исключительно из статики фронта, то докер действительно может быть ненужен.
И чем именно базовые образы вроде ubuntu:latest более уязвимы чем ровно эта же убунта в виртуалке?
И почему это проблема ИБ, а не бизнеса? Если бизнесу ИБ не нужен - пусть накрутят дичь. Если бизнесу ИБ нужен, и дичь неприемлема - почему бизнес не выделяет ИБ необходимые для "сделать нормально" ресурсы? Тут где-то что-то явно не стыкуется:
или начальник ИБ не в состоянии донести до бизнеса то, что необходимо выделить ресурсы под эти задачи,
или бизнесу это на самом деле не нужно а ИБ просто удовлетворяет собственный синдром вахтёра,
или от ИБ бизнес требует создать видимость работы дёшево, но тогда не надо доказывать адекватность этой видимости работы с технической точки зрения на хабре,
или бизнес просто не осознаёт реальную цену излишних запретов ИБ.
"Решать" проблемы тупо запрещая что можно и что нельзя - этот приём активно используется в политике. Может в политике он и работает, не могу судить. Но в бизнесе этот подход совершенно точно вредит бизнесу.
Может ни одной задачи отдела ИБ это и не решает, а вот задачи разработчиков - очень даже решает. Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
Так что если ИБ не делает свою работу полноценно "потому что за это не заплатили" но при этом навязывает запреты "на всякий случай", то нужно понимать, что бизнесу эти запреты обходятся значительно дороже, чем оплата времени ИБ на придумывание и внедрение этого запрета. Безопасность и удобство обычно находятся по разные стороны, а неудобство - это лишние затраты времени, а время - деньги.
Поэтому лично я против театра безопасности. Когда что-то делается для усиления ИБ - это должно быть оправдано реальными нуждами/рисками/ситуацией текущего бизнеса и делаться это должно с пониманием - пониманием как технических аспектов так и цены для бизнеса (в которую входит и неудобство разработчиков в том числе).
А варианта и не делать работу и ничего не запрещать раз не платят - почему нет?
В докере чуть больше рисков, чем в виртуализации. Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов. Это вопрос баланса. И в докере есть достаточно много способов ограничить контейнеры, чтобы в большинстве случаев более высокими рисками по сравнению с виртуализацией можно было спокойно пренебречь. Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
Вы всё говорите правильно, и я с этим не спорю. В компаниях где реально внедрены любые стандарты ИБ есть адекватный аудит, и там отключать
PermitRootLoginдействительно есть смысл. Но помимо таких компаний есть те, которые до этого уровня зрелости ещё не доросли - их намного больше, и в них зачастую процветают карго-культы и театры безопасности вместо реальной ИБ.Я тоже да. Поэтому и говорю, что надеяться на это нельзя - пока процессы аудита не были поставлены и протестированы всегда есть высокая вероятность, что в логах будет что-то бесполезное вроде локального IP или вообще не будет нужного или сами логи будут удалены. Иными словами, я не против отключения
PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации. Хотя бы на минимальном уровне: адекватно настроенный sudoers, наличие алертов на sudo bash сотоварищи которые кто-то реально получает и на которые обязательно реагирует, проведённый анализ логов показывающий возможность отследить кто и что делает, хоть какая-то защита логов от удаления.Это типичная точка зрения технаря. С точки зрения бизнеса всё не так однозначно - ущерб вполне может оказаться застрахован либо "лечь" на того, кого "не жалко". Концепция "нам надо только точно знать кто виноват в инциденте" тоже имеет право на жизнь, если это требование необходимо для того, чтобы обеспечить гладкое получение той же страховки, например, или просто перенос ответственности чтобы какого-нибудь топа не назначили виноватым за инцидент. Мы работаем на бизнес и для бизнеса, закрываем его потребности, и они далеко не всегда совпадают с идеальными техническими решениями - к сожалению.
А чем это поможет в скрипте? ProxyJump нужен чтобы пройти через периметр, но никак не поможет в скрипте обойтись без пароля или беспарольного сертификата.
Когда процесс переписывает эту инфу всегда есть промежуток времени, когда он уже запустился, но ещё не переписал - он не очень большой, но во-первых может тупо повезти, а во-вторых если мониторить запуск чужих процессов скриптом то шанс увидеть оригинальные аргументы сильно увеличивается.
Есть. Но это не повод для карго-культа и театра безопасности. Предпринимая какие-то действия "для безопасности" стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают. Тупо механически выключать везде
PermitRootLoginпросто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.Как я с самого начала говорил, если в компании настроен полноценный аудит - то
PermitRootLoginдействительно нужно отключить, иначе он этому аудиту будет мешать. Но - это далеко не единственное, что нужно сделать, потому чтоsudo bashэтому аудиту будет мешать ровно так же. И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".Вообще, я в эту сторону давненько не смотрел, но вроде были какие-то способы логировать все exec-и на уровне сисколов. Если аудит делать на этом уровне, а не надеяться на "непробиваемый"
/etc/sudoers, то иPermitRootLoginможет аудиту не особо мешать - кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.sudoрешает (частично) вопрос аудита, не более того. Если в компании полноценного аудита нет - тоPermitRootLogin yesможет быть даже безопаснее, потому чтоsudoсоздаёт дополнительный вектор атаки (напр. вот, эскалация привилегий месячной давности: CVE-2025-32463).О, точно, есть же такая фича! Спасибо.
Но, кстати, лет 15 назад у меня было сделано подобным образом. Тогда я зачем-то решил бэкапы со всех серверов сначала собрать на одном, и уже с него заливать в облако бэкапы всех серверов. Если не путаю, изначальная идея была в том, чтобы меньше зависеть от облаков и всегда иметь бэкапы локально на выделенном под это дело сервере. Но сейчас в этом особого смысла нет (а может и тогда тоже не было).
Да нет, с бэкапом всё просто - у меня сервера его сами делают и заливают в облако, ssh тут вообще не нужна. Я в общем случае про задачу "ssh в скрипте", для которой обычно и используются беспарольные ключи - когда такая задача триггерится не на самом сервере (как возможно сделать в случае с бэкапами) а снаружи.
Ну, это всё-таки лучше, чем светить паролем. Кроме того - а какие есть доступные альтернативы?
Это традиционный контр-аргумент. Проблема в том, что он больше теоретический, нежели практический - в теории чем больше уровней защиты тем лучше. А на практике первым возникает вопрос: а каким конкретно способом злоумышленник попал на сервер через ssh не под рутом? И дальше обычно выясняется, что в реалистичных сценариях у него в любом случае будет рут, если рут есть у владельца текущего аккаунта.
Ну так не кладите ключи в
/root/.ssh/authorized_keys2и их там не будет. А если серьёзно, то, опять же, в теории это возможно, но на практике даже при использовании IaaC изредка всё-равно нужен прямой доступ под root - когда случается что-то нештатное (железо частично поломалось, нужно отлаживать какие-то серьёзные странности в поведении ядра, нужно разобраться с идущей прямо сейчас атакой или провести расследование последствий атаки, etc.). И в таких случаяхPermitRootLogin noпросто мешается под ногами, без какой-либо пользы от него ни в этот момент ни в остальное время (потому что полноценного аудита при котором от него польза может быть на практике даже в средних компаниях почти не встречается).Это не про усиление безопасности в контексте текущей статьи. Это скорее про аудит - при условии, что он настроен, что его логи кто-то смотрит, и что никто не использует `sudo bash` и аналоги (впрочем, помним про то, что выйти в шелл можно из многих других приложений, включая vim, так что это не панацея и желающие выполнить команды мимо аудита всё-равно смогут это сделать). В остальном большой пользы от этой настройки нет.
А что, матом можно только в ответ на мат? А откуда тогда по этим правилам возьмётся первое матерное сообщение?
Я не могу говорить за Торвальдса, но из его ответа вполне можно предположить, что у него нет желания продолжать общаться на профессиональном уровне или иметь какие-то дела с автором этого PR. Скажите, если желания иметь общие дела нет - всё-равно все обязаны соблюдать деловой этикет в коммуникации?
Это не проблема. И конкретно Вас - никто не заставляет использовать мат. Проблема - что Вы считаете, что и другие этого тоже не понимают. Проблема - что Вы считаете себя вправе рассказывать другим, что они не должны использовать мат ни в каких ситуациях.
Все слова (включая и мат) в языке появились потому, что у людей в них есть необходимость. И да, в разных условиях и у разных людей есть необходимость в разных словах. Но это не значит, что ненужные лично Вам слова нельзя или нет смысла использовать другим.
Это некорректный пример. Просто потому, что, с одной стороны, есть прямо запрещающие это законы, а, с другой стороны, существуют такие люди как нудисты - их намного больше, чем Вам кажется (погуглите - изумитесь!), и они не видят в этом ничего плохого или нуждающегося в оправданиях.
Прекрасная оговорка. Т.е. Вы всё-таки отдаёте себе отчёт, что для начальника IT профнепригодность это использование мата, а для начальника строителей профнепригодность это не использование мата.
Объективно, есть люди, которые словами - просто не понимают, и до них без рукоприкладства "не доходит". Да, обычно эти люди работают не в IT, но они совершенно точно есть, и их тоже довольно много. И да, рукоприкладство тоже плохой пример, потому что прямо запрещено законом - в отличие от мата.
Все Ваши примеры пытаются выставить мат чем-то очень плохим и сравнимым с нарушением законов - но это некорректно. Мат - это способ передать сильные эмоции (не только, но это одна из основных задач). Запрещать людям испытывать сильные эмоции - бессмысленно, мы это не контролируем. Запрещать людям эффективно сообщать другим, что они испытали сильные эмоции… ну, как минимум это довольно сомнительная идея, цели, задачи и эффективность которой неясны.