21 апреля 2021 года сопровождающий разработчик стабильной ветки ядра Linux Грег Кроа-Хартман (Greg Kroah-Hartman) объявил о введении глобальной блокировки на все коммиты от Миннесотского университета. Это было сделано из-за неэтичных экспериментов вуза с попытками намеренного введения в ядро Linux некачественных патчей — в них были ошибки и даже скрытые уязвимости. Часть патчей ранее даже попали в стабильные ветки Linux. Сейчас все коммиты от Миннесотского университета отозваны и перепроверяются мейнтейнерами проекта.
Разработчики Миннесотского университета занимались устранением настоящих уязвимостей в ядре Linux. Но в прошлом году одна из исследовательских групп вуза начала проект по продвижению скрытых уязвимостей с помощью коммитов в различные файлы и подсистемы. Потом, по заявлению представителя группы исследователей, они отзывали свои коммиты, а в код ядра Linux не уходили некорректные исправления.
В феврале этого года в научной работе они показали, что смогли тайно внедрить множество уязвимостей в различные проекты с открытым исходным кодом. Коэффициент одобрения их кода был 60 %.
Оказалось, что это было не всегда. Грег Кроа-Хартман лично перепроверил несколько проблемных коммитов от Миннесотского университета, причем их разработчики настаивали на своей позиции в переписке и уточняли детали необходимости их внедрения различными отговорками. В настоящее время Грег Кроа-Хартман откатил 190 коммитов разработчиков Миннесотского университета. Их деятельность внутри сообщества продолжает проверяться и анализироваться. Так сообщество уже обнаружило, что часть из ранее якобы отозванных в научной статье патчей были с умышленными уязвимостями и разработчики их пропустили.
Администрация Миннесотского университета также в курсе этой неприятной ситуации и запретила своим преподавателям и аспирантам факультета компьютерных наук заниматься исследованием безопасности ядра Linux таким способом. Университет начал со своей стороны проверку исследования и обещает, что в будущем такое не повторится.
Мейнтейнер ядра Linux и сотрудник Google Тед Т'со (Ted T'so) пояснил, что ранее команда университета делала полезную работу по обеспечению безопасности и вносила нужные для развития проекта коммиты. Даже после окончания исследовательской работы, о которой должны были знать в сообществе разработчиков ядра Linux, сотрудники вуза не раскаиваются и не понимают, почему такие эксперименты по сути на людях, неприемлемы.
Технологический стратег Red Hat Джред Флойд сравнил действия команды университета с умышленным перерезанием тормозных шлангов машин на парковке и фиксацией, сколько людей пострадает от этого, если не заметит и поедет домой.
Не все разработчики согласны с решением сообщества. Так, инженер по криптографии и программному обеспечению в Google Филипо Валсорда считает, что безопасность кода ядра Linux заслуживает большего внимания, чем выходки исследователей, и что блокировка коммитов на основе домена электронной почты университета, без подтвержденной проверки правильности кода, является более серьезной проблемой.
defaultvoice
Ну вообще эксперимент неплохой. Не слишком этичный, но неплохой. Намеренные и общеизвестные коммиты с уязвимостями гораздо лучше, чем если бы этим занимались хакеры втихую (хотя, может и уже занимаются). Возможно, мейнтейнеры начнут проверять коммиты более тщательно или придумают, как частично автоматизировать ревью.
merlin-vrn
Нормально было бы, если бы эти Qiushi Wu и Kangjie Lu вместе с публикацией статьи https://github.com/QiushiWu/qiushiwu.github.io/blob/main/papers/OpenSourceInsecurity.pdf (стоит кстати добавить ссылку в пост — из-за этой статьи весь шум) отослали бы Грегу точный список всех этих коммитов, желательно в виде ещё одного коммита, который всё ревертит. Рожу бы конечно он скривил и в этом случае, но совесть была бы чиста, потому как ему не пришлось бы делать теперь всю эту работу.
А они этого не сделали. За что их университет забанили (ведь они действовали от имени университета, который в данном случае выступил этаким "обезличнным хакером"). Воспользовались его авторитетом (и подорвали его). По сути сообщество идентифицировало и забанило злоумышленника (университет), ищет и отзывает его коммиты, т.е. среагировало в общем-то нормально.
У простого хакера со стороны так не получится сделать — он не сможет слать коммиты с университетского имейла, поэтому на него по-любому сразу будут смотреть с бОльшим подозрением, про что кстати и в почтовой рассылке упоминалось.
ollisso
А вот тут вопрос — использовался ли какой либо «доверенный» аккаунт университета, или же просто «вася пупкин из университета».
Если первый — то согласен, они пользовались незаслуженным доверием.
Если же «Вася Пупкин», то стоит помнить что обычно его может получить любой студент университета. Т.е. только поступил — и уже у тебя есть такой емайл, т.е. ни о каком спец доверии говорить не имеет смысла — то что Вася Пупкин поступил в университет не даёт ему особого доверия.
И второй вопрос — что же там были за уязвимости, которые удалось протолкнуть в основной код? Т.е. если исследователи смогли, и их смогли поймать только когда они опубликовали статью об этом, то фактически, получается, что кто угодно с большим желанием сможет протолкнуть такие проблемные изменения в основной код :) Т.е. проблема и в самому процессе ревью комитов.
merlin-vrn
"Вася Пупкин из университета" считается (лся) доверенным потому, что "из университета".
Если это студент и его поймают за злоупотреблениями от имени университета, он оттуда быстро вылетит, и дело тут вовсе не в опенсорсе — любые злоупотребления от имени университета не будут долго терпеть. Есть предположение, что даже и авторам указанной статьи, которые уже далеко не студенты, не поздоровится, и даже наверняка перепадёт комитету по этике, который дал дорогу проекту. И разумно будет, если всем влетит именно за то, что не сообщили список коммитов/не предложили реверты, а не за то, что занимались исследованиями, хотя это ещё посмотрим.
Авторов поймали не после публикации статьи. Вы переписку-то почитайте в рассылки. Началось всё как раз с того, что кто-то начал ругаться на бессмысленный подозрительный коммит, а тот, кто его запостил (Aditya Pakki), стал отбиваться, мол, "у меня есть право на ошибку" и юлить всячески, изобрёл байку про новый статический анализатор, который он якобы разрабатывает и это, мол, анализатор предложил такой фикс, поймите правильно, он ещё совсем в ранней стадии разработки. Далее нашли и ревертнули ещё несколько его подобных коммитов и несколько похожих штук от других людей, в том числе задели пару невинных. И только через некоторое время Грег раскопал эту статью и уже после этого забанил университет и затеял масштабную проверку.
Кстати, Aditya Pakki как раз, вероятно, студент. Среди авторов статьи его нет, а коммиты от его имени.
Я не говорю, что "всё хорошо". Я говорю, что исследование само по себе херовое, так заниматься исследованиями нельзя. Его нельзя называть "исследованием", это явное вредительство. Не столько для коммьюнити линукс, сколько для репутации университета. В принципе, там же в рассылке учёные уже высказались в этом духе.
DaneSoul
merlin-vrn
Это не знаю, но знаю, что университет при поступлении жалоб заблокирует учётную запись и будет разбираться.
wataru
Он аспирант. Там один профессор проводит исследования на тему безопасности и разные его аспиранты эксперементируют и пишут статьи. Видимо, по результатам этих бессмыссленых найденных комитов Aditya собирался написать статью. Но не прокатило.
merlin-vrn
Теодор Цо заметил, что этот "один профессор" в прошлом сабмитил и нормальные фиксы настоящих багов, но вообще у него, так сказать, особое понимание этики, а в университете, похоже, нет настоящей проверки на этичность и поэтому правильно забанили.
beeruser
На фоне синофобии, проталкиваемой западными СМИ, с такими фамилиями я бы поостерёгся заниматься намеренным вредительством.
merlin-vrn
Я думаю, другие исследователи будут с сомнением относиться к коллаборации с этими персонами, а уважаемые журналы будут не очень охотно принимать их статьи к публикации.
chapai22
Китайцы, под прикрытием имени американского университета, намеренно компрометировали линукс и вкрячивали дыры. Если по простому.
Называя это "исследованиями" — так что еще и на американские деньги, что совсем молодца.
mithdradates
Шапочку из фольги наденьте. Если бы это было конечной целью, то они бы и не публиковали статью.
chapai22
всякие бывают в жизни накладки. Может им славы захотелось, а не безликого "1001й в 100ом ряду слева на церемонии вручения одного на всех ордена в китайском кгб". А может индус подвел и пришлось план Б.
mithdradates
osmanpasha
Другая сторона заявляет обратное — что комиты (минимум один) из статьи в мэйнлайне: https://m.habr.com/ru/news/t/553712/#comment_22960362
hellamps
и это проблема Грега.
сейчас под емейлом условного мистера Смита может работать как анб, так и гру, так и северокорейское агенство чучхе.
любой субъективизм в ревью на основе предыдущих заслуг — недопустим
ss-nopol
Вообще говоря разработчикам нужно проделать теперь всю эту работу в любом случае. Патчи для реверта слать пока не надо, потому что весьма интересно, какой процент лазеек в безопасности разработчики найдут теперь, после того как им уже известно где их искать! Было бы интересно по этим результатам почитать ещё одно исследование.
«Университет» это большая организация, причём с запрограммированной текучкой. Бездумно принимать коммиты без проверок, лишь потому что они исходят от «проверенной» организации, довольно легкомысленно. От отдельных проверенных разработчиков, зарекомендовавших себя, ещё куда ни шло.
Но даже если код исходит от проверенных разработчиков, аудит всё равно не помешает.
Очень полезная работа, на месте разработчиков Линукса, я бы поблагодарил.
merlin-vrn
Нет-нет-нет. Надо обязательно. Иначе реальные баги окажутся в боевой системе, например, моей или того парня.
Я имел ввиду, что если бы список они с самого начала отослали, вместе со статьёй, это с натяжкой, но можно было бы назвать этичным. Они хотя бы таким образом не добавили лишней работы и так занятым людям. А сейчас, занимаясь сомнительными исследованиями, они их ещё и поднагрузили.
Это как представьте себе, идут люди, думают о том, куда идут, какой маршрут, какая цель, короче, не дурака валяют, а кто-то ставит им подножки и всячески мешает, а потом пишет об это статью, в которой показывает на всех пальцем, мол, "все эти дурачки под ноги-то не смотрят, куда они дойдут с такой внимательностью, и вообще внимательность у людей никакая, вот, мы исследовали". Ты бы хотя бы у людей спросил, "исследователь", и улицу-то выбрал не такую забитую и людей не таких занятых. И это, хотя бы подняться на ноги помогал тем, кто упал из-за тебя. Раз это ты не делашь — ты самый настоящий хулиган, а не исследователь.
ss-nopol
А то их там нет сейчас? Бояться нужно тех лазеек, которые внедряли без уведомления. Такой внеплановый аудит поможет выявить, сколько процентов лазеек они смогут найти, даже зная где искать. Весьма полезное и важное исследование.
Важность безопасности Линукса трудно переоценить. Я не считаю работу над безопасностью «лишней». Если разработчики Линукс так считают, это очень плохой знак.
Ага, и ещё показал, что и где внедрил. Нет. Программист из АНБ никого спрашивать не будет. А если разработчик ядра «слишком занят» и у него «нет времени» чтобы заниматься проверкой патчей на предмет безопасности, то ему следует снизить темп приёма патчей.
Безопасность ядра слишком важная вещь, чтобы заниматься ею по остаточному принципу.
merlin-vrn
Ну повторяю, хулиган ты тогда, а не профессор, и отношение к тебе будет как к хулигану. В приличном обществе с тобой иметь дела не станут. Я надеюсь, что именно такое и произойдёт с этим Kangjie Lu.
Этого Aditya Pakki ткнули носом в херовый коммит, и нормальный человек в таких случаях коммит отзывает. А этот не отзывает.
Важно, что эксперимент происходит на самом деле не над линуксом и его безопасностью, а над сообществом, над людьми. Университет это не просёк, за что получил порцию какашек. Линукс тут как таковой выбран в качестве "сцены" эксперимента, и это херовый выбор в случае такой постановки эксперимента.
Список коммитов для реверта предоставить надо обязательно. Пришёл, поэкспериментировал? Молодец, а теперь мусор за собой прибери. Почему это сообщество за тобой его должно вычищать? Ты и так без разрешения только что воспользовался ресурсами этого сообщества.
Видимо, либо у вас тоже несколько всё печально с этикой, как у этого "профессора", либо у меня со способностью объяснять, раз вы не понимаете, в чём собственно тут проблема.
nidalee
Исследование, в общем-то, полезное. И самое главное, что должны понять разработчики, это то, что у них сейчас проблемы не из-за коммитов детишек из университета. Если они умудрились протащить 60% своих зловредных хотелок, то сколько внедрил человек, который этим на жизнь зарабатывает? 90%?
merlin-vrn
Ещё раз, это не исследование, это хулиганство. Исследованием это станет не ранее, чем исследователи возместят сообществу тот ущерб, который они создали в процессе. Пришёл, нагадил, так и оставил и написал статью об этом — это ненормально.
myz0ne
Хакер солонка? Если вы пойдете в ресторан и насыпете слабительное с сахарницу — это тоже будет полезным исследованием? И проблема у ресторана будет не из-за исследователя? Я вот считаю что некоторые вещи нерентабельно решать техническими методами. Надо применять административные меры. Намеренно нагадил и это доказано — штраф. Повторилось — посадить.
Иначе варвары победят цивилизацию.
nidalee
А штрафы за закладки АНБ кому выписывать?..
Как по мне, так у людей просто шаблон "открытый код — это безопасно, его же любой может прочитать!" треснул по швам. Потому что прочитать могут, но делать, этого, конечно, не хочется: "у меня времени мало!" Может быть эту проблему решать?
(Линуксом сам пользуюсь, если что)
myz0ne
Вопрос хороший. Думаю тем же кому выписывают штрафы за спецоперации с жервами/санкциями (никому).
nidalee
Ну так исследование привлекло внимание к тому, насколько легко студент сможет протащить в важный код закладку. Это тебе не в ресторане с людьми солонки раскурочивать, там раньше застукают!
merlin-vrn
Оно привлекло бы меньше внимания, если бы было выполнено этично, с откатом кривых патчей вместе с публикацией статьи?
nidalee
Нет. Но теперь у тех, кто за это отвечает, будет шанс пересмотреть то, что они принимали не глядя все это время.
Или тут кто-то серьезно думает, что левые коммиты только детишки из университета присылали? Это ведь почти heartbleed наклевывается, а то и не один. Впрочем, а давайте просто попросим приколистов все откатить и забудем, как страшный сон? А то времени ведь мало...
От меня тоже UPD: да, меньше. Не припоминаю особо уязвимостей со времён вышеупомянутого, когда люди бросались перелопачивать коммиты за год. Тогда, правда, вроде никто не жаловался, что времени нет. С другой стороны и ничему не научил тот инцидент.
merlin-vrn
Так тут никто и не бросился перелопачивать коммиты все за год.
В текущем виде это привлекло больше внимания к проблеме мудаков в университете Миннесоты, а не ревью коммитов в сообществе линукс.
nidalee
Ну значит забудем, как страшный сон, и будем надеяться, что больше никто и ничего левого в код не закоммитит.
Правда не знаю, как с таким подходом к безопасности можно еще на что-то жаловаться.
mithdradates
Как говорится:
:)saege5b
Рассказ «Хакер в столовой».
ss-nopol
Я не согласен. Это не мусор.
Если разработчики даже после того как узнали, где искать, найдут, скажем, только половину лазеек, то это будет очень важным показателем.
По-моему проблема в том что кто-то пытается проблемы с безопасностью замести под ковёр, прикрывшись атаками на того, кто эти проблемы выявил.
Нормальная этическая реакция за нахождение таких зияющих дыр — благодарность. Логично было бы взять Aditya Pakki руководителем в группу занимающуюся безопасностью ядра.
В любой случае, работу он теперь точно найдёт. Но хотелось бы, чтобы он продолжил заниматься ядром, раз у него так хорошо получается.
merlin-vrn
Я не понимаю, как можно считать нормальным эксперименты над безопасностью, не ставя в известность того, чья это безопасность. А как вам такое: сломать стержни работающего ядерного реактора замысловатым образом, не сказать, какие и как, и потом смотреть, найдут ли и починят ли? Нормально?
Вот сейчас осталось несколько коммитов, возможно, вносящих проблемы с безопасностью. Они попадут, скажем, в очередной релиз ядра и эти проблемы с безопасностью появятся у миллионов пользователей. Причём есть люди, которые точно знают, какие именно патчи и какие именно проблемы. Всё ещё это у вас сомнений в этичности этих людей не вызывает? Я не знаю, что и сказать, очень печально это.
На АНБ не кивайте. То, что там работают люди странноватые, мы и так знаем. Не в этом вопрос. Вопрос в том, что такие же странноватые люди работают в уважаемом университете и что это за университет такой замечательный и чему он может научить хорошему. А вы предлагаете ещё и доверить свою безопасность таким людям. Они так глядишь и кардиостимулятор выключат, для проверки, что будет, мало ли что в голову придёт ещё проверить.
ss-nopol
А я не знаю, как можно проверить безопасность, ставя в известность тех, кто за безопасность отвечает. Правильный способ проверить, на сколько правильно проводится аудит безопасности — попробовать взломать систему, без предупреждений, в неподходящий момент и в самом ответственном месте, естественно. Что они успешно и сделали.
Отмазки «я устал», «у меня нет времени» — не катят.
И тем важнее проверить, как хорошо разработчики Линукса смогут их выявить. Помимо этого они, возможно, параллельно найдут и другие лазейки. А может быть и нет. Вот и узнаем.
Если они не будут пользоваться этими лазейками, то в чём неэтичность? Всё не просто этично, а наоборот, образец для подражания.
Да им памятник ставить надо! Объявить благодарность, попросить научить, где и как нужно закрыть лазейки, создать группу для для выработки контрмер, желательно с их участием.
Надо создать специальный фонд и поощрять таких людей специальными денежными призами.
wataru
Обязательно кто-то из руководителей организации жертвы должен быть в курсе и одобрять такое дело. Понятно, что нельзя в запросе писать "мы тут вас на вшивость проверяем, но вы не обращайте внимания. Как вам патч?". Но получить разрешение на такие эксперименты от Линуса или еще кого-то стоило бы.
Во-первых, это фундаментальный вопрос согласия. Взлом — вещь противозаконная. И только согласие жертвы отделяет пен-тест от преступления.
Во-вторых, Иначе можно просто пытаться что-то ломать и, если не прокатит, утверждать, что это был просто ресерч и пен-тест. А если прокатит — собирать профит.
ss-nopol
Это нарушило бы чистоту проверки. Линус мог бы возразить против проверки и предупредить всех или какую-то группу.
Законы это уже другая область, там пусть юристы разбираются. С этической стороны — всё ок.
Они же так не поступили.
wataru
Ваш аргумент звучит как: "не надо спрашивать разрешение, а то вдруг откажут".
Если бы Линус возразил, то пришлось бы искать другое сообщество для экспериментов.
Это спорный вопрос. Сами разработчики, которые решили забанить весь университет — другого мнения. И вообще, эксперименты над людьми без их информированного согласия любой комитет по этике в университете сразу бы зарезал. Это конкретное исследование прошло проверку, только потому что комитет даже не стал рассматривать с аргументацией вида "Да этика к этим компьютерам не относится вообще. Никаких людей, одни биты и байты, черт с ними". Теперь будут внимательнее смотреть.
Это аргумент, почему так сделано в принципе. То, что в конкретном случае этим не воспользовались не отвергает эту возможность.
ss-nopol
Именно!
Вовсе нет. Их работа очень полезна и согласия Линуса или ещё кого-либо для этого не только не требуется, но и нарушило бы чистоту эксперимента.
Единственное, что нельзя делать — публиковать сами уязвимости, до того как поставлены в известность разработчики ядра. Информацию о наличии уязвимостей — уже сомнительно. А сами уязвимости делать доступными для всех, до того как поставлены в известность разработчики — нельзя конечно, это не этично.
Аргумент подразумевает наличие «взлома». Но само его наличие спорно, пока не опубликована сама уязвимость.
То есть посылать вредоносные патчи для проверки безопасности — можно и нужно. Попытка запретить и тем более преследовать за такие действия, приведёт к падению уровня аудита и уровня безопасности ядра.
Сообщить о существовании такого патча, но не сообщать, где именно находится закладка — можно (но конечно исключительно в соответствующем «security» списке рассылки ).
Публиковать уязвимость без того чтобы заранее сообщить в соответствующий список рассылки — нельзя конечно. Это уже очевидный вред и даже преступление.
Было ли последнее сделано?
wataru
Не надо спрашивать? А давайте я к вам домой приду, поем вашу еду, посплю в вашей кровати? Без спроса, естественно. А то вдруг вы откажете.
Во-первых, можно провести тот же эксперимент, но сначала договорится с Линусом, чтобы точно никакой бяки в репозиторий случайно не попало. Чистота эксперимента не нарушена и хотя бы попытка соблюсти этику были бы. Во-вторых, если идеально чистый эксперимент невозможно произвести без нарушения этики экспериментирования над людьми, то, наверно, с этим надо смирится и поискать другой эксперимент? Вот нельзя получить согласие на проверку, как современные мегаполисы рушатся при ядерной бомбардировке. Это, по-вашему, значит, что и не надо спрашивать? Знание-то в результате полезное будет. Где вы проводите границу, почему взрывать ядерное оружие в центре мегаполиса нельзя, а комитить вредоносный код в стабильную ветку ядра можно? И то и другое, в общем-то, уголовное преступление.
Ну вот аналогия: Чтобы вы лучше защищались от похищения — вас похищают, увозят в неизвестном направлении, но потом отпускают без требования выкупа. Вам это понравится? А ведь отличная проверка безопасности общества получается. Ну, подумаешь — продержали вас в подвале с мешком на голове несколько часов.
Так и тут. Это "тестирование" отнимает время и силы разработчиков, которые никому ничем не обязаны, денег за это не получают.
Какую пользу это исследование принесло? Показало, что ревью не идеален? Еще бы выяснили, что вода — мокрая.
Вот искать баги в репозитории и фиксить их или искать вредоносные коммиты — это другое дело было бы.
ss-nopol
Если от безопасности моей квартиры непосредственно зависела безопасность большинства (миллиардов) других квартир, то аналогия была бы уместна. И было бы понятно Ваше беспокойство о безопасности моей квартиры. Но такой зависимости нет.
Нет, это не годится, по причинам изложенным выше. Кроме того, в репозиторий оно должно было попасть, потому что репозиторий тоже периодически проверятся «тысячей глаз». Это между прочим один из важных аргументов в пользу свободного софта.
нет
Очевидная громадная польза и отсутствующий маловероятный вред.
Смотри объяснение выше, в примере с квартирой. Если моя безопасность напрямую влияет на безопасность миллиардов других людей, то такая проверка может быть вполне уместна.
Насчёт «не получают денег», это зря, некоторые разработчики вполне себе сидят на зарплатах. Но это не важно, даже если бы не сидели. Безопасность линукса слишком важна для всего человечества, чтобы заниматься ею спустя рукава. Может быть как раз пора обратить на это внимание и побольше разработчиков занимающихся безопасностью посадить на хорошую зарплату.
wataru
Ну так пусть и ищут баги и дыры в линуксе, а не отвлекают разработчиков, чтобы написать статью.
ss-nopol
Так ведь нашли. Это дыра чудовищных размеров — 60% зловредного кода попала в ядро и не была удалена длительное время.
Если кто-то не понимает что это значит, то объясню — скорее всего линукс, к сожалению, кишит такими зловредами.
merlin-vrn
Баги в линуксе они не нашли, а добавили. Это большая разница. Баги они нашли в коммьюнити, а не в линуксе. А с коммьюнити, с людьми категорически нельзя так обращаться, как будто это софт и винтики, мол, "замените" или "исправьте". И хулиганов за это реально нужно наказать, чтобы неповадно было.
ilammy
Так вот и нашли: дыру между стулом и клавиатурой. Подтвердили её наличие.
merlin-vrn
Профит в виде исследования и статьи о нём они получили.
ss-nopol
И это хорошо, потому что исследование крайне полезно.
Единственное что нельзя делать, это публиковать сами уязвимости до того как о них было сообщено в linux-security. Если они такое делали, то за это их можно ругать и возможно даже привлекать. А за сам эксперимент — только хвалить.
Kanut79
Вот соседняя новость на хабре:
Или до этого вот такая:
И кто там у кого спрашивал разрешения и кто кого ставил в известность? Теперь у обеих сторон будут проблемы с законом? Тех и других теперь будут "считать хулиганами" и с ними никто не захочет иметь дела? Ну или в чём принципиальная разница?
merlin-vrn
В том, что в обоих случаях никто специально не вносил в указанное ПО проблемы, а только выявил имеющиеся. Сообщество вокруг линукс тоже не против, чтобы в нём выявили и желательно исправили проблемы в коде.
Я полагаю, проблемы в сообществе разработчиков конечно есть, и не только эта. Но вот работать так с людьми нельзя.
Kanut79
Как быть если проблема не конкретно в самом софте, а в том "способе" или "процессе" при помощи которого он создаётся?
То есть если система в принципе позволяет пропихнуть левые коммиты, то это проблема и её надо исправлять. Или по вашему это не проблема и такое проверять не надо? А если всё-таки надо, то как тогда?
И это здорово если до сих пор никому не пришло в голову что-то там пропихнуть в линукс таким образом. Что на самом деле совсем не факт. Но даже если, то где гарантия что такого не произойдёт в будущем?
Ну то есть по вашему когда работаешь с людьми, то обо всех проверках надо обязательно предупреждать заранее? Или как это понимать?
А кого конкретно и каким образом надо предупреждать в случае с общими опенсорс проектами? Ну так чтобы "кому надо" о проверке знали, а те кого проверяют не знали? И что делать если кто-то не хочет чтобы его или его проекты проверяли?
Как быть если часть сообщества хочет провести проверку, а другая часть против? Не проверять?
То есть на мой взгляд если эти ребята постфактум огласили весь список левых коммитов, то к ним особых претензий с этической точки зрения быть не должно. Они просто помогли выявить косяки системы. Если не огласили или огласили не все, то за это их можно осуждать. Но только за это.
merlin-vrn
Cписок не огласили. Более того, началось-то всё с того, что их ткнули носом в то, что некий коммит говно, а они вместо нормального признания косяка и отзыва коммита начали извиваться как ужи на сковороде, что мол мы не виноваты, это анализатор кода новый, и т. п.
При этом, создав людям проблемы, они ещё и получили профит в виде исследования и статьи о нём.
С людьми так нельзя. Если уж ты ставил незаметно и без спроса подножки с целью исследования, как люди могут удерживать равновесие — будь добр, нежно лови тех, кто всё-таки не удержал, чтоб не ударились. Ну или лови заслуженные какашки от тех, кто ударился, в том числе, тех, кто может и ударить в ответ.
ss-nopol
А список уязвимостей опубликовали? Если огласили сами уязвимости, то даже если опубликовали патч с исправлениями, это всё равно очень плохо.
А если не опубликовали уязвимости, то и воспользоваться ими никто не может, то есть проблемы нет.
avost
С аудитом безопасности это имеет столько же общего, сколько "телефонный терроризм". Только ещё хуже — телефонщики настоящих бомб не оставляют.
Это ведь важно проверить как хорошо осуществляется эвакуация школ и больниц. Помимо этого, полицейская собака имеет возможность найти ещё какую-нибудь бомбу — вдруг, кто забыл?
В чём неэтичность намеренно вводить уязвимость в продукт, ктторым все пользуются? Хакер и солонка?
Вона, как! Оказывается, мамкиных школьных минёров нужно поощрять!
ss-nopol
Если какой-то «телефонный террорист» задался целью и реально помог своим звонком выявить серьёзные системные проблемы с безопасностью людей, то такое сравнение уместно. В таком случае польза от «телефонного террориста» безусловно есть, как и в этом случае.
Если этим занимаются из рук вон плохо, а опасность пожара велика, и эвакуация реально поможет спасти жизни людей, то конечно это важно.
Если бы опасность отравления соли была не надумана, а реальна (отравления случаются регулярно раз в месяц), то такая аналогия была бы уместна. И безопасностью солонок пришлось бы реально заниматься, как занимаются безопасностью ядра.
avost
Ну, а то, что из-за эвакуации пришлось прервать операции и погибло десяток пациентов — это же сущие мелочи? "Ещё нарожают" — правда?
Ээээ, вы утверждаете, что уязвимости намеренно вносятся в ядро линукса с регулярностью раз в месяц? И что это не реальные уязвимости, а "надуманые"?!? Кажется, кроме вас и этих
малолетних долбоёмамкиных террористов больше никто до такой дури не додумался. У вас другая информация?Ээээ? Я не знаю об уязвимости, значит её нет? Риали?
ss-nopol
Если при пожаре регулярно гибнут сотни, то это тем более не мелочи.
Я хочу сказать что уязвимости находят регулярно. А уж как они вносятся — хороший вопрос для нового исследования. Сколько из намеренно внесённых находится, мы теперь знаем — около 40%, меньше половины.
Какие-то уязвимости есть всегда и даже известны, но не всякой уязвимостью легко воспользоваться.
Ты не знаешь пароль от моей почты, поэтому ты не можешь её прочитать. Однако остаётся небольшая вероятность что ты можешь угадать пароль. Угадать возможно, но очень трудно и маловероятно. Пароли, ключи, шифрование — вот это всё основано на вероятности. Небольшая вероятность взлома путём угадывания всё равно остаётся, но 100% защиты нет. Некоторые способы шифрования и защиты вообще основаны на недоказанном предположении P!=NP.
В случае с уязвимостью кода единственный способ — регулярно искать уязвимости и закрывать их раньше, чем их найдут злонамеренные люди. Для этого должен быть хорошо поставленный процесс проверки присылаемых патчей и периодического проверки уже существующего кода.
Кроме того, я выяснил что их патчи не несли в себе сознательно внесённых уязвимостей, которые бы было возможно реально эксплуатировать.
Поэтому единственный аргумент который остаётся против них — дополнительная работа для разработчиков.
avost
Тут я перестал понимать. Если не мелочи, то какая разница сколько гибнет? Это в любом случае дополнительные жертвы. Готовы ли вы пожертвовать жизнью своего ребёнка, которого
малолетние долбоёмамкины террористы-"исследователи" для развлечения отключат от аппарата жизнеобеспечения во время операции? Ведь эта эвакуация на потеху дебилам якобы спасёт миллионы (с чего бы это?)А это-то здесь причём? Как из того, что уязвимости находят регулярно следует необходимость их сознательного внедрения? В моей вселенной всё ровно наоборот. Впрочем, вы программер? Попробуйте регулярно повнедрять баги в вашу разработку.
и поэтому их надо внедрять ещё больше?!?
Уязвимость либо есть, либо нет. Если она есть, то ею можно воспользоваться, если нельзя, то это не уязвимость. Не? Кроме того, даже если сейчас нельзя ею воспользоваться, это не значит, что способ не придумают позже. Тот же пример Spectre это показывает — поначалу все эти манипуляции со спекулятивным выполнением казались низкоуровневыми фокусами без возможности реальной эксплуатации, а потом оказалось, что это можно юзать даже на javascript'е.
Ну, вот вы всё же попробуйте на своей работе поставить этот эксперимент. Он же полезный! Узнаете и другие аргументы :)
ilammy
Воу-воу, не надо демагогии. Нельзя сравнивать статистику и отдельных людей. Кто-то может быть согласен и миллиардом пожертвовать, чтобы спасти своего ребёнка — это не значит, что каждое желание следует удовлетворять.
ss-nopol
Количество гибнущих и есть целевая функция, которую мы оптимизируем. Эвакуация, медицина, противопожарная безопасность, это всё про минимизацию этой функции. Вроде бы простые, доступные вещи? Странно что приходится объяснять.
Для проверки процесса приёма патча, вот ради этой цифры в 60%. Но я это уже говорил. По всей видимости впустую.
К сожалению, у нас на работе закрытый софт, то есть таких лазеек нет. А так было бы интересно, конечно.
myz0ne
Уверены? А зависимостей в коде никаких конечно же нет? Или есть и вам можно подсунуть уязвимости через зависимости? Или выполнить код на CI в процессе установки зависимостей проекта? Или вы весь код от которого зависите аудируете и просматриваете? И зависимости зависимостей тоже? Или экономите время разработчиков и доверяете?
ss-nopol
Зависимости есть (то же ядро линукс) и им приходится доверять, именно поэтому аудит патчей меня так интересует.
Но нам эти патчи не присылают.
myz0ne
Так списки рассылок публичны, код публичен — ревьювьте на здоровье. Или вы таки надеетесь что там в ядре не нассут вам в солонку и доверяете сторонним людям? А разработчики ядра к вам такие же сторонние люди как те, кто присылает патчи в ядро к мантейнерам ядра.
wataru
Нет, все далеко не так просто.
Есть тривиальная оптимизация: убить всех людей прямо сейчас, как можно скорее — пока они детей не наделали. Общее количество смертей будет сильно меньше. Эти-то все-равно умрут, но еще и потомство смертное оставят. Даже если считать только смерти от травм или болезней в рассвете сил — на большом промежутке времени накопится сильно больше чем сколько там сейчас людей живет в мире.
Но, почему-то за всерьез озвученный такой способ оптимизации можно попасть в психушку.
Потому что есть еще критерий нанесения вреда. И это очень спорный вопрос, насколько причиняемый вред оправдан полученной пользой.
Я, например, считаю, что установленный исследователями факт о 60% не стоит даже лишней минуты потраченного времени разработчиков.
Сама выборка из нескольких патчей статистически бесполезна. Факт о том, что можно пропихнуть на код ревью фигню нисколько не интереснее того, что вода — мокрая.
ss-nopol
:) Забавный трюк, конечно, но я могу переформулировать и для таких зануд:
Количество cпасённых и есть целевая функция, которую мы оптимизируем.
Это неправда. Конечно, после того как это проделали, всем вдруг стало очевидно что вода мокрая. А раньше рассказывали что свободный софт безопасней по определению, потому что его каждый может проверить на наличие уязвимостей.
wataru
Уже усложняется задача, правда? А теперь дайте определение, кто считается "спасенным"? Мы можем долго играть в эту игру, но что бы вы не написали, я всегда найду более или менее вывернутое наизнанку извращенное решение оптимизационной задачи, пока ваша простая целевая функция не превратится в целую статью. Потому что все на самом деле сильно сложнее и слабо формализуемо.
Может быть вам — да. Но мне и многим другим это было очевидно до этого.
И это не изменилось нисколько. Уязвимости, таки, нашли. Если бы софт был закрытый, и там один из сотрудников шалил, то никто бы об этом так и не узнал.
ss-nopol
Пока усложнения никакого не вижу. Спасённым, очевидно считается тот, кто не погиб при пожаре. Для чего и проводится эвакуация.
Попробуйте конечно. Я не понимаю смысл этой игры для Вас, но готов поучаствовать в виде эксперимента.
Я не оспариваю тезис, что зачастую идею можно довести до идиотизма. Действительно это возможно. Но это не значит что не надо заниматься пожарной безопасностью и её проверкой.
Если проверка выявила слабости в защите, то она не может называться бесполезной. А она выявила!
Я как минимум не один. Поиск в гугле по фразе «why free software is more secure» выдаёт 3.330.000.000 results
Если софт закрытый, то им не присылают патчи.
wataru
Вводим специальные фермы, где рожают много-много детей, которые сразу же эфтанизируются (чтобы от пожара не погибнуть). Счетчик не погибших от пожара растет с бешенной скоростью. Вы тут можете возразить, что пожара-то не было, на что я вам отвечу, что фермы надо переодически сжигать, естественно, после эфтаназии. Не было бы геноцида детей на этих фермах — они бы сгорели заживо. Ну или более приземленный пример — большинство людей живут в клетках вдали от любых горючих материалов.
Тут другой тезис. Целевая функция не тривиальна. Нужно не только минимизировать количество погибших в пожаре людей, но при этом обычно нельзя совершать ради этого убийства (однако поджигателя в некоторых случаях можно и застрелить полицейскому), ограничивать свободы людей и много всяких других вариантов вреда.
В чем принципиальная разница присылания патча и вношения этого патча сотрудником?
ss-nopol
Пожар это незапланированное мероприятие. Но по сути я ответил ниже.
Она конечно нетривиальна при попытке её формализовать для оптимизации с помощью ИИ, но она абсолютно тривиальна для вменяемого человека. И Ваши примеры это ясно показывают. Так как ИИ мы не привлекаем, то не понимаю, как это может помочь в нашей дискуссии.
Очевидно по-моему? Патчи присылает множество абсолютно незнакомых людей (фактически анонимов) с неизвестной мотивацией, сотрудников мало и о них мы знаем почти всё.
wataru
И тут вы за этой тривиально понятной и не формализуемой метрикой понимаете только удобное вам в текущий момент. С одной стороны как бы понятно, что убивать людей ради сокращения жертв пожаров — плохо, и тут вы согласны. С другой стороны, когда (начало этой ветки) "телефонный террорист" помимо проверки эффективности эвакуации вызывает смерти ни в чем невиновных людей, это для вас нормально.
Ну, раз уж мы говорили о ядре линукса… что вы знаете о сотрудниках Майкрософт?
ss-nopol
При этом спасает в десятки раз больше людей. Об этом Вы почему-то забыли написать.
В данном случае имеется в виду, что их знают другие сотрудники Майкрософт, руководство — те кто собственно и отвечают за безопасность.
wataru
А как он их спасает? Пожара-то не было, был только телефонный звонок.
ss-nopol
Конечно, если выявленные проблемы не исправить, а «террориста» показательно наказать, то никак.
COKPOWEHEU
Надо. Но вред от таких «проверок» не должен превышать потенциальный вред от реального пожара.
Вот это в «эксперименте» и не выполняется: вред очевиден, а вот пользы ноль.
Угу. А еще шторы, возможно, гореть могут. Проверьте это в своей комнате. А что, проверка ведь не может называться бесполезной.
… с исправлениями найденных ошибок. Очевидно, вы хотели закончить мысль, но сбились.
ss-nopol
Вы противоречите условиям задачи. В моём сообщении было так:
и
Это общеизвестный факт. Безопасность свободного софта до недавнего времени — нет. Я уже написал в другой ветке:
Поиск в гугле по фразе «why free software is more secure» выдаёт 3.330.000.000 results
COKPOWEHEU
Авторы ведь не исправили существующие ошибки, а добавили свои.
Продолжая аналогию с пожаром, разбросали в разных местах огнеопасные материалы, испортили огнетушители и завалили хламом эвакуационные двери. А потом объявили тревогу.
Если это откровение для вас, не надо считать что все остальные тоже считают что пингвин ест радугу и так далее.
ss-nopol
По условиям задачи от проверки гибнет около 0.01%, то есть мы спасаем 0.099% процентов.
avost
Увеличение количества погибших — это точно НЕ про минимизацию в любом случае, а при наличии альтернатив, дающих не худший результат — тем более. Странно, что это приходится объяснять.
Внимательно прочтите вопрос. Вы отвечаете на что-то другое. Впрочем, можете обосновать какое количество найденных уязвимостей было внесено сознательно вот этим путём помимо этих мамкиных террористов.
Для проверки того, что можно убить несколько людей убьёте несколько людей? Ура, вы выяснили, что человеков можно убить!
Если вы его пишите — какая разница открытый он или закрытый?
Если вы его не пишите, ну заразите сеть вирусом-троянцем.
ss-nopol
Незнакомцы патчи не присылают
Am0ralist
И белые хакеры заранее оповещают админов, через какие дыры полезут?
Мне просто понимать, чем по вашему отличаются проверки реальной безопасности от проверки безопасности, по результатом которой нужно поставить галочка о том, что безопасность «ок»?
PS. То, что после проверки данные не были переданы или что-то сейчас пропихивалось — это другой вопрос, если что. Мне просто интересно, как можно проверять реальную безопасность не проверяя безопасность в реальности?
defaultvoice
Кто угодно может слать коммиты с университетского имейла. Они частенько продаются на ebay за мелкий прайс.
Линукс давно уже вышел за пределы операционки для энтузиастов, одна такая уязвимость в нужном месте и эксплойт к ней – и можно наварить миллионы долларов, скомпроментировав миллионы устройств начиная от дата-центров, заканчивая внутренними системами банков. В таких условиях, даже если кого-то там исключат из университета, обязательно найдётся тот, кто готов будет рискнуть.
astronom1
ментейнеры ядра правильность патчей проверяют или судят о качестве кода по крутизне мыла, с которого прислан патч?
AC130
Исследователи говорят что их коммиты никуда не пушились.
И тащемта опровержений этому утверждению нет. К примеру, этот мужик пишет про коммит от 6 апреля, что он мол сделан с плохими целями и они хотят чтобы статья прошла ревью, однако статья уже была принята на конференцию в декабре 2020 года.
Т.е. в итоге, ребята сделали статью, никакие коммиты, которые делались в рамках работы со статьёй, никуда не ушли. Через несколько месяцев этот мужик обнаружил статью, прочитал, у него немножко испортилось настроение, и он начал наезжать на ребят по поводу их текущей работы, что мол она как-то связана с тематикой этой статьи. Это может быть и так, да, возможно они продолжают работу; но доказательств у него нет, есть только косвенные улики. Т.е. в текущем виде это обострение паранойи на фоне вскрывшихся фактов трёхмесячной давности.
Их забанили не за это, их забанили за то, что этот мужик посчитал такое поведение неэтичным, и вместо жалобы в этическую комиссию университета решил считать что эта комиссия работает плохо, т.е. кто угодно может заниматься похожими по вреду экспериментами. Вам надо по рассылкам от этого мужика походить, там всё расписано.
merlin-vrn
Вот, вы и сами нашли то сообщение Jiri Kosina, о котором я сразу подумал. Вопрос теперь, а сколько там вредоносных коммитов от этой группы, которые ещё не обнаружены? Группа говорит, что таких нет, но вот этот коммит, а также упоротая реакция Aditya Pakki на справедливое замечание, что некоторые его коммиты — говно, несколько подрывает доверие ко всей этой группе.
А то, что университет допустил эксперимент над людьми, подрывает доверие к этической комиссии университета (см. сообщение Теодора Цо как раз об этом). К тому же, из сообщения Грега Кроа-Хартмана, где он пишет, мол, "мы жалуемся в ваш университет" (слово AGAIN он написал капсом), намекает, что в коммиссию они обращались, и что-то реакции не было (пока университет не забанили).
Osnovjansky
Данный аудит показал, что процесс — говно.
merlin-vrn
Это не аудит. Аудит согласовывают с руководством. Это хулиганство и есть попытка извлечь личную пользу в виде статьи, а хулиганы должны быть наказаны.
И, положим, процесс говно (нет)
(и покажите только сначала, где процесс "не говно", может, в университете Миннесоты, где эксперимент над людьми допустили без серьёзного анализа), а можно мне теперь линукс без багов и прочего мусора в виде остатков от ваших грязных экспериментов, пожалуйста?singalen
Двумя сообщениями ниже (болд мой):
ilammy
Accepted != merged and deployed.
Процесс экспримента подразумевал дождаться приёма патча на рассылке, а потом лично мейнтейнеру сказать, чтобы эти патчи никуда не ушли, потому что там намеренно посаженный баг.
wataru
В том же обсуждении:
Еще раз, была прошлая статья несколько месяцев назад, где исследователи утверждали, что они все откатывают, сами свои же баги исправляют до мерджа.
А теперь еще один студент того же профессора засылал множество мусорных патчей.
ilammy
“A lot of these” относится не к патчам с багами-бекдорами, а к патчам от группы исследователей в целом. Они не только плохие патчи, а и хорошие отправляли, которые можно и включить.
Грег откатывает патчи скопом по почтовому домену не потому, что они идут от мерзопакостных экспериментаторов и должны быть выжжены напалмом, а больше потому, что сразу нельзя сказать, какие из них нормальные, а какие всё же случайно пролезли и про них забыли — никто из исследователей не вёл исчерпывающего списка (а следовало бы). Так что в дело вступает один из принципов поддержки ядра: сомнительные патчи сначала откатываем, потом разбираемся.
wataru
Более того:
singalen
Если так, тогда приемлемо.
shnegs
А зачем проводить исследование на рабочей системе, которая должна уйти миллионам пользователей? Для этого есть стендовые сборки.
Это просто два пакостника, рожи бы им
начиститьосмотреть вблизи за такое…