GNU/Linux

В кодовую базу OpenSSH добавлена экспериментальная поддержка двухфакторной аутентификации с использованием устройств, поддерживающих протокол U2F, развиваемый альянсом FIDO. U2F позволяет создавать недорогие аппаратные токены для подтверждения физического присутствия пользователя, взаимодействие с которыми производится через USB, Bluetooth или NFC. Подобные устройства продвигаются в качестве средства для двухфакторной аутентификации на сайтах, уже поддерживаются основными браузерами и выпускаются различными производителями, включая Yubico, Feitian, Thetis и Kensington.

Для взаимодействия с устройствами, подтверждающими присутствие пользователя, в OpenSSH добавлен новый тип ключей "sk-ecdsa-sha2-nistp256@openssh.com" ("ecdsa-sk"), в котором используется алгоритм цифровой подписи ECDSA (Elliptic Curve Digital Signature Algorithm) с эллиптической кривой NIST P-256 и хэшем SHA-256. Процедуры взаимодействия с токенами вынесены в промежуточную библиотеку, которая загружается по аналогии с библиотекой для поддержки PKCS#11 и является обвязкой над библиотекой libfido2, предоставляющей средства для коммуникации с токенами поверх USB (поддерживается протоколы FIDO U2F/CTAP 1 и FIDO 2.0/CTAP 2). Подготовленная разработчиками OpenSSH промежуточная библиотека libsk-libfido2 включена в основной состав libfido2, как и HID-драйвер для OpenBSD.

Для включения U2F можно использовать свежий срез кодовой базы из репозитория OpenSSH и HEAD-ветку библиотеки libfido2, в которую уже входит необходимая для OpenSSH прослойка. Libfido2 поддерживает работу в OpenBSD, Linux, macOS и Windows.

Для аутентификации и генерации ключа необходимо выставить переменную окружения SSH_SK_PROVIDER, указав в ней путь к libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so), или определить библиотеку через настойку SecurityKeyProvider, после чего запустить "ssh-keygen -t ecdsa-sk" или, если ключи уже созданы и настроены, подключиться к серверу при помощи "ssh". При запуске ssh-keygen созданная пара ключей будет сохранена в "~/.ssh/id_ecdsa_sk" и может использоваться аналогично другим ключам.

Открытый ключ (id_ecdsa_sk.pub) следует скопировать на сервер в файл authorized_keys. На стороне сервера только проверяется цифровая подпись, а взаимодействие с токенами производится на стороне клиента (на сервере не нужно устанавливать libsk-libfido2, но сервер должен поддерживать тип ключей "ecdsa-sk"). Сгенерированный закрытый ключ (id_ecdsa_sk) по сути является дескриптором ключа, образующим реальный ключ только в сочетании с секретной последовательностью, хранимой на стороне токена U2F.

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

Ключ U2F может быть добавлен в ssh-agent через "ssh-add ~/.ssh/id_ecdsa_sk", но ssh-agent должен быть собран с поддержкой ключей "ecdsa-sk", должна присутствовать прослойка libsk-libfido2 и агент должен выполняться на системе, к которой подключается токен. Новый тип ключей "ecdsa-sk" добавлен так как формат ecdsa-ключей OpenSSH отличается от формата U2F для цифровых подписей ECDSA наличием дополнительных полей.

Компания Google начала тестирование третьей редакции манифеста Chrome, нарушающей работу многих дополнений для блокирования нежелательного контента и обеспечения безопасности. Поддержка нового манифеста, который определяет возможности и ресурсы, предоставляемые дополнениям, добавлена в экспериментальные сборки Chrome Canary. Новый манифест разработан в рамках инициативы по усилению безопасности, конфиденциальности и производительности дополнений (основной целью является упрощение создания безопасных и высокопроизводительных дополнений, и усложнение возможности создания небезопасных и медленных дополнений).

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

Напомним, что основное недовольство новым манифестом связано с прекращением поддержки блокирующего режима работы API webRequest, который будет ограничен режимом только для чтения. Исключение будет сделано лишь для редакции Chrome для предприятий (Chrome for Enterprise), в которых поддержка API webRequest будет сохранена. Компания Mozilla решила не следовать за новым манифестом и сохранить в Firefox возможность полного использования API webRequest.

Вместо API webRequest для фильтрации контента в новом манифесте предложен декларативный API declarativeNetRequest. Если API webRequest позволял подключать собственные обработчики, имеющие полный доступ к сетевым запросам и способные на лету модифицировать трафик, новый API declarativeNetRequest предоставляет доступ к готовому универсальному встроенному движку для фильтрации, самостоятельно обрабатывающему правила блокировки, не разрешающему использовать собственные алгоритмы фильтрации и не позволяющему задавать сложные правила, перекрывающие друг друга в зависимости от условий.

