Меня как давнего сторонника FOSS исключительно удручает то, что происходит в последние несколько лет с разными сообществами FOSS (за некоторым исключением, конечно).
Рассмотрим один из последних эпизодов в саге индустрии open source, которая понятия не имеет, что она делает в целом:
Это не какой-то уникальный случай. Скорее всего, в ваших зависимостях много других модулей, заброшенных авторами. Я писал этот код не ради альтруизма, а для развлечения. Я учился, а учиться весело. Я опубликовал его, потому что это было легко сделать и потому что обмен кодом тоже помогает учиться. Думаю, что большинство небольших модулей на npm созданы по тем же причинам. Однако это было очень давно. С тех пор я перешёл от этого модуля к другому, а потом ещё к одному, а сейчас в процессе перехода и от него. Я написал намного лучшие модули, чем этот, интернет просто не полностью догнал.
— @dominictarr, в заявлении о бэкдоре в библиотеке event-stream
TL;DR: Тарр отказался от поддержки своего популярного пакета для node.js. Ни один нормальный пользователь не захотел взять поддержку на себя, даже кто использовал библиотеку в своих проектах. Тарр передал пакет «полезному» незнакомцу, который сразу же монетизировал его с помощью кражи криптовалюты. Мнения публики разделились.
Наверное, у «полезного» незнакомца был удачный день. А вот для Тарра не очень. На которого свалилась куча дерьма со всего интернета за передачу пакета незнакомцу без проверки. Мне совершенно непонятно, как он мог осуществить передачу на 100% безопасным способом, но давайте предположим, что такое возможно.
Но это означает, что автор любого пакета или приложения FOSS после публикации его в интернете принимает на себя ответственность за любое неправомерное использование указанного программного обеспечения. Как минимум до тех пор, пока автор не сможет старательно и торжественно передать эту ответственность кому-то другому, словно горячую картошку.
Так, как это делается в корпоративном мире.
Такая логика быстро заводит нас в тупик, ведь публикация даже небольшого фрагмента кода становится невыгодной.
Проведём мысленный эксперимент. Предположим, что сам Тарр решил добавить новую «функцию» криптомайнера в свой собственный пакет. Чёрт, в конце концов, это всего лишь один из многих способов монетизации FOSS. Согласен, это будет нехорошо выглядеть в его резюме, но самое интересное, что такие действия полностью законны. Также не исключено, что если всё сделать правильно, никто долгое время ничего не заметит.
Так что это значит? Это значит, что в любой момент времени любой мейнтейнер FOSS может заменить свой код чем угодно, будь то криптомайнер или
console.log("ur mom, lol"), сделать его недоступным постоянно или только по вторникам и полнолуниям, а также, как и с любым имуществом, передать его кому-либо, не спрашивая вашего мнения.С другой стороны вы, продвинутый пользователь FOSS, наделённый властью бинарного копирования и четырьмя свободами GPL, говорите: «Ну что ж, не сегодня» и достаёте свою собственную, правильную копию программного обеспечения, вносите нужные изменения и дальше, если хотите, публикуете эту модифицированную версию кода.
Но ни у кого нет на это времени, верно? Нам ведь нужно выпускать какие-то модные новые веб-приложения. Нет времени читать весь код с 40 000 зависимостей, если у нас нет времени даже на свои модульные тесты. Нет, это мейнтейнеры FOSS должны придерживаться более высоких стандартов, чтобы мы больше им доверяли! Как они посмели на нас наплевать?!
Вот в чем дело:
FOSS никогда не говорил о доверии к мейнтейнерам.
Для начала не нужно было им доверять.
Код — единственное, чему вы можете доверять, если хотите знать, что делает программа, что происходит с бизнесом или почему ваша система — уже не та, что создавалась изначально.
Код — единственное, чему вы можете доверять. Не читая его, вы утратили самое важное преимущество этой экосистемы: возможность не доверять авторам в отношении поведения или неизменности кода.
Вы хотите бесплатно скачать тысячи строк полезного, но случайного кода из интернета, запустить его на производственном веб-сервере или, что ещё хуже, на машине вашего пользователя, доверить этому коду данные ваших платных пользователей — и наслаждаться успехом. Мы все такое любим. Но вы не хотите проверять лицензию и понимать программное обеспечение, на котором работаете, и по-прежнему обвиняете людей, которые обеспечивают ваш бизнес, когда случаются ошибки, не давая им ничего взамен? Это одновременно и некомпетентность, и ваше право.
Но как это отличается от использования несвободных программ? Если вы не собираетесь в полной мере использовать FOSS, может лучше потратить свои деньги на поддержку? По крайней мере, вы сможете жаловаться до посинения. Может, даже сможете подать на кого-то в суд!
Ваша система — это ваша ответственность, и вы обязаны своим пользователям, особенно если они платят. Эта ответственность не меняется, когда вы решаете взять чей-то код, чтобы не писать его самостоятельно, тем более бесплатно. Это не означает, что экосистема FOSS не выигрывает от высокой степени доверия (она это делает), однако она может работать и нормально работала без этой новой концепции доверия, потому что мы привыкли делать всё трудным способом: доверять путём проверки, изменения, а затем компиляции.
Я могу ошибаться, но в миллионах загрузок event-stream, а это 1500 зависимых пакетов, должно быть не менее пяти компаний, которые могли бы выделить 1 час разработчика в неделю на поддержку event-stream.
Де-факто проприетарный софт
Вот что меня огорчает больше всего.
Возможно, мы достигли этапа, когда FOSS больше не представляет собой то, что раньше, просто потому его слишком много. Слишком много строк кода, слишком много конкурирующих решений, слишком быстрая скорость изменений. Мы хотим, чтобы обновления безопасности поступали прямо из апстрима, но как мы будем проводить аудит каждую неделю?
В таких условиях не удивляет тот факт, что некоторые акценты смещаются в сторону доверия. Экосистема FOSS извлекает огромную пользу из прочной базы доверия, поскольку та позволяет распределить работу.
Но на самом деле это не доверие. В настоящее время это надежда и принятие желаемого за действительное.
Я использую много дистрибутивов Linux. Конечно, я не могу в одиночку проверить всё ядро, тем более весь остальной код, патчи и скрипты сборки для всех пакетов для всех этих дистрибутивов. Я провожу аудит только тех частей, которые меня больше всего интересуют, и я надеюсь, что: 1) мейнтейнеры дистрибутивов не действуют из зловредных побеждений; 2) если так, кто-нибудь другой проверит части, которые я не посмотрел; 3) если кого-то интересуют те же части, что и меня, он выловит баги, которые от меня ускользнули.
Это рисует мрачную картину будущего, когда количество строк кода или патчей намного опередит рост числа разработчиков и мейнтейнеров.
Как же этого избежать?
Аргументы в пользу понятного программного обеспечения
Мы должны упростить программное обеспечение. Сделать его намного проще. И компании, которые предлагают свои услуги на основе программного обеспечения с открытым исходным кодом, должны принимать более активное участие в поддержании этой экосистемы.
Вот ещё один мысленный эксперимент: может ли новый (но опытный) разработчик за 2 недели (80 часов) понять 80% кодовой базы, за которую он будет отвечать?
Если нет, то этот человек перегружен работой с первого дня, поскольку он по определению не сможет передать свои обязанности в течение стандартного для США периода времени. Если он уходит, вы никак не сможете подготовить замену в положенный срок. Как следствие, плавный переход невозможен, а некоторые знания о предметной области неизбежно будут потеряны.
Можете изменить указанные выше цифры для конкретных стран, но основная предпосылка остаётся неизменной. Ни в одной другой отрасли людям не позволяют работать с вещами, которые они не понимают, а тем более разрабатывать их.
Программное обеспечение должно быть понятным. Суть FOSS для сводится к одному фундаментальному праву: праву отказаться от выполнения на моих машинах кода, который я не имею возможности понять. Вот и всё.
Конечно, есть преимущества информационной безопасности, экономические выгоды и некоторые другие, которые я не могу вспомнить прямо сейчас. Но если вы пытаетесь доказать, что для онлайн-системы сдачи налоговой декларации моей страны нормально требовать Adobe Flash и передачи этого перегруженного непрозрачного блоба в мой браузер, то вы получите ответ «публичные деньги, публичный исходный код», с изумлением имея в виду «матерь божья, как вы дышите».
Я принципиально не против софта с закрытым исходным кодом, но только если он работает на чужом компьютере.
Однако мы видим, что наличия исходного кода недостаточно, чтобы гарантировать понятность. Поэтому крайне важно, чтобы индустрия ПО немного притормозила с фейерверком новых функций, а больше внимания уделила стабильности, безопасности, конфиденциальности пользователей и пониманию собственных систем, которые лежат в основе всего. Это абсолютный минимум, что может сделать ответственная компания, особенно если она с радостью берёт с людей деньги за свои «услуги».
И если упомянутые «услуги» основаны на FOSS от частных лиц, то рассмотрите возможность поддержки этих людей. В конце концов, они поддерживают вас. Они не могут пожаловаться, если вы их не поддерживаете, но и вы не можете жаловаться, когда что-то идёт не так.
Комментарии (122)
SerjPeleng
02.12.2018 22:02+1Если честно, то запуск на компьютере открытого и закрытого ПО сегодня почти ни чем с точки зрения безопасности не отличается… проверить запускаемый открытый код у большинства пользователей нет ни какой возможности… все проверки в реальности ложатся только на антивирусное ПО, которое, к сожалению, панацеей не является… поэтому ситуация описанная в начале статьи более чем возможна в любой момент с любой открытой программой… да, потом вредоносный код обнаружат, но и в закрытом ПО его потом обнаружат, только не поздно ли?
А вот вывод в конце статьи хорошо бы поддержать, авторам надо платить, тогда они будут поддерживать свое ПО в актуальном и работоспособном состоянии… но ведь многие ищут открытое ПО как раз для того, что бы за него не платить… короче, проблема стара как мир, коммунизм это идеальный строй, если где-то набрать 100% настоящих коммунистов… а ложка дёгтя, как известно, испортит бочку мёда…JustDont
02.12.2018 23:00+3авторам надо платить, тогда они будут поддерживать свое ПО в актуальном и работоспособном состоянии…
Это не работает в масштабе всей экосистемы. Авторам платного софта выгодно поддерживать «особенность» своего софта, чтоб повышать цену перехода (чтоб поменьше народа уходило, проще говоря). См. софт небольшой частной конторы под названием Microsoft.
То есть вот буквально: если всем будут платить за поддержку и актуальность — у всех появится соблазн к окукливанию, прямо пропорционально объему выплат.qw1
02.12.2018 23:19Окуклиться не даст лицензия, т.к. систему можно забрать у одного платного мейнтейнера и отдать другому.
JustDont
02.12.2018 23:25Um, нет. У вас не та семантика: систему может кто-нибудь забрать у платного мейнтейнера. Тут нет никакой божественной руки, которая бы забирала у окукливающихся и отдавала бы хорошим.
При этом забрать-то он может, а вот получить он с этого ничего на первое время не получит (а получит только тогда, когда достаточно вырастет в популярности, чтоб быть заметным). При этом у любого нового мейнтейнера при сравнимой популярности с прошлым — соблазн на окукливание будет всё точно такой же.qw1
02.12.2018 23:49Если объёмы выплат приличные, то передать проект другому мейнтейнеру сможет тот, кто платит, если его что-то перестало устраивать.
JustDont
02.12.2018 23:50А если речь про случай, когда есть конкретные «заказывающие музыку» — то это и сейчас так работает.
qw1
03.12.2018 00:11Не всегда. В случае с Microsoft сменить мейнтейнера нельзя.
А в случае с открытым софтом редко платят. И тут высказано мнение, что платить было бы неплохо. Другое дело, непонятно, как кооперироваться заказчикам. Если каждый будет платить своим мейнтейнерам, будет дорого.balexa
03.12.2018 12:09+1Не всегда. В случае с Microsoft сменить мейнтейнера нельзя.
А в случае с открытыми вещами? У вас есть возможность сменить мейнтейнера кубернетеса, скажем?qw1
03.12.2018 12:35В этом проекте есть какая-то специфика?
В общем случае, нужно сделать форк и назначить работника на зарплату, который будет проверять патчи из апстрима и мержить в этот форк, ну и своё что-то дописывать, возможно. Таким образом, для конкретного заказчика, этот работник станет мейнтейнером.balexa
03.12.2018 13:06Вы сейчас теоретизируете, или про реальную практику говорите?
В теории конечно все легко — надо просто нанять человека/команду, который форкнет линукс, кубернетес, Jboss, сам будет для вас мейнтейнить форк, исправлять баги, и накатывать патчи. Вы в реальности такое хоть раз видели?
На практике у вас есть опыт, как кто-то использовал стороннего мейнтейнера для открытого софта? Конкретно например редхат сложно чем-то заменить, да и своих работников держать выйдет сильно дороже. Принципиальной разницы с майкрософтом не вижу.Deerenaros
03.12.2018 14:23Даже хуже. FOSS идёт AS IS, тогда как у мелокомягких есть лицензия в которой чёрной по белому (или зелёным по чёрному, зависит от) написаны права и обязанности сторон, причём обязанностей у мелкомягких не мало. А для корпоративных клиентов с поддержкой обязаности значительно вырастают.
Собственно, сейчас в стане свободного софта происходят не очень приятные вещи. Пока он был где-то там, уделом тру гиков всё было хорошо, но… Гик культура стала модной, интерес к свободному ПО возрос катастрофически и саморегулирующее общество поползо в анархию. Этого следовало ожидать, но никто не ожидал.
Очень грустно это наблюдать, просто очень. История с leftpad это лишь вишенка на торте на острие айсберга, проблема настолько глубокая, что исправить что-то будет очень тяжело. Какие-то проекты, конечно, встанут под крыло Microsoft, Google, Mozilla, Canonical, но на всех не хватит и чёрт его знает, что будет дальше. Надеюсь лишь, что интерес к гик культуре поутихнет, схлопнется и все отстанут от опен сорса. Хочу, чтобы снова линуксом пользовались от силы 1% пользователей!
Hardcoin
03.12.2018 14:42В случае рэдхат замена мантейнера, условно, миллиард. В случае майкрософта — условно сто миллиардов. Для обычного пользователя и то и другое — невозможная сумма, а значит и разницы нет. Для страны, например, или транснациональной корпорации — это как раз принципиальная разница.
С кибернетисом аналогично. Есть потенциальная возможность заменить, некоторые заказчики могут это потянуть при необходимости.
balexa
03.12.2018 15:17+1Ок, принимается, как аргумент. Спорный на мой взгляд и притянутый за уши, но ок.
И тем не менее, я таких случае не знаю. Не поделитесь? Принципиальная возможность то есть, но это сродни анекдоту.
Ну и во вторых, почему — заменить майкрософт дешевле. Достаточно перейти на OSS целиком. Это явно займет меньше ста миллиардов. Это будет даже дешевле чем форкать линукс.
qw1
03.12.2018 17:40На практике я сам делал форк десктопного приложения размером проекта в 120.000 строк. За несколько месяцев разобрался. Мержил фичи из основной ветки и успешно добавлял много чего нового своего. Даже какое-то сообщество юзеров появилось с беклогом на 100500 новых хотелок. Потом надоело и я забил.
DaylightIsBurning
03.12.2018 19:22+2В некотором смысле, это произошло с OpenOffice=>LibreOffice, WebKit=>Blink, Owncloud=>Nextcloud, MooseFS=>Lizardfs, Oracle ZFS=>OpenZFS и т.д. Более мелкие проекты нередко форкаются, и затем бывает даже форк выживает, а оригинальный проект чахнет, или сосуществуют параллельно.
qw1
03.12.2018 20:30форк выживает, а оригинальный проект чахнет, или сосуществуют параллельно
Например,
AdBlock > AdBlock Plus
Request Policy > Request Policy Continued.
SerjPeleng
03.12.2018 14:27банально, но программисты хотят кушать… многие из открытых и свободных программ вышли бы на более высокий уровень, если бы делались и поддерживались не в редкие свободные часы, а в нормальное оплачиваемое рабочее время…
Self_Perfection
02.12.2018 23:51+1А помните Алан Кей делал STEPS? Средой в 20000 строк кода. Операционная система, текстовый редактор, браузер, всё-всё в сумме в 20000 строк кода.
Пусть и невозможно вписаться в столько жёсткие ограничения с реализацией всего желаемого, всё равно кажется, что возможно основательно снизить сложность нашего софта.qw1
03.12.2018 00:15+1Хорошо, когда у системы один автор и один пользователь, который точно знает, что хочет, а что ему точно не нужно.
amarao
03.12.2018 17:03Они в 20000 строк кода могли рендерить улыбающиеся какашки с кодом «светлая кожа» и направлением письма справа налево? И privacy extensions в ipv6? И всё это в 20к строк? Не верю.
Pilat
03.12.2018 02:20-2Один из вариантов — реализовать общий набор библиотек на все случаи жизни и реализовать его на всех языках. Это позволит упростить тестирование, позволит более-менее точно автоматически определять что делает программа, ускорит вникание в программный код. Все программы, которые не пользуются таким набором библиотек, помечать как небезопасные. Наверно, другого пути и нет. Пора отойти от программирования как искусства к программированию как ремесло.
netricks
03.12.2018 11:07Нельзя не отметить, что нет особой разницы между программой, использующей стандартные либы и программой использующей сторонние библиотеки, использующие стандартные либы. Вы все равно запускаете на машине пользователя код, которому пользователь не может доверять.
Впрочем, стандартизация библиотек идет полным ходом, что обусловленно нормальным эволюционным процессом. Думаю, еще лет двадцать и стандартный набор будет.
qw1
03.12.2018 11:07Берите выше — давайте напишем общий набор программ на все случаи жизни. Хорошо их отладим, документируем, и программисты больше не будут нужны никогда!
VolCh
03.12.2018 12:02Кто помешает один раз дёрнуть библиотеку для галочки (а то и не дергать, если проверка будет просто по наличию в зависимостях), а дальше использовать что-то своё?
Это только в дополнение к предыдущим комментариям.
Pilat
03.12.2018 13:03А кто мешает запускать автоматическую проверку при каждом изменении? Если это стандартные библиотеки, то проверка быстрая и объективная.
Стандартные библиотеки — это ассемблер высокого уровня. Антивирусные компании давно научились делать выводы о наличии вирусов по коду, даже их наработок десятилетней-двадцатилетней давности может хватить, даже не учитывая нынешнего развития в области ИИ.VolCh
03.12.2018 13:08Проверку на что? На то, что программа использует минимальный набор каких-то библиотек?
Pilat
03.12.2018 13:11Проверку на то, что программа делает только то что заявлено в её профиле.
Hardcoin
03.12.2018 14:56+1Мешает отсутствие возможности такой универсальной проверки. Можете погуглить "Проблема останова".
Pilat
03.12.2018 15:10-2Эта задача уже решена практически. Это эвристический метод поиска вирусов. Начали его использовать лет 20 назад. И препятствие к реализации — именно разнообразие апи и системных вызовов. Если их стандартизировать, проблема упрощается.
Hardcoin
03.12.2018 15:13+1Нет, не решена. Поиск вирусов на 95% идёт по сигнатурам. Это абсолютно другое и никак не мешает создать вирус, который не ловится (до следующего обновления сигнатур).
Alexeyslav
03.12.2018 16:28-1И это хорошо. Поиск по сигнатурам энергетически менее затратный. Нашли вирус по сигнатуре — не надо тратится на более развёрнутый анализ. Кроме сигнатур у антивирусов есть ещё и белые списки заранее проверенных программ, на которые они не тратят свои ресурсы а через анализ проходят только редкие программы сигнатуры которых неизвестны или программы из белого списка у которых не сходится контрольная сумма, просрочена подпись и т.д.
qw1
03.12.2018 17:51Проверку на то, что программа делает только то что заявлено в её профиле.
А как сделать проверку, что программа правильно делает то, что заявлено? Достаточно удалить одну строчку, которая обрабатывает какой-нибудь граничный случай, и в программе появляется уязвимость. И никакая эвристика ничего не найдёт, если только не была запрограммирована специально на эту ситуацию. То есть, анализатор должен знать предметную область.
VolCh
04.12.2018 13:41Что может быть? Отправка сетевых запросов, чтение с диска — такого плана заявления?
Pilat
04.12.2018 14:22Ну да. Правда, Вы перечислили только низкоуровневые операции, я же писал о высокоуровневых. Доступ к реестру, выполнение HTTP запросов, системные вызовы, запуск вычислительных подзадач. Например, типовому приложению доступ к сети вообще не нужен, нужен доступ к конкретной базе данных или внешним сервисам типа фейсбука. Если есть любой вызов сетевой библиотеки — значит приложение взломано.
Alexeyslav
04.12.2018 14:56В виндовс это так не сработает, приложению может и не нужен доступ к сети а вот подключенной библиотеке — нужен, и одна из таких библиотек системных — это работа с файлами, и нужна ей сеть только для того чтобы иметь возможность работать с сетевыми дисками и сетевым окружением. Всё точка — любому приложению уже потенциально нужна сеть…
Pilat
04.12.2018 15:11Вот библиотека и будет иметь доступ к сети, а в исходных текстах приложения не будет вызова процедур доступа к сети. В этом и вся идея.
qw1
04.12.2018 15:15Это дырявая идея, т.к. приложения, манипулируя библиотекой, сможет без проблем справить все свои грязные делишки её кодом. Просто немного надо под другим углом посмотреть. Надо перезаписать файл? Настраиваем доверенную библиотеку логирования на вывод в нужный файл, отключаем печать префиксов/заголовков (чтобы в файл ничего лишнего не попало), и пишем всё что нужно в какой нужно файл.
Pilat
04.12.2018 15:20Это не дырявая идея, а обычный мандатный доступ.
qw1
04.12.2018 15:39Разграничение будет работать только со специально написанными библиотеками, которые не доверяют приложению и полностью перепроверяют все параметры, сверяя их с текущими разрешениями (может ли это приложение писать в этот файл? а в другой файл? библиотека-то может). Всё это даст немалые накладные расходы и сильно усложнит библиотеки.
Alexeyslav
04.12.2018 15:46Тогда это должна быть не библиотека а сервис. Иначе… ничто не остановит приложение от прямой записи в данные библиотеки, она под полным контролем приложения.
Pilat
04.12.2018 15:49Нет, анализ делается исключительно исходных кодов, не во время выполнения. То есть, например, принимая новую версию кода, GitHub запускает проверку и помечает эту версию как безопасную. Делается это один раз.
qw1
04.12.2018 16:59Как он это сделает? Допустим, внутри библиотеки есть запись в файл. Узнать, как формируется имя файла, и не будет ли происходить опасная перезапись данных — алгоритмически неразрешимая задача, равная задаче останова алгоритма.
Alexeyslav
04.12.2018 15:33Для системы библиотека это часть приложения, и она не сможет отличить вызов функции АПИ сделан от приложения или библиотеки. Сверять функциональность на уровне исходных кодов? Это бред… и не для всех программ есть исходные коды, не все бинарники собраны из тех исходников которые вы видите, многие программы обфусцированы, это же какой нужен мощный анализатор чтобы это всё «пробить»?
Ведь можно сделать куда проще(что и сделано!) — цифровая подпись и доверие производителю. ЦП можно отозвать, если и будут инценденты — они будут носить единичных характер. Всё, тупая ЦП решает проблемы вмешательства в код приложения, а репутация производителя и его ответственность — проблему встраивания зловреда на этапе сборки/проектирования. И не нужны какие-то сложные анализаторы учитывающие всё-на-свете но всеравно остающиеся дырявыми.Pilat
04.12.2018 15:42В ДАННОЙ статье идёт речь о программах с исходным кодом, а не о коне в вакууме. Бред — это расширять в дискуссии заявленную тему.
Alexeyslav
04.12.2018 15:51Увы, и даже это не работает на уровне исходного кода так как хотелось бы. Одна возможность вызывать процедуры неявно ставит крест на таких проверках. Непосредственного вызова процедуры может и не быть, просто код изменит адрес указателя на нужную процедуру и осуществит вызов по указателю. Эти ситуации анализатору будет очень трудно отслеживать, особенно если подстановка адреса будет зависеть от двух и даже трёх контекстов.
Pilat
04.12.2018 16:47В общем да, и более того — если код будет вычислять имя процедуры в языках где это возможно, например в Perl. Варианты — отказаться от таких языков или писать без самомодифицирующегося кода. Об опасности кода, который создаёт сам себя, пишется с самого начала эпохи программирования.
qw1
04.12.2018 17:03Это сразу ставит крест на всех нативных языках (не запускающихся в виртуальных машинах). А для виртуальных машин проблема просто сдвигается на другой уровень: пишем на VM интерпретатор, и интерпретируемый код меняет себя как данные. Или надо банить всё, что хоть отдалённо напоминает интерпретатор?
Pilat
04.12.2018 17:47Банить надо приложения, которые пытаются получить возможность делать то что не должны. Например получив пароль из мозиллы, прочитав sqlite файл какой-нибудь, приложение не должно иметь возможности передать его по сети. Или иметь доступ к сети, но не иметь доступа к файловым операциям. Такие ограничения покроют очень большой класс приложений и библиотек. Та же библиотека очередей, о которой идёт речь, не должна была иметь доступа к функциям чтения файлов.
(Доступ к данным можно ограничить разными способами, но кроме ограничения области, в которой можно открывать файлы, особо ничего не придумать. В линуксе этим занимается например firejail. Поэтому если открыть приложению доступ к файлам, надо либо обеспечить невозможность передать информацию на сторону — что сложно, либо ограничить область доступности.)NeuroHunter
04.12.2018 18:04А как быть с приложениями (а точнее — библиотеками), которые должны одновременно получать доступ к ФС и к сети (с потолка взятый пример — отправка крэшрепортов разработчику)?
VolCh
04.12.2018 18:15Утилита синхронизации типа rsync — куда лучший пример. Её прямая задача прочитать файлы с диска, причём практически с любого каталога и отправить по сети на произвольный хост.
Pilat
04.12.2018 18:23Про крэшрепорт пример неудачный — это само по себе опасное действие.
Приложения, которые одновременно и по сети и по файловой системе принято класть в firejail/chroot или ограничивать как-то иначе. Вообще приложениям доступ к файловой системе не нужен вообще либо нужен очень ограниченный доступ в пределах разрешённой зоны. То же с библиотеками.
Никто и не обещал что всё будет просто.VolCh
04.12.2018 18:34Какая разрешенная зона у файлового менеджера с возможностью подключения к удалённым машинам по различным протоколам, запущенного с правами суперадмина? Всё или почти всё!
Pilat
04.12.2018 20:02Проблема всё-таки не просто у какого-то файлового менеджера, а у библиотеки, которая при сборке файлового менеджера скачивается автоматом с гитхаба и линкуется. Именно эта библиотека не должна лазить куда не надо, в ней не должно быть таких вызовов вообще.
Alexeyslav
05.12.2018 12:53Такая вещь как сетевая папка ломает всю малину. Приложение которое может открыть файл неявно использует и доступ к сети. Но вроде бы этот момент как-то решён встроенным фаерволом — можно разрешить программе трафик в локальную сеть, но запретить интернет.
NeuroHunter
05.12.2018 13:17А если эта сетевая папка подключена по WebDav? WebDav может быть и не в локальной сети.
qw1
04.12.2018 18:26Банить надо приложения, которые пытаются получить возможность делать то что не должны
И это опять неформализуемый критерий, что возвращает нас к ручной проверке всех исходников.
Доступ к данным можно ограничить разными способами. В линуксе этим занимается например firejail
Можно, но это другой класс решений, нежели проверка библиотек, с которыми линкуется наш проект.Pilat
04.12.2018 20:40Всё верно. Но менеджер очередей, который вдруг начал воровать пароли, контроль вызовов библиотечных функций отследит — потому что он вообще не должен читать ничего с диска.
qw1
04.12.2018 21:05Контроль в рантайме или контроль при компиляции? При компиляции программа включает 100500 ненужных зависимостей. Тут, например, упоминали, что компилятор тянет mshtml.dll — ключевой компонент от Internet Explorer. Это не запретить, не погружаясь глубоко во все исходники.
Pilat
04.12.2018 21:48+1qw1
05.12.2018 00:23Это вы описываете работающую фичу или ваши пожелания?
Pilat
05.12.2018 02:32+1Пожелания. Начинаются они тут
qw1
05.12.2018 11:54А вам все пытаются объяснить, что это невозможно. Как проверка кода невозможна без полноценного ИИ, так и нельзя заранее создать библиотеки на все случаи жизни.
Pilat
05.12.2018 12:25А я вам всё пытаюсь объяснить что возможно и без ИИ и уже есть и работает. А вы всё как в танке. И даже если привлекать искусственный интеллект — почему нет? ИИ это вообще громкий термин, то что сейчас называют ИИ интеллектом не является, но в определённых областях работает.
Насчёт библиотек — возможно, это вообще неизбежный процесс. Вы думаете, поддержка софта в нынешнем виде это вообще нормально? Когда приходится раз в несколько лет менять методики программирования и изучать новые технологии. Унификация происходит постепенно.
И хорошо бы увидеть ваше решение проблемы.qw1
05.12.2018 14:15я вам всё пытаюсь объяснить что возможно и без ИИ и уже есть и работает. А вы всё как в танке
Так покажите пальцем, где это работает.
Вы думаете, поддержка софта в нынешнем виде это вообще нормально? Когда приходится раз в несколько лет менять методики программирования и изучать новые технологии
Нормально, потому что меняются ожидания юзеров от информационных систем. Раньше им нормально было с перфокартами работать, потом с текстовыми консолями, затем с графическими приложениями, сейчас уже хотят, чтобы через всё работало через браузер, завтра захотят VR. Как тут обойтись однажды сделанными библиотеками?
И даже если привлекать искусственный интеллект — почему нет? ИИ это вообще громкий термин, то что сейчас называют ИИ интеллектом не является, но в определённых областях работает.
Именно, что для этой задачи нужен полноценный, сильный ИИ, а не то, что сейчас им называют. А такого нет ни у кого.
qw1
05.12.2018 14:17И хорошо бы увидеть ваше решение проблемы.
Решение проблемы — экономическое. Хотите надёжность — платите за аудит всего кода, как за атомный авианосец. Хотите за 3 копейки — примите риски, что все ваши данные могут рухнуть (делайте бекапы).
Alexeyslav
05.12.2018 14:25Боюсь, что это будет сложно назвать рабочим решением. Оно наверняка имеет массу ограничений по области применения чтобы гарантировать надёжную защиту. А то получится как всегда — железная титановая дверь, супернавороченный невзламываемый замок и ключ от него под ковриком… ну а что, вдруг потеряю его если носить с собой буду.
К сожалению, класс подобных проблем может быть решён только в частных случаях. Те же виртуальные методы в языках, возможность на лету переназначить процедуру-обработчик и вся схема проверки летит к чертям.Pilat
05.12.2018 15:27Если применить в промышленном масштабе — то будет работать.
Если для доступа к файлам есть набор апи, то никакие виртуальные методы не пройдут мимо этого апи. Либо оно используется, либо нет. Это не замок, это набор свойств, что-то вроде списка затребованных интерфейсов.
Одна из реализаций: приложение или функция (часть библиотеки) перед выполнением требует адреса методов для доступа к сети, дискам, памяти и т.д. Не имея доступа к методам, оно просто не сможет получить такой доступ. Соответственно можно сравнивать списки запрошенных методов и список методов, которые приложение зарегистрировало для себя. Это даже не потребует анализа исходных кодов, это защитит от генерации кода на лету, это просто реализовать.
Другая реализация: приложение вызывает только функции в явном виде. Статический анализ эти функции отслеживает и сравнивает со списком разрешённых. Тот же эффект — несовпадение списков означает что приложение делает не то что надо.
Действительно, все проблемы это не решит, но решит очень многие. Решит проблемы всех библиотек, которым не нужен файловый доступ и не нужна сеть — процентов 99 библиотек наверно будет. Остальные надо как-то иначе проверять.Alexeyslav
05.12.2018 16:26Я же и говорю что применимо это только к частным случаям. А достаточно одной дырки чтобы разрушить всё здание.
Очередная утопия.Pilat
05.12.2018 16:38Если покрытие 99% — то это не такая и дырка. Сейчас ведь любой nodejs или руби / питон проект тащит с гита или охожих складов кучу либ, и именно через них не первый раз встраивают бэкдоры. Минимальными усилиями можно с этим более-менее бороться. Это возможно даже сейчас, автоматически анализируя внесённые исправления в какую-нибудь эталонную версию. А введя общую систему библиотечных вызовов высокого уровня будет совсем просто. Какими то жертвами, конечно, типа запрета лазить в системные функции.
alsii
04.12.2018 19:16+1Исходный код не дает никаких гарантий, если вы не доверяете компилятору. И даже исходный код компилятора не дает гарантий, если вы не доверяете компилятору, которым компилируете компилятор.
Pilat
04.12.2018 20:08Есть какие-то разумные допущения, которыми надо пользоваться. Если мы не доверяем компилятору, то почему мы доверяем процессору или монитору? Отсутствие в исходниках обращения к ресурсу, если это можно проверять, потребует от компилятора чудесного поведения чтобы этот доступ появился. Речь не о уязвимостях, а о использовании сторонней библиотеки, контролировать которую мы не можем. Тут не поможет даже виртуальная машина — приложение, работающее с кошельком, и взломанная библиотека работают в одном пространстве. Единственный вариант кроме ручной проверки изменений — это какая-то автоматизация.
VolCh
05.12.2018 08:19Не понятен даже предмет автоматизации. Вот есть у меня библиотека — ООП обёртка над процедурными файловыми операциями. Над любыми файлами, если процесс имеет права администратора. Что в ней проверять? Что она работает только с файлами? Но в Линуксе всё файл.
Pilat
05.12.2018 09:02Значит ваша ООП библиотека имеет признак «может работать с файлами» и появление в ней файловых операций не вызовет проблем. У библиотеки «event-queue» или «regexp» такого признака не будет, поэтому как только в её исходниках появляются файловые операции, это служит признаком наличия закладок. Файлы, сеть и вообще ресурсы кроме процессора и памяти нужны очень ограниченному числу библиотек.
qw1
05.12.2018 11:57В линуксе можно выполнить сетевое взаимодействие (отправить данные в сеть), записав в специальный файл /dev/udp.
Pilat
05.12.2018 12:33При чём тут /dev/udp и линукс ??? Я пишу о том что всё взаимодействие должно быть через библиотеки, вы пишете что можно обойти. Да, сейчас можно. Я предлагаю сделать чтобы было нельзя.
vassabi
05.12.2018 13:38+1давайте на простой аналогии: «Вам говорят, что в решете воду не носят и показывают на примере — как она легко вытекает.
А вы предлагаете сделать такое решето, чтобы было нельзя воде вытекать.»
так понятно?Pilat
05.12.2018 13:58-1Вы хотите носить воду в решете и жалуетесь что вода вытекает. Вам говорят — возьмите ведро. Вы говорите — вот я взял ведро сделал в дне дырки всё равно вытекает — ваш совет неправильный.
Вот это точная аналогия. Так понятно?qw1
05.12.2018 14:20Не понятно. Запреты некоторых функций — это решето. Что у вас ведро, вы не говорите. Как его реализовать — неизвестно.
qw1
05.12.2018 14:18+1При чём тут /dev/udp и линукс
Вы пишете, что у библиотеке, которая работает с файлами, не должно быть доступа в сеть. Я отвечаю, что это нереально проверить, т.к. через файлы можно стучаться в сеть.Я предлагаю сделать чтобы было нельзя.
Техническое решение заключается в чём? Пока это декларация на уровне анекдота «зайчики, станьте ёжиками».Pilat
05.12.2018 15:01-1Техническое решение тривиально для программиста и недоступно для обычного пользователя клавиатуры.
i0000
05.12.2018 14:39+1И как же вы гуглодроидом пользуетесь, когда там каждое приложение, начиная от обычного блокнота (утрирую, но видел сходное по функциональности приложение, то есть то, где это было бы совсем не в тему… не помню уже название, но требовало покупок в маркете), требует всех разрешений, от рыться в списке контактов до покупок в маркете.
poznawatel
03.12.2018 06:02А первопричина проблем — отказ от Unix way в пользу яйцекладущих шерстемолочных свиней…
Надоели, значит, безошибочные, используемые десятилетиями утилиты? Ну-ну.
antirek
03.12.2018 08:17github.com начал уведомлять о том, что те или иные пакеты скомпрометированы, npm audit показывает те имеющиеся проблемы. поэтому проверяй и все будет ок. второй момент, что как узнавать, что в новой версии пакета есть зловред? как раз при переходе с версии на версию необходимо немного посматривать код и в случае каких-то даже подозрений и непонятностей — сообщать сообществу для совместной проверки. возможно, мы в будущем будем платить фондам и компаниям за проверку на безопасность пакетов.
GreedyIvan
03.12.2018 08:25Так сравнение версий исходного кода не поможет, так как бинарники или минифицированные версии могут быть немного не тем, что получается из исходников. А любовь к использованию готовых сборок идет ещё со времен jQuery.
VolCh
03.12.2018 12:03При обновлении делать свой билд и сравнивать с предоставляемой сборкой. Один раз.
klirichek
03.12.2018 11:05Раньше разница между открытым и закрытым кодом была качественной.
А нынче открытый код во многом настолько обфусцировался (тоннами зависимостей, кривым стилем и т.д.), что зачастую дизассемблер после его компиляции оказывается лаконичнее и понятнее, чем многочисленные "слои" исходников.
VolCh
03.12.2018 11:58Вот ещё один мысленный эксперимент: может ли новый (но опытный) разработчик за 2 недели (80 часов) понять 80% кодовой базы, за которую он будет отвечать?
Если нет, то этот человек перегружен работой с первого дня, поскольку он по определению не сможет передать свои обязанности в течение стандартного для США периода времени. Если он уходит, вы никак не сможете подготовить замену в положенный срок. Как следствие, плавный переход невозможен, а некоторые знания о предметной области неизбежно будут потеряны.Не очень корректный эксперимент: понимать кодовую базу с нуля без посторонней помощи и понимать кодовую базу с помощью того, кто длительное время за неё отвечал, а то и сам писал почти всю — две большие разницы даже в случае прекрасной документации. Собственно для этого и даётся эти две недели прежде всего, как по мне — для передачи дел прежде всего.
Hardcoin
03.12.2018 15:01без посторонней помощи
Об этом речь не идёт. Наоборот, вопрос — сможет ли он при поддержке увольняющегося за две недели понять?
По мнению автора (тут я с ним согласен) — за две недели успеть не получится. Придется потом миллион тонкостей догонять самому.
johnfound
03.12.2018 12:32Я много раз писал. Но еще раз напишу. Приходит эпоха оптимизации ПО. Оптимизации скорости, размера, понятности и т.д.
Все чаще будем читать подобные статьи.
qw1
03.12.2018 12:42Все чаще будем читать подобные статьи
Для прихода эпохи нужно, чтобы не статьи появлялись, а сервисы массово появлялись такие, что не жрут по 300 МБ в браузере. И софт, помещающийся на дискетку.johnfound
03.12.2018 12:56Ну я же в роли пророка выступаю. К тому же, в начале всегда слово, а дело потом. ;)
Так что будет! Все будет.
amarao
03.12.2018 17:01Ждём, когда rust станет Big. Чистота и строгость в системном языке должна мультиплицироваться дальше по стеку. Но пока что node на C++, python на C, linux и libc на С, etс.
vassabi
03.12.2018 12:58разве что оптимизации обывательского мышления — особенно когда лозунгами и кликбейтными заголовками бросаться («аааа! все пропало!»).
Jekcep
03.12.2018 13:09Думаю чтобы как-то решить проблему использования стороннего кода, нужна поддержка изоляции выполнения этого стороннего кода на уровне языка, операционной системы и может быть процессора. Что-то вроде вызова сторонней функции в контейнере. Допустим что мне нужна какая-то простая функция из сторонней библиотеки, непосредственно принимающая на вход массив данных и возвращающая массив данных. Так вот я бы хотел, запуская ее, быть уверен, что она не получит доступа к другим данным моей программы, не получит доступ к данным других программ, не будет иметь доступ ни к чему в моей файловой системе, и не сможет сделать сетевых вызовов.
Может кто-нибудь знает язык где возможно провернуть такое? Возможно ли это с текущими архитектурами ОС и процессоров?fukkit
03.12.2018 15:04Да, легко.
Оформляйте свою функцию отдельным процессом, режьте ему доступ на уровне системы, взаимодействуйте любым IPC, от разделяемой памяти и сокетов до REST API.
Заодно модульность повысите и подумаете не раз, так ли нужен вам очередной «leftpad» в зависимостях и с такими бубнами, или можно обойтись приватнымвелосипедомдоверенным решением.
potan
03.12.2018 19:15Большую часть проблем можно решить типизацией, что бы модуль не мог ни чего сделать, что не прописано в интерфейсе.
qw1
03.12.2018 20:32+1На каком языке программирования это возможно?
potan
04.12.2018 00:25-1Практически любой хорошо типизированный, возможно, с урезанной стандартной библиотекой. JVM и .NET это более-менее сразу могут. Elm и Purescript, если обойтись без js-зависимостей тоже вролне изолируют модуль.
qw1
04.12.2018 10:09.NET сразу из коробки может запретить использовать System.IO?
mayorovp
04.12.2018 10:19+2Да, такая возможность предусматривается. How to: Run Partially Trusted Code in a Sandbox
Но типизация тут ни при чем. К тому же, ЕМНИП, эту песочницу уже несколько раз ломали.
qw1
04.12.2018 11:58Это другое. Можно любой код запустить в песочнице (хоть си-шный, хоть js). Всё равно получается оверхед, в данном случае на передачу данных через AppDomain.
Вопрос тут обсуждается, как проверить, что код не делает вредную активность, а не как блокировать эту активность.
potan
04.12.2018 13:36Я с .NET не работал, но вроде там был аналог JVMного менеджера безопасности.
По крайней мере байткод не очень сложно проверить на отсутствие вызовов опасных библиотек и использование рефлекшена.qw1
04.12.2018 14:10Проверить можно, но придётся отсечь все готовые библиотеки и новые принимать с большим трудом (выйдет не проще, чем всё отсматривать вручную).
Потому как в большом проекте найдётся пара мест, где пишется в файлы, например, для логирования. Доверять библиотекам-логерам тоже нельзя, потому что их можно переконфигурировать на запись в какой-то важный файл (например, в соседний, уже проверенный файл исходника записать небезопасный код), а не только во временную папку.potan
04.12.2018 14:27Сторонним библиотекам ни к чему давать возможность преконфигурировать логгер.
qw1
04.12.2018 15:13Берём любую развитую библиотеку логирования (я рассматриваю log4net). И, внезапно, там несколько способом конфигурации: атрибутами, через app/web.config, и кодом, с полным доступом ко всем фичам.
Я к тому, что с таким подходом придётся выкинуть все библиотеки и начинать принимать только специальным образом написанные, «доверенные». Что есть нереалистично. Может, тогда заодно формальную верификацию потребуем, раз уж всё равно всё с нуля.
Arranticus
04.12.2018 15:24В .Net можно выполнить код во временно созданном домене, для которого можно настроить ограниченные права. Штатными средствами домены не могут получить доступ к данным друг друга (взаимодействие организовано почти как между процессами). Правда, с этой целью я ими не пользовался, могу в чём-то ошибаться. Но для безопасного подключения плагинов это используется, насколько мне известно.
amarao
03.12.2018 16:59Любая просьба «прекратите писать новые фичи» напоминает просьбу фермера «не стройте новых заводов». Ответ — «нет».
А вот что делать? Если бы можно было сказать простой ответ… Их нет. Есть робкие попытки поправить core инфраструктуру (например, недавно libsvg перешёл на версию, переписанную на расте, и это big fucking deal, потому что от неё зависят 100500 приложений, так что во многих приложениях, наверное, работа с svg станет чуть лучше и чуть надёжнее), но у нас огромные пласты легаси-кода, которые шуршат даже в shiny new версиях софта.
Систему ПО невозможно контролировать целиком, надо доверять. Компиляторы и ОС, на которых эти компиляторы работают, среды исполнения и сборки, ОС на которой софт работает…
Просто верьте. И да, читать Документацию (aka исходный текст) иногда нужно и полезно. Есть робкая надежда, что читающих достаточно много.
Вторая важная вещь — мы можем это всё увидеть, то есть хотя бы аудит проводить легко и без всяких мрачных NDA.
potan
03.12.2018 17:05В идеале, пакеты должны быть изолированы и не иметь возможности залезть в потроха других пакетов иначе как через публичный интерфейс и явно переданные объекты.
Понятно, почему Elm предпочитает принимать написанные целиком на нем пакеты, а не биндинги к js.vassabi
03.12.2018 21:51В идеале, пакеты должны быть изолированы и не иметь возможности залезть в потроха других пакетов иначе как через публичный интерфейс и явно переданные объекты.
увы, эти идеалы разбиваются о банальный: «какая потом будет скорость итогового приложения ?»…
qw1
На что рассчитывает автор? Наивно думать, что все немедленно остановят эту гонку за новыми фичами и просроченными делайнами. Да, есть риск. Но если его попытаться нейтрализовать, проверяя весь открытый софт, то просто ничего не успеешь.
AlexanderS
Автор просто задумывается — во что выльется текущая тенденция положения дел. И резонно указывает, что тезис «открытый код = безопасный код» уже несколько не тот, что подразумевалось раньше. И что будет дальше не очень понятно, ведь прогресс не остановишь. Да, притормозить его было бы может и неплохо. Не остановить, а просто снизить темпы. Но мне сложно представить как это сделать в современных рыночных условиях.
Fracta1L
Надо нейросети натаскивать на проверку кода
qw1
Чтобы получить ответ: «код — говно, но почему — не скажу».
BigBeaver
«Сам знаешь, почему, странно, что ты ждал другого»?=)