Чем плох Линукс. Или мифы про Линукс

Ну что вы обсуждаете? Strcpy memcpy - давно деприкейтед и их слабости известны. Екзекв - ну он как бы, и чё, сискол как сискол? Главное, деятели, ни одного инжекта не привели, а спору и взаимных упрёков в некомпетенции успели
накидать.

Какие тезисы на кону?
Малвари нет на Линукс ? - есть, много.
Линуксов мало? - линуксов много.
Смысла ломать Линукс нету? - смысл есть.
Линукс не стабилен? - весьма стабилен. И все нестабильно при выходе за флажки.
Я вот в гуи иос ощущаю себя как на луне или на Марсе. Но это моя проблема, а не оси. Просто мало сидел за ней.

 

например? но тут стоит более точно определить о каких типах малвари речь (способы доставки, установки, запуска).

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

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

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

 

Как это использовалось...

Можно подменить параметр в execv, причем код необязательно может-быть команда, например:

Код (Text):

1. execvp(arg[0],arg)

agv[0] мы можем подменить, например agv[0] = "telnet", запустит телнет.

Всё будет запускаться из-под рута и пароли никакие брутить не надо.

Как запустить сторонний код, а очень просто, по scp копируем бинарник и запускаем.)

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

Создавал пользователя, добавлял вирус в крон.

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

Извините за резкий пост предыдущий, незнаю почему бомбануло что-то.)))

--- Сообщение объединено, 2 мар 2020 ---

Достаточно часто ломают хостинги, через уязвимости ядра.
Ломают, через уязвимости в стороннем софте.

В убунте гуй в целом достаточно стабилен.

Такие системы как Дебиан и КентОС, они в принципе не заточены под десктопы, можно поставить конечно, но в основном это серверные системы, либо для встаиваемых систем.

Так достаточно надежны.

 

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

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

если мы говорим о х64, то там переполнение буфера годно лишь для дидосов.

xss, sql inject одинаково пройдут, что под линь сервачом, что под вынь. тч тут следует разделять ось-зависимые атаки и независимые.

--- Сообщение объединено, 2 мар 2020 ---

если на убунту/минт == пользуй снапы https://snapcraft.io

 

самый простой способ сбегать на exploit-db.com сейчас там 589 записей. а можно смотреть на историю патчей ядра, и вкуривать, чего это вдруг решили такой вот патч запилить. Линукс попроще винды, в нем нет части инжектов. А ботнеты на дырах пхп и питона, это как бы не проблемы оси.

--- Сообщение объединено, 2 мар 2020 ---

Не пробовал. Юзал либо дд, либо систембэк.

 

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

--- Сообщение объединено, 2 мар 2020 ---

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

 

против ремоут атак есть достаточно простые техники..

1. блокировка ипа временная при ошибочном вводе.
2. ограничение скорости подключения.
3. ложно-успешный вход на песочницы.
4. изменение дефолтных портов.
5. ограничение времени сессии.
6. запрет ипов проксей а-ля тор.
7. капча.
8. фильтры на команды..
8.1. ограничение длины команды.
8.2. запрет удалённого запуска крит команд иль привязка их к доверенным ипам/портам.
=========
короче, дырка и актуальная малваря есть две большие разницы == для успешной атаки требуется предсказуемая и устойчивая среда. ещё есть казус дырявой системы == при низком пороге входа малвари ось превращается в зоопарк и в итоге она либо глючно-тормознутая, либо тупо лежит. То бишь дырявые сервачи тоже вполне надёжны

весьма годная штука, также есть appimage https://appimage.org , для рхл и его семейства есть flatpak https://flatpak.org хотя, вроде, на бубунте тожЪ пахать должен, но мне для бубунты снапов хватает.

 

Ага, вы это владельцам ломанных серверов скажите.)

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

Поэтому обычно берут сервер с дефолтными настройками и работают в нем.

Также как собственно и с виндой, только там ещё хуже...)

Кстати распространенное заблуждение, что "Программисты шарят в безопасности", нихрена они не шарят, скажу более что большинству программистов вообще насрать, основные лозунги:

"Работает-же", "Ура собралось и запустилось"...

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

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

 

ну-так, они просто лежат и в этом их надёжность

в большинстве случаев они не нужны от слова СОВСЕМ == против ремоут атак есть более простые подходы (уже говорил), а для десктопа тоже сплошной оверкил == это называется ЗАЩИТИ СИСТЕМУ ОТ САМОГО СЕБЯ. к тому же, параноидальные настройки зачастую могут приводить к обратному эффекту == система поломается и галерь над восстановлением данных/доступа.

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

на заре всех этих дел, прогеры были инженерами. А теперь всё совсем не так.

 

Ну вот ProtonMail, например, отдали частной конторе на сертификацию по безопасности -- и сертифицировали.
Просто когда всплывет сообщение, что где-то там найдена уязвимость, рядовой пользователь может сделать
в корне неверный вывод, что платформа дырявая. Суть Линукса в серверах -- это серверная система. Enterprise
там априори безопасности уделяется внимания больше. И качеству, не всего, но связанного с серверами ПО.

Если автор не принимает коммиты, то можно форкнуть.

 

не совсем так == линь -- это набор дженерик кодов, кои можно запилить под задачу..