В новом манифесте также представлены и другие изменения, влияющие на совместимость с дополнениями. Среди них:

Переход к выполнению Service workers в форме фоновых процессов, что потребует от разработчиков изменения кода некоторых дополнений.

Новая гранулированная модель запроса полномочий - дополнение не сможет активироваться сразу для всех страниц (убрано полномочие "all_urls"), а будет работать только в контексте активной вкладки, т.е. пользователю потребуется подтверждать работу дополнения для каждого сайта.

Изменение обработки Cross-origin запросов - в соответствии с новым манифестом на скрипты обработки контента будут распространяться те же ограничения полномочий, что и для основной страницы, в которую эти скрипты внедряются (например, если страница не имеет доступа к API определению местоположения, то и скрипт дополнения также не получит этот доступ).

Запрет выполнения кода, загруженного с внешних серверов (речь про ситуации, когда дополнение подгружает и выполняет внешний код).

Компания Google развивает сборочную систему Soong, призванную заменить собой старые сценарии сборки платформы Android, основанные на использовании утилиты make. Soong предлагает использовать простые декларативные описания правил сборки модулей, задаваемые в файлах с расширением ".bp" (blueprints). Формат файлов близок к JSON и по возможности повторяет синтаксис и семантику сборочных файлов Bazel. Код написан на языке Go и распространяется под лицензией Apache 2.0.

Сборочные файлы Soong не поддерживают условных операторов и выражений для ветвления, а только описывают структуру проекта, применяемые при сборке модули и зависимости. Подлежащие сборке файлы описываются при помощи масок и группируются в пакеты, каждый из который представляет собой коллекцию файлов с указанием связанных с ними зависимостей. Возможно определение переменных, которые строго типизированы (тип переменных выбирается динамически при первом присвоении, а для свойств статически в зависимости от типа модуля). Сложные элементы сборочной логики вынесены в обработчики, написанные на языке Go.

Soong переплетается с более общим проектом Blueprint, в рамках которого развивается не привязанная к Android мета-система сборки. Парадигма данного типа сборки заключается в том, что на основе файлов с декларативными описаниями модулей, формируются сборочные сценарии Ninja (замена make), описывающие команды, которые необходимо выполнить для сборки, и зависимости. Вместо применения сложных правил или предметно ориентированного языка для определения логики сборки, в Blueprint применяются специфичные для собираемых проектов обработчики на языке Go (Soong является по сути набором подобных обработчиков для Android).

Подобный подход позволяет для больших и разнородных проектов, таких как Android, реализовать сложные элементы сборочной логики в коде на высокоуровневом языке программирования, при этом сохраняется возможность при помощи простого декларативного синтаксиса вносить в модули изменения, связанные с организацией сборки и структурой проекта. Например, в Soong выбор флагов компилятора производится обработчиком llvm.go, а применение специфичных для аппаратных архитектур настроек производится обработчиком art.go, но привязка файлов с кодом осуществляется в файле ".bp".

cc_library {

...

srcs: ["generic.cpp"],

arch: {

arm: {

srcs: ["arm.cpp"],

},

x86: {

srcs: ["x86.cpp"],

},

},

}

Организация Open Invention Network (OIN), занимающаяся защитой экосистемы Linux от патентных претензий, примет участие в защите проекта GNOME от атаки патентного тролля Rothschild Patent Imaging LLC. На проходящей в эти дни конференции Open Source Summit Europe директор OIN заявил, что организация уже собрала команду юристов, которые займутся поиском фактов более раннего использования описанных в патенте технологий (Prior art), что поможет добиться признания патента недействительным.

OIN не может воспользоваться для защиты GNOME сформированным для защиты Linux патентным пулом, так как Rothschild Patent Imaging LLС лишь владеет интеллектуальной собственностью, но не ведёт разработку и производственную деятельность, т.е. ей невозможно предъявить ответный иск, связанный с нарушением условий использования патентов в каких-либо продуктах. Rothschild Patent Imaging LLC является классическим патентным троллем, живущим в основном за счёт исков к мелким стартапам и компаниям, которые не имеют ресурсов для длительного судебного разбирательства и которым проще оплатить отступные. За последние 6 лет компания Rothschild Patent Imaging LLС подала 714 подобных исков.

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

Напомним, что GNOME Foundation вменяется нарушение патента 9,936,086 в менеджере фотографий Shotwell. Патент датирован 2008 годом и описывает технику беспроводного соединения устройства захвата изображений (телефон, web-камера) с получающим изображение устройством (компьютер) и последующей выборочной передачей изображений с фильтрацией по дате, местоположению и другим параметрам. По мнению истца, для нарушения патента достаточно наличия функции импорта с камеры, возможности группировки изображений по определённым признакам и отправки изображений на внешние сайты (например, в социальную сеть или фотосервис).

Истец предложил отозвать иск в обмен на покупку лицензии на использование патента, но GNOME не согласился на сделку и решил бороться до конца, так как уступка поставила бы под угрозу другие открытые проекты, которые потенциально могут стать жертвами указанного патентного тролля. Для финансирования защиты GNOME был создан фонд "GNOME Patent Troll Defense Fund", который уже собрал 109 тысяч долларов из необходимых 125 тысяч.

Компания Intel опубликовала новую версию гипервизора Cloud Hypervisor 0.3. Гипервизор построен на основе компонентов совместного проекта Rust-VMM, в котором кроме Intel также участвуют компании Alibaba, Amazon, Google и Red Hat. Rust-VMM написан на языке Rust и позволяет создавать специфичные для определённых задач гипервизоры. Cloud Hypervisor является одним из таких гипервизоров, который предоставляет высокоуровневый монитор виртуальных машин (VMM), работающий поверх KVM и оптимизированный для решения задач, свойственных для облачных систем. Код проекта доступен под лицензией Apache 2.0.

Cloud Hypervisor cфокусирован на запуске современных дистрибутивов Linux с использованием паравиртуализированных устройств на базе virtio. Из ключевых задач упоминается: высокая отзывчивость, низкое потребление памяти, высокая производительность, упрощение настройки и сокращение возможных векторов для атак.

Поддержка эмуляции сведена к минимуму и ставка делается на паравиртуализацию. В настоящее время поддерживаются только системы x86_64, но в планах имеется и поддержка AArch64. Из гостевых систем пока поддерживается только 64-разрядные сборки Linux. Настройка CPU, памяти, PCI и NVDIMM производится на этапе сборки. Предусмотрена возможность миграции виртуальных машин между серверами.

В новой версии:

Продолжена работа по выносу паравиртуализированного ввода/вывода в отдельные процессы. Для взаимодействие с блочными устройствами добавлена возможность использования бэкендов vhost-user-blk. Изменение позволяет подключать к Cloud Hypervisor блочные устройства на базе модуля vhost-user, такие как SPDK, в качестве бэкендов для паравиртуализированных хранилищ;

Появившаяся в прошлом выпуске поддержка выноса сетевых операций в бэкенды vhost-user-net, расширена новым бэкендом на базе виртуального сетевого драйвера TAP. Бэкенд написан на языке Rust и теперь используется в Cloud Hypervisor в качестве основной паравиртуализированной сетевой архитектуры;

Для повышения эффективности и защищённости коммуникаций между хост-окружением и гостевой системой предложена гибридная реализация сокетов с адресацией AF_VSOCK (виртуальные сетевые сокеты), работающая через virtio. Реализация основана на наработках проекта Firecracker, развиваемого компанией Amazon. VSOCK позволяет использовать штатный POSIX Sockets API для взаимодействия между приложениями на стороне гостевой системы и хоста, что позволяет легко адаптировать для такого взаимодействия обычные сетевые программы и реализовать взаимодействие нескольких клиентских программ с одним серверным приложением;

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

Добавлен слой с реализацией транспорта на базе virtio MMIO (Memory mapped virtio), который может быть использован для создания минималистичных гостевых систем, не требующих эмуляции шины PCI;

В рамках инициативы по расширению поддержки запуска вложенных гостевых систем в Cloud Hypervisor добавлена возможность проброса паравиртуализированных устройств IOMMU через virtio, позволяющего повысить защищённость вложенного и прямого проброса устройств.

Обеспечена поддержка Ubuntu 19.10;

Добавлена возможность запуска гостевых систем с более чем 64 ГБ ОЗУ.

Дополнительно можно отметить новый выпуск смежно развиваемого монитора виртуальных машин Firecracker, также написанного на Rust, базирующегося на Rust-VMM и работающего поверх KVM. Firecracker является ответвлением от проекта CrosVM, используемого компанией Google для запуска приложений Linux и Android в ChromеOS. Разработка Firecracker ведётся в подразделении Amazon Web Services с целью повышения производительности и эффективности работы платформ AWS Lambda и AWS Fargate.

Платформа рассчитана на запуск виртуальных машин с минимальными накладными расходами и предоставляет средства для создания и управления изолированными окружениями и сервисами, построенными с использованием бессерверной модели разработки (функция как услуга). Firecracker предлагает легковесные виртуальные машины, именуемые microVM, для полноценной изоляции которых применяются технологии аппаратной виртуализации, но при этом обеспечивается производительность и гибкость на уровне обычных контейнеров. Например, при использовании Firecracker время с момента запуска microVM до начала выполнения приложения не превышает 125мс, что позволяет запускать новые виртуальные машины с интенсивностью до 150 окружений в секунду.

В новом выпуске Firecracker добавлен режим работы без запуска обработчика API ("--no-api"), ограничивающий окружение только жёстко заданными в файле конфигурации настройками. Статическая конфигурация задаётся через опцию "--config-file" и определяется в формате JSON. Из опций командной строки также добавлена поддержка разделителя "--", указанные после которого флаги передаются по цепочке без обработки.

Развивающая Firecracker компания Amazon также объявила об оказании спонсорской поддержки разработчиков языка программирования Rust. Отмечается, что Rust всё чаще используется в проектах компании и разработки на нём уже внедрены в таких службах, как Lambda, EC2 и S3. Amazon предоставил проекту Rust инфраструктуру для хранения выпусков и сборок в S3, запуска регрессивных тестов в EC2 и поддержания сайта docs.rs с документацией для всех пакетов из репозитория crates.io.

Amazon также представил программу AWS Promotional Credit, в рамках которого открытые проекты могут получить бесплатный доступ к сервисам AWS, которые можно использовать для хранения ресурсов, сборки, непрерывной интеграции и тестирования. Из уже одобренных для участия в программе проектов кроме Rust отмечены AdoptOpenJDK, Maven Central, Kubernetes, Prometheus, Envoy и Julia. Заявки принимаются от любых открытых проектов, поставляемых под лицензиями, одобренными OSI.

Опубликованы сведения о 10 уязвимостях в гипервизоре Xen, из которых пять (CVE-2019-17341, CVE-2019-17342, CVE-2019-17340, CVE-2019-17346, CVE-2019-17343) потенциально позволяют выйти за пределы текущего гостевого окружения и повысить свои привилегии, одна уязвимость (CVE-2019-17347) даёт возможность непривилегированному процессу получить контроль над процессами других пользователей в той же гостевой системе, оставшиеся четыре (CVE-2019-17344, CVE-2019-17345, CVE-2019-17348, CVE-2019-17351) уязвимости позволяют вызвать отказ в обслуживании (крах хост-окружения). Проблемы устранены в выпусках Xen 4.12.1, 4.11.2 и 4.10.4.

CVE-2019-17341 - возможность из подконтрольной атакующему гостевой системы получить доступ на уровне гипервизора. Проблема проявляется только на системах x86 и может быть совершена из гостевых систем, работающих в режиме паравиртуализации (PV), при пробросе в работающую гостевую систему нового PCI-устройства. В гостевых системах, работающих в режимах HVM и PVH, уязвимость не проявляется;

CVE-2019-17340 - утечка памяти, потенциально позволяющая повысить свои привилегии или получить доступ к данным других гостевых систем. Проблема проявляется только на хостах с более чем 16 Тб ОЗУ в 64-разрядных системах и 168 Гб в 32-разрядных. Уязвимость может быть эксплуатирована только из гостевых систем в режиме PV (в режимах HVM и PVH при работе через libxl уязвимость не проявляется);

CVE-2019-17346 - уязвимость при использовании PCID (Process Context Identifiers) для повышения производительности защиты от атак Meltdown позволяет получить доступ к данным других гостевых систем и потенциально повысить свои привилегии. Уязвимость может быть эксплуатирована только из гостевых систем в режиме PV на системах x86 (проблема не проявляется в режимах HVM и PVH, а также в конфигурациях, в которых нет гостевых систем со включенным PCID (PCID активируется по умолчанию));

CVE-2019-17342 - проблема в реализации гипервызова XENMEM_exchange позволяет повысить свои привилегии в окружениях с только одной гостевой системой. Уязвимость может быть эксплуатирована только из гостевых систем в режиме PV (в режимах HVM и PVH уязвимость не проявляется);

CVE-2019-17343 - некорректный маппинг в IOMMU даёт возможность при наличии доступа из гостевой системы к физическому устройству использовать DMA для изменения собственной таблицы страниц памяти и получения доступа на уровне хоста. Уязвимость проявляется только в гостевых системах в режиме PV при наличии прав для проброса PCI-устройств.