Каковы последствия для безопасности регистрации учетной записи для livepatch?

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

• Повторно используете логины / пароли
• Используйте легко угадываемые пароли
• Не защищайте ваш сброс пароля (например, никогда не меняя пароль основной учетной записи электронной почты)
• Поделиться паролями
• ...

Таким образом, помимо базовой безопасности учетной записи:

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

_{OTOH: действительно ли он вам нужен, так как он отлично подходит для серверов, которые должны быть доступны 24/7/365, но для вашего ноутбука / ПК ??? Не совсем по моему личному и абсолютно субъективному мнению}

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

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

TL; DR : последствия для безопасности заключаются в том, что вы позволяете третьей стороне напрямую обновлять ваши системы без действий с вашей стороны, и, следовательно, вы полагаетесь на то, что она выполняет свою работу должным образом и безопасно, а также полагаясь на нее о хорошей безопасности по всему сетевому пути между вами и этим провайдером (который влияет на разные уровни, от IP из-за перехвата BGP, до разрешения DNS и сертификатов X.509, вероятно).

Живое исправление ядра в целом

Во-первых, важно понимать, что «живое исправление» является особенностью недавних ядер Linux с несколькими реализациями. Это также означает, что вы можете извлечь из этого выгоду самостоятельно, не полагаясь на какую-либо третью сторону (пример вы можете увидеть здесь: http://chrisarges.net/2015/09/21/livepatch-on-ubuntu.html ). Это, конечно, не просто, так как вы должны освоить технологию, определить, какие достоинства будут исправлены, а какие исправлены или нет, затем создать исправления, затем применить их и т. Д.

Третья сторона, например Canonical, просто упаковывает весь этот опыт на данный момент, так что это оценка затрат / выгод, причем стоимость не является только денежной частью (например, здесь, если вы используете их сервис для бесплатно вы можете привыкнуть как канарейка, см. «Вопрос: Как Canonical тестирует живые патчи?» в http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html , где есть «он развернут на канарской основе тестирования, сначала для небольшого процента пользователей сообщества Ubuntu службы Canonical Livepatch» и «пользователей сообщества Ubuntu службы Canonical Livepatch», которые хотят исключить небольшую вероятность случайного выбора в качестве Канарейка должна зарегистрироваться в программе Ubuntu Advantage (начиная с 12 долларов в месяц). »

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

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

Здесь вы полагаетесь исключительно на Canonical, чтобы правильно выполнять свою работу. Это вопрос доверия, но у вас почти всегда нет каких-либо полезных индикаторов извне того уровня доверия, который вы можете оказать. Вы можете решить доверять компании только из-за ее названия или ее размера, но вы легко найдете контрпримеры для крупных компаний по названию или размеру, которые делают глупые вещи нарочно, а не так или иначе терпят неудачу. Это не означает, что вы или я не должны доверять этому конкретному провайдеру, это просто общая позиция - верить каждому невиновному до тех пор, пока его вина не будет доказана, или прямо противоположное (и, конечно, доказать что-то отрицательное, например, «нет проблем / ошибок /»). «дыра в безопасности» невозможна, поэтому вам просто нужно идти на компромиссы)

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

О доставке автоматических обновлений

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

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

1. Mozilla заблокировала расширения и обновления Firefox из-за некоторых ошибок подписи ( https: //blog.mozilla. орг / аддонов / 2019/05/04 / ДОПОЛНЕНО относительно-аддонов-в-светлячок / ); по сути, это обратная универсальная атака DOS: один сбой в одном месте (серверы Mozilla) отрицательно сказывается на всех, кто их использует. Это очень похоже на livepatching ядра: в вашем браузере есть расширения, и их можно настроить на автоматическое обновление; но если механизм выходит из строя, он, к сожалению, может даже блокировать запуск расширений, это даже не просто проблема обновления
2. ASUS получила свою инфраструктуру обновлений, захваченную пиратами, которые использовали ее для доставки вредоносного ПО клиентам ( https://arstechnica.com/information-technology/2019/05/asus-cloud-service-abused-to-install-backdoor-on-pcs/)
3. посредством BGP угонщики смогли перенаправить трафик на известный веб-сайт, посвященный криптовалютам, а затем заставить людей потерять часть своих портфелей, поскольку они были перенаправлены в другое место. Это myetherwallet.com история с 2018 года: https://www.psychz.net/client/blog/en/theft-of-cryptocurrency-of-myetherwallet-users-by-bgp-hijack--.html Попутно заметьте, что преступники даже не удосужились использовать что-либо, кроме самосвидетельства, так как люди, кажется, не заботятся о отображаемых тогда предупреждениях, или операции выполняются автоматизированным программным обеспечением, которое часто неправильно создается для неправильной проверки. удаленный сертификат и действуйте должным образом на тех, кто не был действительно проверен известным CA
4. Более поздняя сага «DNSpionnage» ( https://krebsonsecurity.com/2019/02/a-deep-dive-on -the-latest -wide-dns-hijacking-attack / ) представляет собой эволюцию предыдущего случая, когда комбинация BGP-угонщиков, украденных паролей и автоматического создания новых сертификатов DV X.509 для связи TLS, которая затем способна помешать даже лучшему программному обеспечению, настроенному на разрешение только сертификатов от известных ЦС.

Приведенный выше список показывает очень разные случаи:

1. был провайдером, потерпевшим поражение из-за своей собственной архитектуры: сертификат с истекшим сроком действия делает всю подцепь под ним недействительной, это сделано по замыслу
]
2. был провайдером, который видел, как его злоумышленники злоупотребляли его архитектурой.
3. был веб-сайтом, который не подвергался прямой атаке, поскольку преступники могли захватывать ресурсы «под» (IP-адрес), чтобы сделать поток трафика к ним, а не к истинному веб-сайту (это означает, что, хотя этот веб-сайт безопасен и совершенен, или нет, на этом уровне нет ничего, что могло бы предотвратить эту атаку)
4. было широкомасштабной атакой на несколько систем, в том числе люди, получающие в своем программном обеспечении ошибки об изменениях в сертификатах или несоответствиях и продолжающие идти дальше

Теоретически, система Canonical LivePatch, как и любая другая, может подвергаться атакам такого же типа, как описано в список выше и другие, конечно.

Canonical LivePatch system

Из документации в Интернете, как только вы запустите конкретную службу snap и сгенерируете свой токен, вам больше нечем заняться, обновления (исправления ядра) автоматически появятся в вашей системе и будут применяется. [+1148]

В любом случае всегда полезно прочитать мелкий шрифт, а здесь условия обслуживания по адресу https://ubuntu.com/legal/livepatch-terms-of-service . им стандартные предложения об услугах, предлагаемых как есть, без каких-либо гарантий, и в конце «В противном случае общая ответственность Canonical по контракту, правонарушениям или иным образом за любые претензии ограничена 10 фунтами стерлингов. «

Насколько я понимаю, наличие учетной записи является обязательным для отслеживания того, как вы используете систему (поскольку существует бесплатное предложение для 3 серверов), но вход в систему не позволяет специально« выдвигать »некоторые обновления. Можно предположить / теоретизировать, что в «бизнес-настройке» такой вид доступа может позволить просматривать список соответствующих серверов, удаленно узнавать их статус livepatch (имея панель мониторинга) и, возможно, ограничивать / приостанавливать / форсировать некоторые livepatching.

Фактически, вовсе не теория, это точно написано в листе данных по адресу https://assets.ubuntu.com/v1/ef19ede0-Datasheet_Livepatch_AW_Web_30.07.18.pdf :

Служба On-prem предоставляет вам все преимущества Canonical Livepatch, но позволяет полностью контролировать развертывание исправлений и упрощает отслеживание состояния зарегистрированных компьютеров. Служба On-prem доступна как сайт. Общая подписка, первоначально развернутая Canonical в облаке по вашему выбору.

и

On-pre m Служба Livepatch позволяет вам определять политику развертывания и сохранять полный контроль над тем, какие машины будут обновляться и когда. Чтобы поддерживать ваши машины в актуальном состоянии, служба «на прем» регулярно синхронизируется с Canonical Livepatch и получает самые последние исправления. Однако локальный сервер позволяет установить политику для поэтапных выпусков и применить новое исправление к контролируемому подмножеству компьютеров в центре обработки данных, а после проверки применить исправление к более широкому набору компьютеров на любом количестве этапов, если это необходимо. .

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

Так что для вашего Вопрос:

Означает ли это, что если кто-то угадает ваш пароль, он может вмешаться в ваши обновления или livepatch?

ответом будет ДА , если принять во внимание все возможные варианты использования.

Еще одна вещь, которую следует принять во внимание, это то, что клиент (снимок canonical-livepatch) является проприетарным и, следовательно, исходный код недоступен. Таким образом, вы понятия не имеете, что именно делает этот код, даже если вы хотите его изучить. Вам, вероятно, потребуется установить прокси и вмешиваться в рукопожатия TLS и записи DNS, чтобы фиксировать, какие данные передаются в обоих направлениях.

Вы можете по крайней мере поздравить их с честностью на http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html , что технически прямо здесь:

В: Разве livepatching не является просто большим оле-руткитом?

A: Canonical Livepatches внедряет модули ядра для замены разделов двоичного кода в работающем ядре. Это требует возможности CAP_SYS_MODULE. Это необходимо для проверки любого модуля в ядре Linux. Если у вас уже есть эта возможность (root по умолчанию работает в Ubuntu), то у вас уже есть возможность произвольно модифицировать ядро ​​с использованием или без Canonical Livepatches.

Безопасная загрузка

Примечание при передаче из https://wiki.ubuntu.com/Kernel/Livepatch этой части:

Почему Livepatch не работает на моей машине?

SECUREBOOT

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

[..]

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

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

Процесс аутентификации

Ваш вопрос был

Существует ли дополнительный процесс аутентификации, который происходит во время livepatch и зависит от этой учетной записи? если так, то почему?

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

Этот другой вопрос на этом сайте также имеет отношение: Какие данные передаются в Canonical для livepatch?

Мы узнаем, что проприетарное программное обеспечение обменивается нетривиальным количеством данных, которое технически не требуется для livepatching (например: текущее время безотказной работы), но является частью службы Canonical.

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

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