Импликации безопасности разбивки на страницы

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

Действительно, много типов данных, таких как хеши, незашифрованные версии уязвимых данных, и аутентификационные маркеры, не должны обычно писаться в диск вследствие потенциала для злоупотребления. Это повышает интересную проблему. Нет никакого хорошего способа иметь дело с этим в пространстве пользователя (если программа не работает как root). Однако для кода ядра, возможно препятствовать тому, чтобы страницы были выписаны к запоминающему устройству. Этот процесс упоминается как “соединяющий проводом вниз” память и описан далее в Копировании Отображения и Блока Памяти.

Основная цель соединенной проводом памяти состоит в том, чтобы позволить основанный на DMA I/O. Так как аппаратные средства, контроллеры DMA обычно не понимают виртуальное обращение, информация, используемая в I/O, должны быть физически в памяти в определенном расположении и не должны перемещаться, пока операция I/O не завершена. Этот механизм может также использоваться, чтобы препятствовать тому, чтобы уязвимые данные были записаны в запоминающее устройство.

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

В OS X можно соединить проводом вниз память во время выделения или впоследствии. Соединять память проводом во время выделения:

• В Наборе I/O вызвать IOMalloc и IOFree выделить и освободить соединенную проводом память.

• В других расширениях ядра вызвать OSMalloc и OSFree и передайте тип тега, флаги которого установлены в OSMT_DEFAULT.

• В коде пространства пользователя выделите количества размера страницы со своим выбором API, и затем вызовите mlock соединять их проводом.

• В самом ядре (не в расширениях ядра), можно также использовать kmem_alloc и связанные функции.

Для получения дополнительной информации о соединенной проводом памяти посмотрите, что Память Отображается и Блочное Копирование.

Переполнение буфера и недопустимый ввод

Переполнение буфера является одной из более общих ошибок и в приложении и в программировании ядра. Наиболее распространенной причине не удается выделить площадь для Символа Нулевого, завершающего строку в C или C++. Однако ввод данных пользователем может также вызвать переполнение буфера, если входные буферы фиксированного размера используются, и надлежащую заботу не соблюдают для предотвращения переполнения этих буферов.

Самая очевидная защита, в этом случае, является лучшей. Или не используйте буферы фиксированной длины или добавляйте код, чтобы отклонить или усечь ввод, переполняющий буфера. Подробные данные реализации в любом случае зависят от типа кода, который Вы пишете.

Например, если Вы работаете со строками, и усечение приемлемо вместо использования strcpy, необходимо использовать strlcpy ограничить объем данных для копирования. OS X обеспечивает ограниченные длиной версии многих строковых функций, включая strlcpy, strlcat, strncmp, snprintf, и vsnprintf.

Если усечение данных не приемлемо, необходимо явно вызвать strlen определить длину входной строки и возвратить ошибку, если это превышает максимальную длину (меньше, чем размер буфера).

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

Частая ошибка предполагает что, перечисляя каждое возможное значение enum тип обеспечивает защиту. Перечисление обычно реализуется как любой a char или int внутренне. Небрежный или злонамеренный программист мог легко передать любое значение функции ядра, включая не явно перечисленных в типе, просто при помощи различного прототипа, определяющего параметр как, например, int.

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

int do_something(bufptr *bp, int flags) {

    char *token = bp->b_data;

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

Безопасность особенно важна для кода ядра, рисующего ввод из сети. Предположения о размере пакета часто являются причиной проблем безопасности. Всегда наблюдайте за пакетами, которые являются слишком большими и обрабатывают их разумным способом. Аналогично, всегда проверяйте контрольные суммы на пакетах. Это может помочь Вам определить, был ли пакет изменен, поврежден или усеченный в пути, хотя это далеко от защиты от случайных ошибок. Если законность данных от сети имеет огромное значение, необходимо использовать удаленную аутентификацию, подписание и механизмы шифрования, такие как описанные в Удаленной аутентификации и Основанной на ключе Аутентификации и Шифровании.

Удостоверения пользователя

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

Модель обеспечения безопасности ядра основывается на двух механизмах: учетные данные рядового пользователя и полномочия ACL. Первые учетные данные рядового пользователя, розданы в ядре для идентификации текущего пользователя и группы обработки вызовов. Второй механизм аутентификации, списки управления доступом (ACLs), обеспечивает управление доступом на более прекрасном уровне гранулярности.

Одна из самых важных вещей помнить, когда работа с учетными данными состоит в том, что они для каждого процесса, не на контекст. Это важно, потому что процесс может не работать как пользователь консоли. Двумя примерами этого являются процессы, запущенные с ssh сеанс (так как ssh работает в контексте запуска), и setuid программы (которые работают как различный пользователь в том же контексте входа в систему).

Крайне важно знать об этих проблемах. Если Вы связываетесь с a setuid root Приложение GUI в контексте входа в систему пользователя, и если Вы выполняете другое приложение или считываете уязвимые данные, Вы, вероятно, хочет обработать его, как будто это имело те же полномочия как пользователь консоли, не полномочия эффективного идентификатора пользователя, вызванного путем выполнения setuid. Это особенно проблематично при контакте с программами, работающими как setuid root если пользователь консоли не находится в администраторской группе. Отказ выполнить разумные проверки может привести к главным дырам в системе безопасности в будущем.

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

Обычно проще определить пользователя консоли из приложения пространства пользователя, чем от кода пространства ядра. Таким образом необходимо обычно делать такие проверки от пространства пользователя. Если это не возможно, однако, переменная console_user (сохраняемый подсистемой VFS), даст Вам uid последнего владельца /dev/console (сохраняемый небольшим количеством кода в chown системный вызов). Это - конечно, не идеальное решение, но оно действительно обеспечивает наиболее вероятные идентификационные данные пользователя консоли. Так как это - только “лучшее предположение”, однако, необходимо использовать это, только если Вы не можете сделать надлежащей регистрации в пространстве пользователя.

Удаленная аутентификация

Это - одна из более трудных проблем в компьютерной безопасности: возможность идентифицировать кого-то соединяющегося с компьютером удаленно. Один из самых безопасных методов является использованием шифрования с открытым ключом, описанного более подробно в Основанной на ключе Аутентификации и Шифровании. Однако много других средних значений аутентификации возможны с различными степенями безопасности.

Некоторые другие схемы аутентификации включают:

• слепое доверие

• Аутентификация только для IP

• пароль (совместно использованный секрет) аутентификация

• комбинация IP и аутентификации по паролю

• шифры Вернама (ответ проблемы)

• основанная на времени аутентификация

Большинство из них очевидно, и не требует никакого дальнейшего объяснения. Однако шифры Вернама и основанную на времени аутентификацию могут быть незнакомыми многим людям вне кругов безопасности и таким образом стоит упомянуть более подробно.

Основанная на времени аутентификация

Это - вероятно, наименее понятые средние значения аутентификации, хотя она обычно используется такими технологиями как SecurID. Понятие является относительно прямым. Вы начинаете с математической функции, берущей небольшое количество параметров (два, например) и возвращающей новый параметр. Хорошим примером такой функции является функция, генерирующая набор Чисел Фибоначчи (возможно усеченный после определенного числа битов с произвольными начальными значениями семени).

Возьмите эту функцию и добавьте третий параметр, t, представление времени в модулях k секунды. Заставьте функцию быть производящей функцией на t, с двумя значениями семени, a и b, где

Другими словами, каждый k секунды, Вы вычисляете новое значение на основе предыдущих двух и некоторого уравнения. Тогда отбросьте самое старое значение, заменив его вторым по возрасту значением, и замените второе по возрасту значение значением, которое Вы просто сгенерировали.

Пока оба конца имеют то же понятие текущего времени и исходных двух чисел, они могут тогда вычислить последний раз сгенерированное число и использовать это в качестве совместно используемого секрета. Конечно, если Вы пишете код, делающий это, необходимо использовать закрытую форму этого уравнения, начиная с вычисления Чисел Фибоначчи рекурсивно без дополнительного хранения растет на O(2^(t/k)), который не практичен когда t измеряется в годах и k маленькая константа, измеренная в секундах.

Безопасность такой схемы зависит от различных свойств функции генератора, и подробные данные такой функции выходят за рамки этого документа. Для получения дополнительной информации необходимо получить вводный текст на криптографии. такой как Прикладная Криптография Брюса Шнайера.

Временные файлы

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

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

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

/dev/mem и /dev/kmem

Одно особенно болезненное удивление людям, делающим программирование безопасности в большей части UNIX или подобных UNIX средах, является существованием /dev/mem и /dev/kmem. Эти файлы устройств позволяют root пользователь для произвольного доступа к содержанию физической памяти и памяти ядра, соответственно. Нет абсолютно ничего, что можно сделать для предотвращения этого. С точки зрения ядра корень является вездесущим и всезнающим. Если это - проблема безопасности для Вашей программы, то необходимо рассмотреть, должна ли программа использоваться в системе, которой кто-то еще управляет, и принять необходимые меры предосторожности.

Основанная на ключе аутентификация и шифрование

Основанная на ключе аутентификация и шифрование являются якобы некоторыми более безопасными средними значениями аутентификации и шифрования, и могут существовать во многих формах. Наиболее распространенные формы основаны на совместно используемом секрете. DES, 3DES (тройной DES), IDEA, twofish и шифры шифра является примерами схем шифрования на основе совместно используемого секрета. Пароли являются примером схемы аутентификации на основе совместно используемого секрета.

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

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

Понятие доказательства нулевого знания - то, что созданы две на вид произвольных ценности ключа, x и y, и что эти значения связаны некоторым ƒ математической функции таким способом который

ƒ(ƒ(a,k1),k2) = a

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

ƒ(ƒ(a,k2),k1) = a

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

Пример этого должен выбрать математическую функцию, чтобы быть

f(a,k)=((a*k) MOD 256) + ((a*k)/256)

где a байт открытого текста, и k некоторые ключевые 8 битов в длине. Это - чрезвычайно слабый шифр, начиная с функции f позволяет Вам легко определять один ключ от другого, но это иллюстративно из фундаментального понятия.

Выбрать k1 быть 8 и k2 быть 32. Таким образом для a=73, (a * 8)=584. Это берет два байта, поэтому добавьте биты в высоком байте к битам младшего байта, и Вы добираетесь 74. Повторите этот процесс с 32. Это дает Вам 2368. Снова, добавьте биты от высокого байта до битов младшего байта, и Вы имеете 73 снова.

Это математическое понятие (с совсем другими функциями), когда помещено в практическое применение, известно как криптография с открытым ключом (PK) и формирует основание для шифрования DSA и RSA.

Консольная отладка

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

В OS X любой пользователь может выполнить Консольное приложение. Это представляет основное отбытие от других подобных UNIX систем. В то время как это никогда не хорошая идея включать уязвимую информацию в отладочные операторы ядра, особенно важно не сделать так в OS X. Необходимо предположить, что любые информации, выведенные на экран к консоли, могли потенциально быть считаны любым пользователем в системе (так как консоль виртуализируется в форме просматриваемого пользователем окна).

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

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

Это, при необходимости, не полный список информации, чтобы избежать распечатывать к консоли. Необходимо использовать собственное решение при решении, могли ли бы данные быть ценными, если замечено третьим лицом, и затем решать, является ли надлежащим распечатать его к консоли.

Передача кода

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

Если возможно выполнить Ваш код в пространстве пользователя, Вы даже не должны собираться продвигать код в ядро. Для редкого случая, где никакое другое разумное решение не существует, однако, Вы, возможно, должны передать некоторую форму исполняемого кода в ядро. Этот раздел объясняет некоторые разветвления безопасности продвижения кода в ядро, и уровень проверки должен был гарантировать непротиворечивую работу.

Вот некоторые инструкции для минимизации потенциала для дыр в системе безопасности:

1. Никакой необработанный объектный код.

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

2. Проверка границ.

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

3. Проверка завершения.

   С очень, очень немного исключений, выбранный язык должен быть ограничен для кодирования, который может быть проверен для завершения, и необходимо проверить соответственно. Если Ваш драйвер застревает в плотно прокрученном цикле, это, вероятно, неспособно выполнить свою работу и может повлиять на полную производительность системы в процессе. Язык, не позволяющий (неограниченные) циклы (например, позволяя for но нет while или goto мог быть один способ гарантировать завершение.

4. Проверка законности.

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

5. Проверка здравомыслия.

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

   Например, сетевое правило фильтра должно вывести что-то напоминающее пакеты. Если контрольные суммы плохи, или если другая информация отсутствует или повреждение, ясно загруженный код является дефектным, и соответствующие меры должны быть приняты. Было бы очень неуместно для OS X отослать плохой сетевой трафик.

В целом, чем более строгий набор языка, тем ниже угроза безопасности. Например, интерпретация простых политик сетевой маршрутизации, менее вероятно, будет проблемой безопасности, чем интерпретация пакетных правил перезаписи, который, менее вероятно, будет проблемой, чем выполнение Байт-кода Java в ядре. Как с чем-либо еще, необходимо тщательно взвесить потенциальные выгоды против потенциальных недостатков и принять лучшее решение, данное доступную информацию.