1. сервачи.
2. мобильные девайсы.
3. орг. техника.
...
====
в силу нарастающей нехватки (уже прогеров, а с инженерами давно всё грустно) линь стал затычкой во все дырки и это, кстати, весьма плохо, пч следующая стадия пролегает в острой деградации самого линя.

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

 

Всё из-за отхода от принципов Unix. И в особенности от этого страдает десктоп. Получается, что одни и те же действия делаются много раз в разных местах. Инженеров? Тут нужны люди уровня Дугласа Макилроя и Брайна Кернигана. А сейчас во главе всего стоят корпы -- получается распыление ресурсов сообщества. Это распад Линукса под собственной тяжестью. Линус постарел. Философы из мира Юникс повымерли (кто не захотел, того турнули). Бразды правления в руках корпораций и Линукс становится для них платформой для конкурентной борьбы. Инженеру такой котовасии не исправить -- если только быть затычкой.

По сути нормальная философия осталась только у ОпенБСД.

 

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

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

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

 

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

 

одно другому не противоречит == корпи в данном случае делают унификацию среды.

а что в этом плохого???

они приводят к фрагментации проектов == вон сколько на гитах валяется форков ради одной-двух строчек, а цельной поддержки у них нет, пч тупо не хватает чел-часов на допилку до ума. даже Линус про это..

 

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

Опен-сорц -- это не Венда для бедных, а от разработчиков и для разработчиков. Усложнение системы комбайнами делает части этой системы подъёмными только для корпорации. Т.е. плохого в этом именно то, что Linux планомерно превращается в Венду для бедных. Лично я ничего хорошего в этом не вижу. Мне нравится, когда ПО прозрачно для меня.

--- Сообщение объединено, 9 мар 2020 ---

И в чём проблема? Две строчки нужные двум людям должны войти в мэнлайн каждого дистра? СистемД не имеет столько форков только лишь потому, что никто не хочет копаться в его потрохах -- они банально большие.

 

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

 

Есть несколько проблем, или даже не проблем, а предложений.

1. Декларативный unit-файл
2. Параллельный запуск демонов, когда это возможно
3. Отслеживание и перезапуск демонов
4. Что-то там про безопасность.
5. Что-то про логи
6. Тема с перезапуском сервисов и их зависимостей во время работы
7. Может быть что-то там ещё.

И какой смысл решать их все и сразу? Так проще только на первом этапе, а потом кто угодно закопается. Есть такое понятие -- когнитивная сложность. Число образов, которые человек может удерживать в уме. В среднем 5. Если ПО превышает эту сложность, то его нужно дробить, иначе разработка сначала заме́длится, а потом и вовсе встанет. Инженер проблему сложности решает, но как правило в своей голове и только. Bus factor = 1. +/- Усилиями RedHat заменить разработчика можно. Но для рядового пользователя это просто закрытый мир. И все возмущения SystemD как раз из-за этого.

Допустим меня на 100% устраивает SystemD, но логи я хотел бы катать и грепать из /var/log. И я ничего не могу с этим сделать, т.к. сорцы очень большие и всё переплетено. Где там в доках про это читать -- не понятно (да и не охота =). То же, если захочу подменить формат unit-файла на свой, более удобный для меня. SysV давал все свободы. SystemD все их отнимает.

Вообще принцип "разделяй и властвуй" по сути и есть один из принципов Unix. А текстовый вывод -- это для того, чтобы не было привязки к ЯП. Допустим мне не нужна скорость работы ПО, а нужно быстро набросать там чуть-по-чуть. И с текстовыми интерфейсам я могу запросто это сделать. А когда мне нужно, когда есть зрелое решение, переписать на Си.

Суть распространённости СистемД как раз таки в корпорациях. Часть проблем по сути делегированы Red Hat (узурпированы Red Hat =) ). И все (промышленники) довольны. Но если бы спеки и разделение было бы, то были бы довольны и простые смертные. А так -- имеем то, что имеем.

https://twitter.com/gumnos/status/1123277201535918080

Я думаю, что дело в инструменте. Раньше всё упиралось в программу. Теперь в их набор. А инструментов для эффективной разработки, отладки и оптимизации набора программ либо нет, либо они в зачаточной фазе. Это просто переход к новому этапу. Но это мои философские домыслы.

P.S.: форум про ассемблер, сам по себе отрицающий, по сути, один из принципов Unix -- производительность всё, переносимость ничто. Ну да и это ладно.

 

neofit, дробление проги на модули лишь отчасти облегчает разработку (да, и цель там не столько в лёгкости обзора кодов, сколько в оптимазе использования озу), но по мере роста числа связей/состояний в системе любой подход нулёвый в плане удобств. меняешь строчку в одном модуле и надо отследить не будет ли крашей по всему кусту зависимостей. когда речь же идёт про управление индустриальными объектами, то там вольности юних принципов легко да просто приведут к фатальным авариям.

девуан/войд освободят тебя от оков систем-д https://devuan.org https://voidlinux.org другой вопрос, что сейчас куча сорцов собирается с зависимостью на систем-д

 

Как совместить удобство работы под линуксом с интересом к системному программированию под виндой? Ставить винду на Virtual Box под линуксом это единственная удобная альтернатива?