Слияние кода завершено, страница обновится автоматически
Использование BoringSSL в песочнице
Песочницы — это ценный инструмент для обеспечения безопасности приложений, поэтому BoringSSL стремится их поддерживать. Однако трудно дать конкретные гарантии относительно API с песочницами. Песочницы удаляют низкоуровневые ресурсы ОС и системные вызовы, что нарушает абстракции платформы. Например, песочница с фильтрацией системных вызовов может быть чувствительна к изменениям, которые в противном случае не нарушают работу, при использовании новых системных вызовов либо в BoringSSL, либо в библиотеке C.
Некоторые функции в BoringSSL, такие как BIO_new_file, по своей сути требуют ресурсов ОС, таких как файловая система. Мы предполагаем, что потребители в песочницах либо избегают этих функций, либо предоставляют необходимые ресурсы. Другие функции, такие как RSA_sign, являются чисто вычислительными, но всё же имеют некоторые базовые зависимости от ОС.
Песочницы, которые частично теряют привилегии в течение времени жизни процесса, также чувствительны к ресурсам ОС, сохраняемым при переходах. Например, если библиотечная функция внутренне открыла и сохранила дескриптор домашнего каталога пользователя, а затем приложение вызвало chroot, этот дескриптор стал бы выходом из песочницы.
В этом документе делается попытка описать эти базовые зависимости ОС и долгосрочные внутренние ресурсы. Эти зависимости могут меняться со временем, но мы стремимся работать с потребителями в песочницах, когда они это делают. Однако каждая песочница накладывает разные ограничения, поэтому, прежде всего, потребители в песочницах должны иметь достаточное тестовое покрытие для обнаружения проблем по мере их возникновения.
Вызывающие объекты должны предполагать, что любая функция BoringSSL может выполнять одну из следующих операций:
Любая функция BoringSSL может выделить память через malloc и связанные функции.
Любая функция BoringSSL может вызывать примитивы синхронизации платформы, включая блокировки чтения/записи и эквивалент pthread_once. Они должны быть успешными, иначе BoringSSL завершит процесс. Вызывающие, однако, могут предположить, что функции BoringSSL не будут создавать внутренние потоки, если иное не задокументировано.
Песочницам с фильтрацией системных вызовов следует отметить, что BoringSSL использует pthread_rwlock_t в системах POSIX, который менее распространён и может не входить в поверхность системных вызовов других библиотек. Кроме того, примитивы синхронизации потоков обычно имеют быстрый путь на основе атомарных операций. Если песочница блокирует необходимый системный вызов pthreads, он может не проявиться при тестировании без конкуренции блокировок.
Любая функция BoringSSL может записывать в stderr или дескриптор файла STDERR_FILENO (2) либо через API FILE, либо через низкоуровневые функции, такие как write. Записи в stderr могут завершиться неудачно, но должен существовать файл в STDERR_FILENO, который будет принимать сообщения об ошибках от BoringSSL. (Дескриптор файла должен быть выделен, чтобы вызовы open случайно не открыли там что-то другое.)
Обратите внимание, что некоторые реализации стандартной библиотеки C также регистрируются в stderr, поэтому вызывающие должны обеспечить это независимо.
Любая функция BoringSSL может получать энтропию от ОС. В Windows это использует RtlGenRandom, а в системах POSIX — getrandom, getentropy или read из дескриптора файла в /dev/urandom. Эти операции должны быть успешными, иначе BoringSSL завершит процесс. BoringSSL проверяет поддержку getrandom только один раз и предполагает, что поддержка остаётся постоянной в течение всего времени существования адресного пространства (и любых копий, сделанных через fork). Если песочница с фильтрацией системных вызовов включена частично в течение этого времени существования и изменяет работу getrandom, BoringSSL может завершить процесс. Песочницам рекомендуется разрешить getrandom.
Обратите внимание, что даже детерминированные алгоритмы могут потребовать энтропии ОС. Например, RSASSA-PKCS1-v1_5 является детерминированным, но BoringSSL получает энтропию для реализации ослепления RSA.
Сбор энтропии дополнительно имеет некоторые зависимости инициализации, описанные в следующем разделе.
BoringSSL имеет некоторые необычные зависимости от ОС, которые используются только один раз для инициализации некоторого состояния. Песочницы, теряющие привилегии после некоторой настройки, могут использовать CRYPTO_pre_sandbox_init для предварительной инициализации этого состояния. В противном случае вызывающие стороны должны предположить... Любая функция BoringSSL может зависеть от этих ресурсов, в дополнение к указанным операциям.
На платформах Linux ARM BoringSSL зависит от API ОС для запроса возможностей процессора. 32-битная и 64-битная ARM зависят от функции getauxval. 32-битная ARM, чтобы обойти ошибки на старых устройствах Android, может дополнительно читать /proc/cpuinfo и /proc/self/auxv.
Если запрос о возможностях процессора не удастся, BoringSSL всё равно будет работать, но может работать не так хорошо.
В системах Linux без работающего getrandom, получение энтропии из ОС дополнительно требует открытия /dev/urandom. Если это не удаётся, BoringSSL завершит процесс. BoringSSL сохраняет полученный файловый дескриптор даже при переходе привилегий.
В Linux BoringSSL выделяет страницу и вызывает madvise с MADV_WIPEONFORK, чтобы защитить одноразовое состояние от fork. Эта операция не должна приводить к сбою, но если она не удалась, BoringSSL будет использовать альтернативные стратегии безопасности форка, потенциально за счёт производительности. Если она успешна, BoringSSL предполагает, что MADV_WIPEONFORK функционален, и полагается на него для обеспечения безопасности форка. Песочницы не должны сообщать об успехе, если они игнорируют флаг MADV_WIPEONFORK. На момент написания статьи QEMU будет игнорировать вызовы madvise и сообщать об успехе, поэтому BoringSSL обнаруживает это, вызывая madvise с -1. Песочницы должны чисто сообщать об ошибке вместо сбоя.
После инициализации этот механизм не требует системных вызовов в устойчивом состоянии, хотя следует отметить, что настроенную страницу можно наследовать при переходе привилегий.
BoringSSL зависит от стандартных библиотек C и C++, которые сами по себе не дают никаких гарантий относительно песочниц. Если он выдаёт правильный ответ и не имеет наблюдаемых недопустимых побочных эффектов, возможно, хотя и неразумно, чтобы memcmp создал и закрыл сокет.
BoringSSL предполагает, что функции в библиотеке C и C++ имеют только те платформенные зависимости, которые были бы «разумными». Например, функция в BoringSSL, которая стремится не открывать файлы, всё равно свободно вызывает любые функции памяти и строк libc.
Обратите внимание, что некоторые функции C, такие как strerror, могут читать файлы, относящиеся к локали пользователя. BoringSSL может запускать эти пути и предполагает, что среда песочницы будет терпима к этому. Кроме того, BoringSSL не может дать гарантии относительно того, какие системные вызовы используются оболочками системных вызовов стандартной библиотеки. В некоторых случаях компилятор может добавлять зависимости. (Некоторые функции языка C++ излучают код блокировки.) Песочницам фильтрации системных вызовов могут потребоваться обновления по мере изменения этих зависимостей.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )