 |  |
http://www.bugtraq.ru/library/security/failure.html |
|
|||
|
|
|
||
| http://www.bugtraq.ru/library/security/failure.html |
||||
| ||||
Peter A. Loscocco, Stephen D. Smalley, Patrick A. Muckelbauer, Ruth C. Taylor, S. Jeff Turner, John F. Farrell /National Security Agency/
Несмотря на быстрый рост всеобщей осведомленности в необходимости обеспечения безопасности компьютерных систем, современные попытки обеспечить ее вряд ли закончатся успешно. Современные попытки обеспечения безопасности страдают от неверного предположения, что адекватная степень защиты может быть достигнута на прикладном уровне (с помощью приложений) совместно с механизмами защиты существующими в основных современных операционных системах. В реальности, благодаря значительному увеличению взаимодействия и разделения данных, в современных компьютерных средах растет необходимость в защищенных операционных системах. Целью данной статьи является возобновление интереса к защищенным операционным системам, чтобы последующие попытки обеспечения компьютерной безопасности базировались на более прочной основе. В данной статье указываются несколько возможностей защищенных операционных систем, которые отсутствуют в основных современных операционных системах, доказывается необходимость этих возможностей для адекватной защиты более общих механизмов обеспечения безопасности прикладного уровня, а также приводятся конкретные примеры того, как сильно существующие решения в области обеспечения безопасности зависят от этих возможностей.
Keywords: secure operating systems, mandatory security, trusted path, Java, Kerberos, IPSEC, SSL, firewalls.
Всеобщая осведомленность в необходимости обеспечения безопасности компьютерных систем растет по мере того, как очень важные сервисы все больше и больше становятся зависимыми от взаимодействия компьютерных систем. Компоненты национальной инфраструктуры, такие как электроэнергия, телекоммуникации и транспортная система, не могут больше функционировать без использования компьютерных сетей. Появление ВВВ особенно способствовало усилению всеобщего внимания к проблемам безопасности. Безопасность является основной заботой бизнеса, который хочет использовать интернет в коммерческих целях и для поддержания деловых отношений [24].
Увеличение осведомленности в необходимости защиты вылилось в увеличение количества попыток интегрировать защитные механизмы в компьютерные системы. Впрочем, эти попытки страдают от неверного предположения, что адекватная степень защиты может быть достигнута на прикладном уровне (с помощью приложений) без использования определенных механизмов защиты операционной системы. В реальности, механизмы защиты операционной системы играют решающую роль в обеспечении безопасности на более высоких уровнях. Это было вполне понятно на протяжении как минимум 25 лет [2][54][39], и продолжает подтверждаться в литературе [1][35].
Необходимость наличия встроенных средств защиты на уровне операционной системы бесспорна; операционная система обеспечивает защиту механизмов прикладного уровня от неправильного использования, обхода или навязывания ложной информации. Если она не сможет удовлетворить этим требованиям, появятся уязвимости в масштабах всей системы. Потребность в защищенных операционных системах особенно важна в современных компьютерных средах. Значительное увеличение возможностей взаимодействия и совместного использования данных увеличило риск использования систем настолько, что даже осторожный и опытный пользователь, использующий однопользовательскую систему, больше не защищен от угрозы злоумышленного кода (программ). В связи с тем, что разница между кодом программы и данным исчезает, злоумышленный код может быть введен в систему, причем без осознанного решения пользователя установить исполняемый код, когда бы данные не вводились в систему. Например, злоумышленный код может быть введен как Ява-апплет или при просмотре кажущихся безобидными данных, в действительности содержащие исполняемый код [32][62]. Для защиты от этой угрозы защищенная операционная система необходима как никогда.
Целью данной статьи является мотивация возрождающегося интереса к защищенным операционным системам. Объединив несколько хорошо документированных примеров из литературы, она показывает, что угрозы, возникающие в современных компьютерных системах, не могут быть преодолены без помощи защищенных операционных систем, и, как изложено в [8], любые усилия по обеспечению безопасности, неучитывающие этого факта, могут оказаться лишь крепостью, построенной из песка. В разделе 2 приведен набор возможностей защищенных операционных систем, который обычно отсутствует в основных современных операционных системах, но является критичным для обеспечения информационной безопасности. Необходимость наличия этих возможностей обоснована в разделе 3, в котором рассматривается вопрос, почему разграничение доступа на прикладном уровне и криптографическая защита не могут обеспечить значимый уровень безопасности без поддержки защищенной операционной системы. В разделе 4 приведены конкретные примеры того, как усилия по обеспечению безопасности зависят от этих возможностей защищенных операционных систем. В разделе 5 обсуждается роль защищенности операционной системы в обеспечении защищенности системы в целом.
В этом разделе указаны некоторые возможности защищенных операционных систем, которые являются необходимыми для обеспечения безопасности механизмов защиты прикладного уровня, и отсутствуют в большинстве современных операционных систем. Они образуют "потерянное звено" защиты. Хотя этот раздел затрагивает только сами возможности, необходимо обратить внимание на то, что сами по себе наличие возможностей не является адекватной мерой. Необходимо гарантированное доказательство того, что возможности удовлетворяют требуемым системным свойствам, а так же показать, что возможности корректно реализованы. Гарантии - самое слабое звено; несмотря на то, что подходы к предоставлению гарантий могут быть спорными, важность гарантий несомненна.
Список возможностей, приведенный в данном разделе, не претендует на полноту; вместо это представлен просто набор критичных возможностей, который демонстрирует значение защищенных операционных систем. Более подробное обсуждение защищенных операционных систем, включая обсуждение гарантий, можно найти в [25], [59] или [20]. В последующих разделах показывается необходимость этих возможностей путем описания того, как механизмы безопасности прикладного уровня и современные усилия по обеспечению безопасности, использующие их, становятся уязвимыми при их отсутствии.
2.1. Мандатная безопасность
В TCSEC [20] приведено довольно узкое определение мандатной безопасности, которое тесно связано с политикой многоуровневой безопасности Министерства Обороны США. Оно стало общепринятым определением мандатной безопасности. Однако это определение является недостаточным для удовлетворения требованиями ни Министерства Обороны, ни частного производства, т.к. оно игнорирует такие важные качества, как непередаваемость и динамическое разделение обязанностей [12][22]. Вместо этого в данной статье употребляется более общее определение мандатной безопасности, данное в [59], в котором мандатной политикой безопасности считается любая политика, логика и присвоение атрибутов безопасности которой строго контролируются системным администратором политики безопасности. С помощью мандатной безопасности можно реализовать политики безопасности на уровне предприятия. Другие авторы ссылаются на эту концепцию как на недискреционную безопасность в рамках контроля доступа на базе ролевой модели [22] и модели соответствия типов [39][7][13].
Также, как определено в [59], в данной статье используется более общее понятие дискреционной безопасности, при котором дискреционной политикой безопасности считается любая политика, в которой обычные пользователи могут принимать участие в определении функций политики и/или присвоении атрибутов безопасности. В данном случае дискреционная безопасность не является синонимом контроля доступа основанного на идентификаторе; IBAC, равно как и любая другая политика безопасности, может быть либо мандатной, либо дискреционной[58].
Мандатная политика безопасности операционной системы может быть разделена на несколько типов политик, таких как политика контроля доступа, политика использования подсистемы идентификации и аутентификации и политика использования криптографической подсистемы. Мандатная политика контроля доступа определяет каким образом субъекты могут получить доступ к объектам под контролем операционной системы. Мандатная политика использования подсистемы идентификации и аутентификации указывает, какие механизмы идентификации и аутентификации должны быть используется для получения доступа пользователя к системе. А мандатная политика использования криптографической подсистемы указывает, какие криптографические механизмы должны быть использованы для защиты данных в системе. Дополнительно, различные подсистемы операционной системы могут иметь собственные политики использования механизмов данных подсистем. Эти политики могут зависеть от политики использования криптографической подсистемы. Например, политика использования каналов связи маршрутизатором может содержать пункт об обязательном использовании механизма IPSEC ESP [4] в режиме туннелирования перед отправкой во внешнюю сеть закрытой информации. Использование конкретных алгоритмов шифрования для IPSEC ESP может быть регламентировано политикой использования криптографической подсистемы.
Защищенная операционная система должна предоставлять набор средств для задания мандатной политики безопасности операционной системы и перевода этих определений в форму, понятную для низлежащих механизмов обеспечения мандатной безопасности. При отсутствии подобного набора средств не может быть никакой уверенности в том, что механизмы обеспечения мандатной безопасности смогут предоставить желаемые характеристики безопасности. Тем не менее, даже операционная система, предоставляющая мандатную защиту, может "страдать" от наличия высокоскоростных скрытых каналов утечки информации. Это становится большой проблемой всякий раз, когда мандатная политика безопасности используется для обеспечения конфиденциальности (секретности). Однако это не должно становиться причиной игнорирования мандатной безопасности. Даже при наличии скрытых каналов утечки, операционная система, имеющая самые простые мандатные механизмы, повышает уровень безопасности системы, требуя большей квалификации от злоумышленника. Как только операционные системы с простыми мандатными механизмами станут использоваться повсеместно, использование скрытых каналов утечки станет обыденной практикой, что в свою очередь подогреет общественный интерес к необходимости исследования проблемы скрытых каналов в компьютерных системах [57].
В любой системе, поддерживающей мандатную безопасность, существуют набор приложений, которым требуются специальные привилегии для выполнения некоторых функций, связанных с безопасностью. Такие приложения часто называют "доверенными", потому что существует уверенность в том, что они корректно выполнят возложенные на них функции по обеспечению безопасности и не будут использовать во вред привилегии, предоставленные им для выполнения этих функций. Если механизмы мандатной безопасности операционной системы поддерживают только упрощенное разделение привилегий, то безопасность всей системы может свестись к обеспечению безопасности доверенных приложений в операционной системе. Для снижения зависимости от доверенных приложений, механизмы мандатной безопасности операционной системы должны быть спроектированы с учетом поддержки принципа минимальных привилегий. Соответствие типов является примером такого механизма мандатной безопасности, который может быть использован и для ограничения набора привилегий, выделяемого доверенным приложениям для выполнения их функций, и для ограничения возможного ущерба, вызванного любым злоумышленным использованием данных привилегий[48][28].
Механизмы мандатной безопасности операционной системы могут быть использованы для поддержки в приложениях функций, связанных с безопасностью, только в случает строгих гарантий того, что данные механизмы невозможно обойти и обмануть. Например, соответствие типов может быть использовано для реализации защищенных каналов взаимодействия, необходимых для обеспечения такой функциональности. Защищенный канал взаимодействия гарантирует, что данные, передаваемые от определенного отправителя к определенному получателю пройдут через подсистему безопасности, а также он гарантирует целостность самой подсистемы. Большинство требований безопасности таких приложений может быть удовлетворено с помощью низлежащих механизмов мандатной безопасности операционной системы [48].
Механизмы мандатной безопасности операционной системы также могут быть использованы для строгой изоляции приложения в рамках уникального домена безопасности, который тщательно отделен от остальных доменов системы. Даже в этом случае приложение может совершить какие-либо несанкционированные действия, однако возможный ущерб от этих действий будет ограничен рамками одного домена безопасности. Эта ограничивающая функция является очень важной для контроля потоков данных при поддержке политики безопасности системы [33]. В дополнение к поддержке безопасного исполнения ненадежного ПО, ограничивающая функция может поддерживать функциональные требования, такие как изолированная тестовая среда или замкнутая среда разработки [48]. Например, и МЭ Sidewinder и МЭ DTE используют соответствие типов для подобного ограничения [6][12].
Несмотря на то, что кто-то может попытаться навязывать мандатную политику безопасности, используя механизмы дискреционной безопасности, такие механизмы не в состоянии противостоять неаккуратному пользователю или злоумышленнику. Так как дискреционные механизмы безопасности переносят все бремя обеспечения безопасности на пользователя, халатность любого пользователя в любой момент времени может привести к нарушению мандатной политики. В отличии от мандатных механизмов безопасности, которые перекладывают бремя обеспечения безопасности на администратора политики безопасности. При использовании только лишь дискреционных механизмов безопасности, злоумышленник, имеющий доступ к конфиденциальной информации и приложениям, может напрямую раскрыть конфиденциальную информацию в нарушение мандатной политики. Хотя тот же пользователь может также быть способен осуществить утечку конфиденциальной информации путями, не затрагивающими компьютерную систему, сама возможность использования компьютерных каналов утечки информации может увеличить размеры утечки и уменьшить ее обнаружение и прослеживание. В противовес, при наличии мандатных механизмов защиты он бы только смог обеспечить утечку конфиденциальной информации через скрытые каналы, что ограничивает размеры утечки и обеспечивает контроль за ней, при условии аудита скрытых каналов.
Более того, даже с благонадежными и аккуратными пользователями мандатная политика безопасности все еще может быть нарушена некорректным или злоумышленным приложением, в случае если для ее применения используются только дискреционные механизмы . В данном случае разница между некорректным и злоумышленным приложениями не так уж важна. В любом случае приложение может не использовать механизмы безопасности, требуемые мандатной политикой, или использовать их путем, несоответствующим намерениям пользователя. Для обеспечения гарантий того, что механизмы безопасности были использованы правильно и они могут защитить пользователя от случайного запуска ненадежного приложения, необходимо использовать мандатные механизмы защиты. Даже если пользователь тщательно определит все дискреционную политику для корректной реализации мандатной политики, приложение может самостоятельно изменить дискреционную политику без согласования с пользователем. В то время как мандатная политика может быть изменена только лишь системным администратором безопасности.
Даже в случае использования персонального компьютера, на котором пользователь может сам являться администратором политики безопасности системы, мандатные механизмы безопасности все равно полезны в защите от некорректного или злоумышленного ПО. В простейшем случае, когда существует различие только между обычной ролью пользователя и ролью пользователя, как администратора политики безопасности системы, мандатные механизмы защиты могут защитить пользователя от непреднамеренного запуска недоверяемого ПО. При дальнейшем разделении ролей обычного пользователя на набор ролей по функциональному признаку, мандатные механизмы безопасности ограничат размеры ущерба, который может быть нанесен некорректным или злоумышленным ПО.
Несмотря на то, что существует несколько коммерческих операционных систем со встроенными мандатными механизмами безопасности, ни одна из этих систем не нашла широкого применения. Эти системы страдали от ограниченного представления о мандатной безопасности, что ограничивало их рыночную привлекательность. К тому же, в этих системах обычно отсутствовала адекватная поддержка необходимых доверенных приложений. Для достижения более широкого охвата рынка, операционная система должна поддерживать более общее представление о мандатной безопасности и должна предоставлять возможность гибкой настройки мандатных политик.
Широкоиспользумые операционные системы редко поддерживают принцип минимума привилегий, даже в своих архитектурах дискреционного контроля доступа. Многие операционные системы предоставляют только лишь разграничение между полностью привилегированным доменом безопасности и полностью непривилегированным доменом безопасности. Даже в Microsoft Windows NT механизм привилегий не обеспечивает адекватной защиты от злоумышленной программы, потому что он не ограничивает привилегии, которые программа наследует от вызывающего ее процесса, основываясь на степени надежности(доверенности) программы [65].
Современные микроядерные исследовательские операционные системы имеют тенденцию к предоставлению примитивных механизмов защиты, которые могут быть использованы для гибкого построения архитектуры безопасности более высокого уровня. Многие из этих систем, такие как микроядро Fluke [23] и Exokernel [41], используют механизм привилегий, управляемых на уровне ядра ОС, как механизмы защиты нижнего уровня. Впрочем, как обсуждается в [59], типичная архитектура привилегий не является адекватной для обеспечения мандатного контроля доступа с высокой степенью гибкости и гарантий. L4 [38] предоставляет некоторую поддержку мандатного контроля посредством своего механизма "кланов и начальников" и механизма межпроцессных коммуникаций (IPC) для идентификации отправителя и получателя сообщений, но все же не имеет согласованного набора инструментов для использования этих механизмов, чтобы они удовлетворяли требованиям мандатной политики. К тому же L4 предполагает, что будет использовано только небольшое количество отдельных доменов безопасности [38]. Flask [56], как вариант микроядра Fluke, предоставляет базовые механизмы мандатной безопасности, аналогичные DTOS [43], варианта микроядра Mach; обе системы предоставляют механизмы для обеспечения мандатного разграничения доступа и поддержки мандатной политики безопасности.
2.2. Надежный путь доступа
Надежный путь доступа - это механизм, посредством которого пользователь может взаимодействовать с доверенным ПО напрямую, и который может быть активирован либо пользователем либо доверенным ПО, но не может быть воспроизведен каким либо другим ПО [28]. При отсутствии механизма надежного пути доступа, злоумышленное ПО может выдать себя за доверенное ПО пользователю или выдать себя за пользователя для доверенного ПО. Такое злоумышленное ПО потенциально может получить доступ к конфиденциальной информации, совершать действия от лица пользователя, нарушающие намерения пользователя, или обманывать пользователя, заставляя его думать, что запрошенная функция выполнена, в то время как она не вызывалась. В дополнение к поддержке доверенного ПО в базовой системе, механизм надежного пути доступа должен быть расширяемым для поддержки последующих добавлений доверенных программ системным администратором политики безопасности [28].
Концепция надежного пути доступа может быть обобщена и подразумевать не только взаимодействия непосредственно между пользователями и доверенным ПО. Надежный сетевой канал (Trusted Network Interface - TNI) представляет концепцию надежного(безопасного) канала связи между доверенным ПО на различных узлах сети [44]. В общем, механизм, который гарантирует взаимно-аутентифицирующий канал связи, защищенный туннель, необходим для обеспечения того, что важные системные функции не будут введены в заблуждение. Несмотря на то, что механизм защищенного канала связи для взаимодействия внутри СВТ может быть построен на прикладном уровне без прямого прямой поддержки аутентификации на уровне операционной системы, все же для операционной системы желательно предоставлять собственные механизмы защищенных каналов связи, так как такие механизмы проще проверить [59] и они, скорее всего, более эффективны.
В большинстве широкоиспользуемых коммерческих операционных систем поддержка как механизма надежного пути доступа, так и защищенного канала связи, отсутствует. Microsoft Windows NT предоставляет поддержку надежного пути доступа для маленького подмножества функций, таких как аутентификация при регистрации в системе и смена пароля, но она не поддерживает расширение этого механизма для других доверенных программ [65]. При локальном взаимодействии, NT предоставляет серверам идентификационную информацию о клиентах, однако она не предоставляет клиентам идентификационную информацию о серверах.
В этом разделе аргументировано показано, что при отсутствии в операционной системе поддержки механизмов мандатного контроля доступа и надежного пути доступа, механизмы контроля доступа и криптографической защиты прикладного уровня не могут быть реализованы безопасно. Эти аргументы далее будут использованы для возобновления дискуссии в разделе 4, в котором проанализированы конкретные примеры.
3.1 Контроль доступа
Механизмы контроля доступа прикладного уровня могут быть разбиты на две компоненты - перехватывающую и решающую. Когда субъект пытается осуществить доступ к объекту, защищенному этим механизмом, перехватывающая компонента должна вызвать решающую компоненту, передав ей соответствующие входные параметры для принятия решения в соответствии с политикой безопасности, и должна претворить в жизнь принятое решение. Обычным примером необходимых входных параметров являются атрибуты безопасности субъекта и объекта. Решающая компонента может также запрашивать другие внешние источники для принятия решения в соответствии с политикой безопасности. Например, она может использовать внешнюю базу данных политики безопасности и системную информации, такую как текущее время.
Если программа-агент злоумышленника сможет влиять на любую компоненту механизма контроля доступа или на входные данные для механизма принятия решения, то программа-агент злоумышленника может нарушить работу всего механизма контроля доступа. Даже если все компоненты и все входные данные механизма контроля доступа расположены в рамках одного файла, все равно целостность файла зависит от механизмов защиты операционной системы. Как уже обсуждалось в предыдущем разделе, только мандатные механизмы безопасности могут четко предоставить гарантии обеспечения целостности. Даже при наличии строгих гарантий обеспечения целостности входных данных политики безопасности, если авторизованный пользователь запускает злоумышленное ПО, оно может изменить атрибуты безопасности какого-либо объекта или правила политики безопасности без уведомления или согласования с пользователем. Механизму контроля доступа необходимо использование механизма надежного пути доступа, предоставляемого операционной системой, для того, чтобы гарантировать, что случайное распространение(передача) прав доступа пользователя не может быть произведена без явного согласования с пользователем.
Если программа-агент злоумышленника сможет выдать себя за решающую компоненту и таким образом обмануть перехватывающую компоненту, или если программа-агент злоумышленника подменить источник данных для принятия решения, тогда программа-агент злоумышленника может нарушить работу всего механизма. Если любая из компонент механизма или внешние источники данных для принятия решения расположены не в рамках одного приложения, то механизму контроля доступа требуется использовать механизм надежного пути доступа.
Если программа-агент злоумышленника сможет обойти перехватывающую компоненту, тогда нарушить работу механизма контроля доступа еще проще. Механизмы мандатной безопасности операционной системы могут быть использованы для гарантирования того, что все попытки доступа к защищаемым объектам проходят через перехватывающую компоненту.
3.2 Криптография
Анализ криптографической защиты на прикладном уровне может быть разбит на анализ вызова механизма криптографической защиты и анализ самого механизма. Анализ, приведенный в этом подразделе, является компиляцией дискуссий из [51][15] [60][61][55][52].
Как отправную точку обсуждения представим, что механизм криптографической защиты является аппаратным и реализует все необходимые криптографические функции корректно, а также что существуют защищенные методы, с помощью которых криптографические ключи помещаются в это устройство. Даже в этом упрощенном варианте, когда конфиденциальность и целостность алгоритмов и ключей достигается без поддержки операционной системы, все еще существуют угрозы безопасности, описанные далее, которые эффективно обходятся только с помощью возможностей, предоставляемых защищенными операционными системами.
Одной из угроз безопасности в этом простом случае является отсутствие гарантий использования аппаратного шифратора. Любая законная попытка использования шифратора может не привести к обращению к шифратору. Приложение, осуществляющее вызовы криптографических функций, может быть обойдено или модифицировано злоумышленным ПО или пользователем. Злоумышленное ПО может выдавать себя за шифратор приложению, обратившемуся к нему.
Мандатная безопасность и механизм надежного пути доступа в операционной системе противостоят этой угрозе. Механизмы мандатной безопасности могут быть использованы для гарантирования того, что приложение, которое обращается к аппаратному шифратору, невозможно обойти и оно устойчиво к некорректным воздействиям как злоумышленного ПО так и пользователей. Невозможность обхода может быть достигнута путем использования встроенного аппаратного шифратора, который физически встраивается между источником и приемником защищаемых данных; тем не менее, это решение менее гибкое. Механизм надежного пути доступа может быть использован для гарантирования того, что злоумышленное ПО не сможет выдать себя за шифратор вызывающему приложению.
Злоупотребление аппаратным шифратором является второй возможной угрозой в простейшем случае. Злоупотребление включает в себя использование сервиса, алгоритма, сессии или ключа неавторизованным приложением. Без поддержки идентификации вызывающих абонентов со стороны операционной системы, аппаратный шифратор может сделать гораздо больше, чем просто потребовать от пользователя инициализировать его, после чего он любой сервис, алгоритм, сессия или ключ, авторизованные для этого пользователя, могут быть использованы любым приложением в системе. В этом случае, аппаратным шифратором может воспользоваться злоумышленное приложение, действующее от лица авторизованного пользователя. Более того, если аппаратный шифратор не имеет прямого физического интерфейса для активации пользователем, злоумышленное ПО может выдать себя за шифратор для пользователя, получить аутентификационную информацию и в последствии активировать аппаратный шифратор без уведомления или запроса пользователя. Даже при наличии прямого физического интерфейса с пользователем, аппаратный шифратор не имеет возможности запрашивать у пользователя подтверждения каждой криптографической операции.
Эта вторая угроза может быть предотвращена путем использования функций мандатной безопасности, надежного пути доступа и защищенного канала связи операционной системы. Механизм надежного пути доступа устраняет необходимость в отдельных физических интерфейсов для активизации шифратора. Защищенный канал связи позволяет аппаратному шифратору идентифицировать своих абонентов и обеспечивает более гибкий контроль за использованием его сервисов, алгоритмов, сессий и ключей. В качестве альтернативы, вместо того, чтобы шифратор разбирался в контролировании своего использования, для этого также могут быть использованы механизмы мандатной безопасности. Например, механизмы мандатной безопасности могут быть использованы для выделения аппаратного шифратора для использования только приложениями, запущенными тем пользователем, который активизировал устройство. Более того, механизмы мандатной безопасности могут снизить риск возможности использования аппаратного шифратора злоумышленным ПО, а следовательно они могут ограничить применение механизма надежного пути доступа только исключительно важными действиями.
Следовательно, даже в простейшем случае, свойства защищенных операционных систем помогают противостоять угрозам, возникающим при шифровании на прикладном уровне. В заключение, предположения простейшего случая отбрасываются, и изучаются возникающие при этом угрозы.
Если предположение о том, что начальные ключи передаются в устройство шифрования безопасным образом, откинуть, то появляется дополнительная угроза того, что ключи могут стать доступны на чтение или модификацию неавторизованному субъекту(пользователю или программе). Если начальные ключи передаются не по специально выделенному физическому каналу в аппаратный шифратор, то операционная система должна обеспечить защищенный канал связи между источником начальных ключей и аппаратным шифратором, а также обеспечить защиты самого источника начальных ключей. Механизмы мандатной безопасности могут быть использованы тщательной защиты канала и источника ключей. Надежный путь доступа может потребоваться при введении начальных ключей.
Если отбросить предположение о том, что криптографический механизм ограничен использованием только аппаратного шифратора, а вместо этого он реализован на программном уровне, конфиденциальность и целостность криптографического механизма становиться зависимой от операционной системы, от ее возможностей по защите оперативной памяти и внешней памяти. Для обеспечения конфиденциальности и целостности этого механизма необходимо применение мандатной защиты. Если криптографическим механизмом используются несколько внешних источников данных, например начальные значения для генератора псевдослучайных чисел, то источники входных данных и сами каналы передачи данных между источниками данных и криптографическим механизмом должны быть защищены с помощью мандатных механизмов безопасности.
4.1 Мобильный код
В настоящее время разработано несколько независимых решений для WWW, каждое со своей моделью защиты, обеспечивающих защиту от угроз злоумышленного мобильного кода. Тем не менее, системы, использующие эти решения, все равно остаются уязвимы из-за недостаточно поддержки функций безопасности со стороны операционной системы. В основном в данном разделе пояснение этой точки зрения сосредотачивается на анализе попыток обеспечения безопасности языка Java [27], но другие достижения также будут рассматриваться для выделения проблем.
Основной угрозой, с которой пытаются бороться все существующие решения, является угроза получение злоумышленным мобильным кодом несанкционированного доступа к файлам и ресурсам пользователя с целью нарушения целостности или конфиденциальности. Эта угроза не ограничивается только интерпретируемыми апплетами, загружаемыми из сети веб-броузером; в докладах [26] и [30] эта модель угроз распространяется на вспомогательные приложения, которые могут активно устанавливаться пользователем. Разница между мобильным кодом и тем, что обычно называют данными, невелика. Например, представьте себе, что документ в формате Postscript на самом деле является программой с потенциальной возможностью доступа к локальной файловой системе. Соответственно, вспомогательные приложения, которые работают с ненадежными данными, такие как просмотрщики Postscript документов, либо должны исполняться в ограниченном режиме использования, либо должны быть тщательно ограничены операционной системой.
Базовая модель безопасности Java основана на концепции "песочницы". Система полагается на безопасность использования типов в языке совместно с менеджером безопасности Java для предотвращения несанкционированного доступа [27]. В настоящее время предпринимаются усилия по добавлению дополнительных функций безопасности в Java, таких как привилегии, расширенная модель контроля доступа, или дополнительный контроль надо доступом к определенным библиотекам классов [70]. Фундаментальным ограничением этих подходов является то, что ни один из них не гарантирует невозможность обмана или обхода. Например, несмотря на то, что сам язык Java якобы является безопасным, виртуальная машина Java (JVM) исполнит код, который будет нарушать семантику языка и может привести к нарушениям безопасности [32]. Ошибки в реализации JVM привели к нарушениям семантики языка [19]. Значительная часть системы Java сейчас существует в виде "родных" методов, реализованных в виде объектного кода (для конкретной платформы) и не подлежат проверке соответствия типов данных со стороны JVM. JVM не может защитить себя от воздействия других приложений. Наконец, модель безопасности Java не может предоставить никакой защиты от многих других форм злоумышленного мобильного кода. В докладе [30] авторы ссылаются на защищенные системы, в которых содержаться решения, противостоящие угрозам, представленным кодом, не написанном Java. Даже если бы проблемы с JVM не существовало, эти решения по обеспечению безопасности все равно будут страдать от фундаментального ограничения, в соответствии с которым они полагаются на обеспечение безопасности с помощью контроля доступа на прикладном уровне. Они все зависят от локальной файловой системы, сохраняющей целостность кода системы, включая файлы классов. Все системы, хранящие политику безопасности локально, зависят от контроля доступа к файлам файловой системы, сохраняющей целостность файлов политики. В разделе 3.1 показана важность свойств защищенной операционной системы для поддержки контроля доступа на прикладном уровне.
Другим популярным способом "обезопасить" мобильный код является цифровая подпись апплетов и ограничение их исполнения только теми, которые получены из доверенных источников [27]. В сущности, собственная безопасность ActiveX полностью основана на цифровых подписях, так как оно не имеет механизмов контроля доступа ни в какой из форм [24][27]. Основной уязвимость этого подхода является позиция "все или ничего"; пользователь не может поместить собственные механизмы контроля доступа ActiveX в ограниченных домен безопасности. Для этой цели могут быть использованы механизмы мандатной безопасности операционной системы, с помощью которых можно ограничить действия броузера в рамках определенного домена безопасности.
Обратите внимание на то, что хотя цифровые подписи не являются самодостаточными, они играют важную роль в обеспечении безопасности мобильного кода, даже в защищенных операционных системах. Они могут уменьшить риск попадания злоумышленного кода в систему, предоставляя некоторый уровень гарантий того, что апплет будет функционировать корректно, а также предоставляя дополнительную информацию для принятия решения о предоставлении доступа. Тем не менее, так же как и в случае с криптографической подсистемой прикладного уровня, описанной в подразделе 3.2, механизм проверки цифровых подписей зависит от свойств защищенной операционной системы, гарантирующей правильный вызов, обеспечивающей целостность механизма проверки и целостность хранящихся локально открытых ключей.
Необходимость в наличии механизма надежного пути доступа была освещена в [67], где продемонстрирована легкость, с которой троянский апплет может перехватить номера кредитных карт, PIN-коды или пароли, великолепно эмулируя диалоговую форму графической оконной системы. Предлагаемым решением было специально организованный механизм надежного пути доступа на прикладном уровне, который требовал от пользователя переделать диалоговую форму с использованием собственных сложных графических шаблонов. Однако это решение не является адекватным, ибо только увеличивает уровень "интеллекта" требуемого от троянского коня.
В других системах предпринимались попытки предоставить альтернативные безопасные решения для угроз мобильного кода. Система Janus [26] помещает себя в системные вызовы Solaris для ограничения действий родных ненадежных приложений, а Safe-Tcl [49] предоставляет "безопасный интерпретатор", который делает попытку ограничить набор команд, доступных для ненадежного кода. Однако, так же как и в случае решениями по безопасности с Java, все эти системы содержат ту же уязвимость, что и любой другой механизм контроля доступа прикладного уровня; соответственно они нуждаются в поддержке со стороны защищенной операционной системы.
После того как все системы мобильного кода, описанные выше, приспособлены функционировать безопасно, защищенная система может также упростить их. Вместо того, чтобы реализовывать свои примитивы безопасности на прикладном уровне, где они являются уязвимыми, они могут использовать сервисы защищенной системы, получив в итоге систему более защищенную. Правильно разработанная защищенная система предоставит гибкую и практичную базу с одной используемой непротиворечивой моделью безопасности для различных виртуальных машин.
4.2 Kerberos
Kerberos [31][47] - это сетевой сервис аутентификации, первоначально разработанный в MIT в рамках проекта Athena. В дополнение к предоставлению сервиса аутентификации, Kerberos поддерживает создание ключей сессии для обеспечения сетевых сервисов конфиденциальности и целостности. Производные от Kerberos использовались для предоставление сервисов аутентификации и создания ключей в AFS [64], DCE [53], и ONC RPC [21]. Kerberos и системы, основанные на Kerberos, предлагаются как средство обеспечения безопасности в World Wide Web [18][36][37].
Kerberos основан на использовании симметричного шифрования с доверенным центром распределения ключей (KDC) для каждого домена(группы узлов сети). KDC Kerberos имеет доступ ко всем секретным ключам каждого субъекта своего домена. Соответственно компрометация KDC может быть катастрофой. Обычно данную проблему прикрывают требованием обеспечения физической безопасности выделенного узла сети для KDC, на котором функционирует только сервис аутентификации Kerberos [46]. Обычно в системах, использующих Kerberos, также применяются выделенные узлы с обеспеченной физической безопасностью. Без этих допущении о среде функционирования, сервису аутентификации Kerberos и серверным приложениям, которые его используют, потребуются свойства защищенных операционных систем, для строго гарантирования их устойчивости к внешним воздействиям и невозможности обхода. Для аргументирования, далее в разделе данные допущения будут приниматься как верные и обсуждение будет сфокусировано только на безопасности клиентских рабочих станций.
Kerberos был спроектирован для сред, в которых клиентские рабочие станции и сеть являются абсолютно ненадежными [10][45]. Тем не менее, так как ПО клиентской рабочей станции является посредником всех взаимодействий между пользователем и серверным приложением, пользующимся сервисом Kerberos, это предположение подразумевает, что серверное приложение, пользующееся сервисом Kerberos, должно рассматривать все клиентские приложения как потенциально злоумышленное ПО. Более того, серверное приложение, пользующееся сервисом Kerberos, не имеет никаких возможностей для порождения надежного пути доступа для пользователя на клиентской рабочей станции, так как это бы потребовало наличие доверенного кода на клиентской рабочей станции. Поэтому, в системах, использующих Kerberos, злоумышленное ПО, запущенное пользователем, может совершенно свободно произвольным образом модифицировать или передавать третьим лицам информацию пользователя без каких либо ограничений; выделить различие между законным запросом пользователя и запросом злоумышленного ПО не представляется возможным. Учитывая возрастающую легкость, с которой злоумышленное ПО может быть привнесено в систему, модель среды Kerberos кажется непригодной для использования. Как указано в [14], защищенные транзакции между конечными абонентами требуют наличия доверенного кода на обоих концах канала связи.
За основу дальнейшей дискуссии возьмем предположение о том, что на клиентской рабочей станции существует некий базовый набор доверенного ПО, который защищен от внешних воздействий, но операционная система на клиентской рабочей станции не содержит механизмов мандатной безопасности и надежного пути доступа. К тому же предположите, что клиентская рабочая станция является однопользовательской системой, непредоставляющей никаких сервисов другим системам. Несмотря на эти допущения, пользователь все еще уязвим для атак со стороны злоумышленного ПО, такого как мобильный код, полученный пользователем из сети.
Если злоумышленное ПО сможет выдать себя пользователю за клиентскую часть аутентификационной программы, тогда оно сможет получить пароль пользователя. Даже при применении одноразовых паролей эта атака даст возможность злоумышленному ПО действовать от имени пользователя в течении сеанса работы. Для предотвращения осуществления подобной атаки необходимо применение механизма надежного пути доступа в операционной системе клиентской рабочей станции. Дополнительно, подобный механизм надежного пути доступа в комбинации с поддержкой сетевого защищенного канала связи могут быть использованы для предоставления надежного пути доступа между пользователями и серверными приложениями.
Если злоумышленное ПО имеет доступ на чтение к файлам, используемым клиентским ПО Kerberos для хранения билетов и ключей сессий, то злоумышленное ПО может прямо выдавать себя за пользователя серверным приложениям, пользующимся сервисом Kerberos. Даже если ключи сессии помещены в аппаратный шифратор, злоумышленное ПО может обратиться к аппаратному шифратору от имени пользователя, используя уязвимость неправомерного использования, обсуждавшуюся в подразделе 3.2. Механизмы мандатной безопасности могут быть использованы для тщательной защиты и файла и аппаратного шифратора от доступа со стороны злоумышленного ПО.
4.3 Сетевые протоколы обеспечения безопасности
Сетевые протоколы обеспечения безопасности IPSEC [5][3][4] используются для предоставления сервисов аутентификации, конфиденциальности и целостности на уровне протокола IP. Типичные реализации этого протокола основываются на серверах управления ключами прикладного уровня, которые используются для обмена и создания ключей для защищенных объединений. Модуль IPSEC в сетевом стеке взаимодействует с локальным сервером управления ключами посредством обращения из ядра к приложению для получения необходимой информации.
SSL [69] является другим сетевым протоколом обеспечения безопасности, который предоставляет сервисы аутентификации, целостности и конфиденциальности, а также сервис установления сессионных ключей и алгоритмов шифрования. Однако, SSL реализован полностью на прикладном уровне и не требует модификации ядра. SSL реализован в библиотеке, которая вклинивается в вызовы гнезд для включения протокола SSL между нижележащим протоколом транспортного уровня гнезда (например, TCP) и протоколом прикладного уровня (например, HTTP).
Из-за того, что IPSEC использует криптографические сервисы прикладного уровня, используемый им сервер управления ключами подвержен уязвимостям, описанным в подразделе 3.2, и нуждается в механизмах мандатной безопасности в операционной системе для реализации адекватной защиты. В свою очередь, так как защита, предоставляемая IPSEC, зависит от защиты ключей, то наличие мандатных механизмов защиты в операционной системе так же является критичным для удовлетворения требованиям безопасности IPSEC. А поскольку реализация SSL полностью работает на прикладном уровне, она целиком и полностью подвержена уязвимостям, описанным в подразделе 3.2, и нуждается в механизмах мандатной безопасности в операционной системе для реализации адекватной защиты.
И IPSEC и SSL предназначаются для создания защищенных туннелей. Тем не менее, как отмечено в [14], защищенное взаимодействия между конечными абонентами требует наличия защищенных конечных точек доступа. Если атакующий сможет проникнуть в одну из точек доступа, и получить прямой доступ к незащищенным данным, тогда защита, предоставляемая IPSEC и SSL является лишь иллюзией.
4.4 Межсетевые экраны
Межсетевой экран представляет собой механизм, определяющий зону доверия между двумя сетями. Анализ, представленный в этом подразделе, основан на обсуждениях в [17][9][11][6]. Обычно, межсетевые экраны используются для поддержания разделения между внутренними и наружными вычислительными ресурсами предприятия или организации. Внутренние межсетевые экраны также могут быть использованы для разделения между различными группами внутренних пользователей, или для дополнительного рубежа защиты против внешнего врага.
Современная архитектура межсетевых экранов обычно содержит использование бастионного узла; в архитектуре экранированных подсетей могут использоваться бастионный узел на внешней границе сети, который полностью открыт для внешних пользователей, и внутренний бастионный узел во внутренней сети, который открыт внешнему бастионном узлу. Безопасность бастионного узла является критичной для безопасности, предоставляемой межсетевым экраном. Для уменьшения риска бастионные узлы являются выделенными серверами, предоставляющими только минимально необходимый набор сервисов. Даже в таких минимальных конфигурациях при наличии уязвимости в прокси-серверах возможен взлом бастионного узла. Тем не менее, мандатные механизмы безопасности в операционной системе бастионного узла могут быть использованы для огранчения возможностей прокси-серверов таким образом, что последствия взлома будут сильно ограничены. Таким же образом мандатным механизмы безопасности могут быть использованы для защиты прокси-серверов от внешних воздействия.
Межсетевые экраны не предоставляют никакой защиты от внутреннего злоумышленника. Обычно внутренние пользователи могут с легкостью передать информацию через межсетевой экран. Внутренние злоумышленники могут также создать каналы, которые позволят внешним злоумышленникам производить внутренние запросы через межсетевой экран, или предоставить путь полного обхода межсетевого экрана. Дополнительно, внутренние злоумышленники могут получить доступ к данным, которыми обмениваются пользователи, до межсетевого экрана (во внутренней сети). Несмотря на то, что для разграничения пользователей на несколько групп по степени доверия могут быть использованы внутренние межсетевые экраны, степень детализации подобной защиты довольно ограничена по сравнению с той, которую может предоставить защищенная операционная система.
Возможность внутреннего злоумышленника передать информацию через межсетевой экран может быть ограничена с помощью механизмов мандатной безопасности в операционной системе внутреннего узла сети. Таким же образом мандатные механизмы безопасности в операционной системе внутреннего узла могут ограничить внешних пользователей, выполняющих внутренние запросы через каналы, созданные внутренними злоумышленниками в домены безопасности, в которых внутреннему злоумышленнику разрешено работать.
В дополнение к угрозе внутреннего злоумышленника, межсетевой экран находится под угрозой злоумышленного ПО, запущенного благонадежным внутренним пользователем. Обычно межсетевые экраны не требуют от внутренних пользователей строгой аутентификации при запросах к внешним сервисам через межсетевой экран [40]. Поэтому, если злоумышленное ПО на внутреннем узле сети запускает благонадежный пользователь, злоумышленное ПО может осуществлять поиск бреши в защите межсетевого экрана таким же образом, как если бы оно было запущено внутренним злоумышленником. Пример использования злоумышленного Java-апплета, позволяющего внешним злоумышленникам проникнуть через межсетевой экран приведен в [40]. Даже если внутренние пользователи обязаны проходить процедуру строгой аутентификации на межсетевом экране, благонадежный внутренний пользователь все равно может запустить троянскую программу, чьей явной целью является доступ к внешним ресурсам; в этом случае злоумышленное ПО так же может обойти защиту межсетевого экрана.
Использование мандатных механизмов защиты в операционной системе внутренних узлов сети может быть применено для защиты пользователей от запуска злоумышленного ПО или ограничения деятельности этого ПО, если оно запущено. Если доступ к внешним ресурсам требует прохождения процедуры строгой аутентификации, то мандатные механизмы защиты могут быть использованы для обеспечения гарантий того, что только доверенное ПО внутреннего узла сети может взаимодействовать с механизмом строгой аутентификации межсетевого экрана. В любом случае, мандатные механизмы безопасности ограничат возможности злоумышленного ПО по утечке информации или поддержки внешних вызовов.
Межсетевые экраны также поддаются атакам с использованием неверных данных [62]. Некоторые примеры атак с использованием неверных данных, относящихся к межсетевым экранам, описаны в [68][40][16]. Так же как и в случае с внутренним злоумышленником или злоумышленным ПО, мандатные механизмы безопасности в операционной системе на бастионном узле и на внутренних узлах сети могут быть использованы для ограничения атак с использованием неверных данных.
Если межсетевым экраном поддерживаются входящие запросы к внутренним сервисам, то межсетевой экран сам по себе не может защитить удаленную систему от взлома. Операционная система удаленного узла должна обеспечивать защиту от неправильного использования доступных снаружи сервисов, а так же любую информацию, полученную с помощью этого сервиса, от утечки. Для обеспечения подобной защиты могут быть использованы мандатным механизмы защиты операционной системы удаленного узла. Дополнительно, мандатные механизмы защиты операционной системы внутреннего узла сети должны быть использованы для пресечения любой атаки со стороны взломанной удаленной системы.
Когда благонадежный внутренний пользователь хочет получить безопасный доступ к удаленном у сервису, межсетевой экран сам по себе не может предоставить полную защиту при использовании удаленного сервиса. Операционная система внутреннего узла сети должна защищать клиента от любых попыток со стороны сервера использовать полномочия клиента не по назначению, так как в случае с броузером, который исполняет злоумышленный апплет, полученный с сервера; для ограничения таких клиентских приложений могут быть использованы механизмы мандатной безопасности операционной системы внутреннего узла сети.
Ни одно из существующих технических решений в области безопасности не может обеспечить полную безопасность системы; необходимо достигнуть определенного баланса в использовании механизмов безопасности. Каждый механизм обеспечения безопасности предоставляет набор специфических функций и должен быть разработан только для выполнения этих функций. Он может опираться на другие механизмы и необходимые сервисы безопасности. В защищенной системе весь набор механизмов дополняет друг друга, таким образом вместе образуя полный комплект программ обеспечения безопасности. Системы, в которых данный баланс не достигнут, останутся уязвимыми.
Как уже указывалось в данной статье, защищенная операционная система является важным и необходимым звеном на пути к разрешению вопроса полной безопасности системы, но она не является единственным звеном. Высоко-защищенная операционная система не будет эффективной без подсистемы безопасности прикладного уровня, построенной на ее основе. Некоторые проблемы на самом деле лучше разрешаются на уровне выше операционной системы. Одним из таких примеров являются системы электронной торговли, которые требуют наличия цифровой подписи каждой из транзакций. Криптографический механизм прикладного уровня в системе транзакций, защищенной с использованием свойств защищенных операционных систем, возможно является наилучшим решение по обеспечению безопасности.
Ни один из механизмов обеспечения безопасности не способен обеспечить полную защиту в одиночку. Неразрешенные технические проблемы, ошибки реализации и неверные предположения о среде функционирования приведут в результате к остаточным уязвимостям. Например, скрытые каналы остаются серьезной технической проблемой для разработчиков защищенных операционных систем. Эти ограничения должны быть осмыслены и предприняты соответствующие меры для внедрения дополнительных механизмов, разработанных для корректировки данной проблемы. В случае со скрытыми каналами необходимо применять аудит и механизмы обнаружения для минимизации шансов того, что кто-то воспользуется известными каналами утечки. Аудит и детекторы в свою очередь должны зависеть от защищенной операционной системы, обеспечивающей защиту таких важных компонентов, как журналы регистрации событий и датчики вторжения, так как они являются объектом тех же типов уязвимостей, которые обсуждались в данной статье.
В данной статье приведены аргументы, указывающие на то, что угрозы, создаваемые современными компьютерными средами, не могут быть нейтрализованы без использования защищенных операционных систем. Были разъяснены такие важные свойства операционной системы, как мандатная безопасность и надежный путь доступа, и сопоставлены с неадекватностью механизмов защиты современных широкоиспользуемых операционных систем. В данной статье определены уязвимости, которые появляются в механизмах криптографической защиты и разграничения доступа прикладного уровня, а также показано, как мандатные механизмы защиты и надежный путь доступа справляются с этими уязвимостями. Для того, чтобы представить четкое восприятие необходимости этих свойств в операционных системах, в данной статье были проанализированы конкретные примеры современных подходов к обеспечению безопасности и показано, что уровень безопасности, предоставляемый этими подходами, не является адекватным при отсутствии таких свойств. Наконец, читателю был представлен перспективный путь развития безопасности систем, в котором и защищенные операционные системы, и механизмы безопасности прикладного уровня должны дополнять друг друга, для достижения требуемого уровня защиты.
Утверждая, что защищенные операционные системы являются обязательными для обеспечения безопасности системы, авторы надеются породить возрождающийся интерес к обеспечению защиты в операционной системе. Если бы профессионалы в области защиты более открыто признавали зависимость их решений по обеспечению безопасности от операционных систем и выдвигали эти зависимости в качестве требований к будущим операционным системам, тогда возросшая потребность в защищенных операционных системах приведет к новым исследованиям и разработкам в этой области и конечном счете к коммерчески жизнеспособным защищенным системам. В свою очередь, наличие защищенных операционных систем позволит профессионалам в области защиты сосредоточиться на сервисах защиты, подходящих для их специфических компонент, а не обрекая их на попытки решить проблему обеспечения полной защиты без каких-либо шансов на успех.
[1] M. Abrams et al, Information Security: An Integrated Collection of Essays, IEEE Comp. 1995.
[2] J. Anderson, Computer Security Technology Planning Study [PDF 7,893K], Air Force Elect. Systems Div., ESD-TR-73-51, October 1972.
[3] R. Atkinson. IP Authentication Header (AH) [TXT 30K]. IETF RFC 1826, August 1995.
[4] R. Atkinson. IP Encapsulating Security Payload (ESP) [TXT 30K]. IETF RFC 1827, August 1995.
[5] R. Atkinson. Security Architecture for the Internet Protocol [TXT 55K]. IETF RFC 1825, August 1995.
[6] Badger et al. DTE Firewalls, Initial Measurement and Evaluation Report. Trusted Information Systems Technical Report #0632R, March 1997.
[7] L. Badger et al. Practical Domain and Type Enforcement for UNIX. Proceedings of IEEE Symposium on Security and
Privacy, May 1995.
[8] D. Baker. Fortresses Built Upon Sand. Proceedings of the New Security Paradigms Workshop, 1996.
[9] S. Bellovin and W. Cheswick. Network Firewalls. IEEE Communications, September 1994.
[10] S. Bellovin and M. Merritt. Limitations of the Kerberos Authentication System. Computer Communications Review 20(5), October 1990.
[11] B. Blakley. The Emperor's Old Armor. Proceedings of the New Security Paradigms Workshop, 1996.
[12] W. Boebert and R. Kain, A Further Note on the Confinement Problem. Proceedings of the 30th IEEE International Carnahan Conference on Security Technology, 1996.
[13] W. Boebert and R. Kain. A Practical Alternative to Hierarchical Integrity Policies. Proceedings of the 8th National Computer Security Conference, 1985.
[14] E. Brewer at al. Basic Flaws in Internet Security and Commerce. http://http.cs.berkeley.edu/~gauthier/endpoint-security.html, 1995.
[15] W. Brierley. Integrating Cryptography into Trusted Systems: A Criteria Approach. Proceedings of the 8th IEEE Conference on Computer Security Applications, 1992.
[16] Computer Emergency Response Team. Advisory 93:16.
[17] D. Chapman and E. Zwicky. Building Internet Firewalls. O'Reilly, 1995.
[18] D. Davis. Kerberos Plus RSA for World Wide Web Security. Proceedings of the 1st USENIX Workshop on Electronic Commerce, July 1995.
[19] D. Dean et al. Java Security: From HotJava to Netscape and Beyond. Proceedings of the IEEE Symposium on Security and Privacy, 1996.
[20] DOD 5200.28-STD. Department of Defense Trusted Computer System Evaluation Criteria, December 1985.
[21] M. Eisler et al. Security Mechanism Independence in ONC RPC. Proceedings of the 6th USENIX UNIX Security Symposium, July 1996.
[22] D. Ferraiolo and R. Kuhn. Role-Based Access Control. Proceedings of the 15th National Computer Security Conference, 1992.
[23] B. Ford et al. Microkernels Meet Recursive Virtual Machines. Proceedings of 2nd USENIX Symposium on Operating Systems Design and Implementation, October 1996.
[24] S. Garfinkel. Web Security and Commerce. O'Reilly & Associates, Cambridge, 1997.
[25] M. Gasser. Building a Secure Computer System. Van Nostrand Reinhold Company, New York, 1988.
[26] I. Goldberg et al. A Secure Environment for Untrusted Helper Applications [PS 173K]. Proceedings of 6th USENIX Unix Security Symposium, July 1996.
[27] L. Gong. Java Security: Present and Near Future. IEEE Micro, May/June 1997.
[28] R. Graubart. Operating System Support for Trusted Applications. Proceedings of the 15th National Computer Security Conference, 1992.
[29] M. Harrison et al. Protection in Operating Systems. Communications of the ACM 19(8), August 1976.
[30] T. Jaeger et al. Building Systems that Flexibly Control Downloaded Executable Content. Proceedings of the 6th USENIX Security Symposium, July 1996.
[31] J. Kohl and C. Neuman. The Kerberos Network Authentication Service V5 [TXT 268K]. IETF RFC 1510, September 1993.
[32] M. Ladue. When Java Was One: Threats from Hostile Byte Code. Proceedings of the 20th National Information Systems Security Conference, 1997.
[33] B. Lampson. A Note on the Confinement Problem. Communications of the ACM 16(10), 1973.
[34] B. Lampson et al. Authentication in Distributed Systems: Theory and Practice. Proceedings of the 13th ACM Symposium on Operating Systems Principles, 1992.
[35] J. Lepreau et al. The Persistent Relevance of the Local Operating System to Global Applications. Proceedings of the 7th ACM SIGOPS European Workshop, September 1996.
[36] S. Lewontin. The DCE-Web Toolkit. Proceedings of the 3rd International World Wide Web Conference, 1995.
[37] S. Lewontin and M. Zurko. The DCE Web Project: Providing Authorization and Other Distributed Services to the World Wide Web. Proceedings of the 2nd International World Wide Web Conference, 1994.
[38] J. Liedtke. L4 Reference Manual. Research Report RC 20549, IBM T. J. Watson Research Center, September 1996.
[39] T. Linden. Operating System Structures to Support Security and Reliable Software [PDF 3,424K]. ACM Computing Surveys 8(4), Dec. 1976.
[40] D. Martin et al. Blocking Java Applets at the Firewall. Proceedings of the Internet Society Symposium on Network and Distributed Systems Security, 1997.
[41] D. Mazieres and M. Kaashoek. Secure Applications Need Flexible Operating Systems. Proceedings of the 6th Workshop on Hot Topics in Operating Systems, May 1997.
[42] A. Medvinsky et al. Public Key Utilizing Tickets for Application Servers. IETF Draft Jan 1997 expires July 1997.
[43] S. Minear. Providing Policy Control Over Object Operations in a Mach Based System. Proceedings of the 5th USENIX Security Symposium, April 1995.
[44] NCSC-TG-005. Version 1. NCSC Trusted Network Interpretation, July 1987.
[45] C. Neuman and J. Steiner. Authentication of Unknown Entities on an Insecure Network of Untrusted Workstations. Proceedings of the Usenix Workshop on Workstation Security, August 1988.
[46] C. Neuman and T. Ts'o. Kerberos: An Authentication Service for Computer Networks. IEEE Communications Magazine, September 1994.
[47] C. Neuman et al. The Kerberos Network Authentication Service V5 R6. IETF Draft July 1997, expires Jan 1998.
[48] R. O'Brien and C. Rogers. Developing Applications on LOCK. Proceedings of the 14th National Computer Security Conference, 1991.
[49] J. Ousterhout et al. The Safe-Tcl Security Model. Sun Labs Technical Report TR-97-60, March 1997.
[50] President's Commission On Critical Infrastructure Protection. Research and Development Recommendations for Protecting and Assuring Critical National Infrastructures, September 1997.
[51] M. Roe and T. Casey. Integrating Cryptography in the Trusted Computing Base. Proceedings of the 6th IEEE Conference on Computer Security Applications, 1990.
[52] RSA Laboratories. Public Key Cryptography Standard No. 11 - Cryptoki Version 2.0. RSA Laboratories, pp. 24-25, April 1997.
[53] R. Salz. DCE 1.2 Contents Overview. Open Group RFC 63.3, October 1996.
[54] J. Saltzer and M. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), September 1975.
[55] B. Schneier. Applied Cryptography, 2nd Edition. John Wiley & Sons, New York, 1996. p. 169-187, 216-225.
[56] Secure Computing Corporation. Assurance in the Fluke Microkernel: Formal Security Policy Model, Technical report MD A904-97-C-3047 CDRL A003, March 1998.
[57] Secure Computing Corporation. DTOS Covert Channel Analysis Plan, Technical report MD A904-93-C-4209 CDRL A017, May 1997.
[58] Secure Computing Corporation. DTOS Generalized Security Policy Specification, Technical report MD A904-93-C-4209 CDRL A019 June 1997. (http://www.securecomputing.com/randt/HTML/dtos.html)
[59] Secure Computing Corporation. DTOS General System Security and Assurability Assessment Report, Technical report MD A904-93-C-4209 CDRL A011 June 1997. (http://www.securecomputing.com/randt/HTML/dtos.html)
[60] Secure Computing Corporation. LOCKed Workstation Cryptographic Services Study, Technical Report MD A904-94-C-6045 CDRL A009, September 1995.
[61] Secure Computing Corporation. Security Requirements Specification and Requirements Rationale Report for the Technical Study Demonstrating the Feasibility of Software-Based Cryptography on INFOSEC Systems, Technical report MDA904-91-C-7103 CDRL A011 and A012, May 1994.
[62] W. Sibert. Malicious Data and Computer Security. Proceedings of the 19th National Information Systems Security Conference, 1996.
[63] M. Sirbu and J. Chuang. Distributed Authentication in Kerberos using Public Key Cryptography. Proceedings of the Symposium on Network and Distributed System Security, 1997.
[64] M. Spasojevic and M. Satyanarayanan. An Empirical Study of a Wide-Area Distributed System. ACM Transactions on Computer Systems 14(2), May 1996.
[65] S. Sutton and S. Hinrichs. MISSI B-level Windows NT Feasibility Study Final Report. Technical Report, NSA MISSI Contract MDA904-95-C-4088, December 1996.
[66] B. Tung et al. Public Key Cryptography for Initial Authentication in Kerberos. IETF Draft expires Jan 1998.
[67] J. Tyger and A. Whitten. WWW Electronic Commerce and Java Trojan Horses. Proceedings of the 2nd Usenix Workshop on Electronic Commerce, November 1996.
[68] W. Venema. Murphy's Law and Computer Security. Proceedings of the 6th USENIX Unix Security Symposium, 1996.
[69] D. Wagner and B. Schneier. Analysis of the SSL 3.0 Protocol. Proceedings of the 2nd USENIX Workshop on Electronic Commerce, November, 1996.
[70] D. Wallach et al. Extensible Security Architectures for Java. Technical Report 546-97, Dept. of Computer Science, Princeton University, April 1997.
| обсудить | все отзывы (0) | |
| [23228; 7; 6.42] |
|
|
|