Зегжда Д.П. Информационная безопасность
Подождите немного. Документ загружается.
При выборе политики доступа к Internet, NIST рекомендует брать сначала наиболее
безопасную политику, т.е. запрещать все службы, кроме специально разрешенных. Затем
разработчик политики должен ответить на следующие вопросы:
какие из служб Internet организация собирается
использовать (например, TELNET, Mosaic или NFS),
где эти службы будут использоваться: в локальной области, через Internet, через
модем или из удаленных организаций,
необходимы ли дополнительные требования, например, шифрование или
поддержка входного диалога,
какой риск связан с предоставлением этих служб и доступа,
как повлияет обеспечение защиты на удобство управления и использования сети,
оправданны ли предполагаемые меры обеспечения безопасности, с точки зрения
соотношения их стоимости и возможного риска.
Например, в сети может возникнуть необходимость использования NFS между
двумя удаленными объектами, однако политика, по умолчанию запрещающая все,
запретит его использование. Если риск, связанный с использованием NFS для данной
организации является допустимым, она может потребовать замены политики
безопасности на менее безопасную, разрешающую все службы, кроме специально
запрещенных, и разрешающую NFS. Кроме того, можно реализовать такой firewall,
который позволяет поместить системы, требующие NFS, в экранированную подсеть, тем
самым сохраняя политику, запрещающую все по умолчанию, для всех остальных систем
сети. Если же риск использования NFS слишком велик, то в этом случае NFS должна
быть исключена из списка разрешенных служб.
5.4.6.2. Гибкость политики.
Любая политика обеспечения безопасности, связанная с доступом к Internet и
сетевым доступом вообще, должна быть гибкой по двум причинам: сама по себе Internet
постоянно меняется, следовательно, могут меняться и требования безопасности, по мере
того как Internet предлагает все новые услуги и методы доступа к этим услугам.
Возникновение новых услуг и протоколов ведет к возникновению новых проблем
обеспечения безопасности. Кроме того, гибкость необходима еще и потому, что риск
организации также не остается статичным. Изменение риска может быть обусловлено,
например, новыми обязанностями, возложенными на организацию, или изменением
сетевой конфигурации. Увеличение риска может быть вызвано и наличием удаленных
пользователей.Удаленными являются те пользователи, которые инициируют связь с
системой сети из Internet. Для всех этих сеансов должна применяться усиленная
аутентификация. В политике безопасности должно быть отражено, что удаленные
пользователи не могут проникнуть в системы через линии связи, неконтролируемые
firewall. Из этого правила не должно быть исключений, поскольку даже одного
перехваченного пароля или одной неконтролируемой модемной линии может быть
достаточно для возникновения в лазейки для вторжения в сеть.
Такая политика имеет и определенные недостатки. необходимость для
пользователей наличия навыков обращения со средствами усиленной аутентификации,
повышение стоимости обеспечения удаленных пользователей средствами
аутентификации (например, смарт-картами) и увеличение расходов на
администрирование дистанционного доступа.
Удаленным пользователям также может быть необходима возможность доступа к
таким системам, которые недостижимы из Internet. Эти пользователи должны помнить об
опасностях, которые могут возникнуть при небрежном обращении с модемным
доступом.
Кроме того, необходимо рассматривать возможность использования протоколов
Serial Line IP (SLIP) и Point-to-Point Protocol (PPP). Пользователи могут использовать эти
протоколы для установления связей с объектом, защищенным firewall. Такое соединение
осуществляется в обход firewall и является потенциально опасным. Для соединений SLIP
и PPP необходимо придерживаться политики, указанной при рассмотрении модемных
соединений. Как правило, по отношению к этим соединениям политика должна быть
очень строгой.
Если сеть допускает открытый доступ к информационному серверу, это должно
быть учтено при разработке firewall. Хотя сам по себе информационный сервер
представляет определенную угрозу безопасности, он не должен стать слабым местом в
безопасности всей защищаемой сети. В политике должно быть отражено, что при
компрометации информационного сервера не будет скомпрометирована вся сеть.
Необходимо отметить, что трафик информационного сервера в корне отличается от
остальных графиков, таких, например, как электронная почта. Каждый их этих двух
типов графиков подвергается своим собственным угрозам, и нужно четко разграничить
их друг от друга.В примерах firewall экранирующего подсеть и firewall с простым
шлюзом были показаны информационные серверы, которые можно разместить в
экранированной подсети и изолировать от других систем объекта. Это уменьшает шанс
компрометации информационного сервера и дальнейшего его использования для атаки
на сеть.
5.4.6.3. Обеспечение Firewall.
После определения политики безопасности необходимо рассмотреть ряд вопросов,
связанных с обеспечением firewall. Многие из этих вопросов аналогичны тем, которые
возникают в других сис-емах программного обеспечения, поэтому некоторые этапы
разработки firewall, такие, например, как определение требований, их анализ и
спецификация, являются стандартными.
Как только принято решение об использовании firewall-технологии для реализации
политики безопасности организации, следующим шагом является выбор такого firewall,
который обеспечил бы подходящий уровень защиты с наименьшими затратами. Так как
эта задача чрезвычайно сложна и еще недостаточно исследована, то можно
воспользоваться общими рекомендациями. В общем случае необходимо, чтобы firewall
обладал следующими свойствами или атрибутами [3,5]:
Firewall должен иметь возможность поддерживать политику доступа,
запрещающую все, что не разрешено, даже если используется другая политика.
Firewall должен поддерживать политику безопасности, используемую в
организации.
Firewall должен быть гибким, он должен иметь возможность приспосабливаться к
появлению новых служб и требований и изменению политики безопасности сети.
Firewall должен содержать средства усиленной аутентификации или иметь
возможность быстрой инсталляции этих средств.
Firewall должен использовать методики фильтрации для разрешения или отказа в
обслуживании определенным хост-системам в зависимости от заданных требований.
Язык, на котором задаются правила фильтрации IP должен быть гибким,
дружественным для и должен оперировать с как можно большим числом критериев ( в
том числе, с адресом источника и приемника, типом протокола, портом TCP/UDP
источника и приемника и с входным и выходным интерфейсом).
Firewall должен обязательно использовать полномочные службы для таких служб
как FTP и TELNET, чтобы можно было использовать сосредоточенные в firewall средства
усиленной аутентификации. Если требуются такие службы как NNTP, X, http или gopher,
то firewall должен содержать соответствующие им полномочные службы.
Firewall должен иметь возможность централизованного SMTP доступа, чтобы
уменьшить число прямых SMTP-связей между сетью и удаленными системами. В
результате, управление электронной почтой сети будет осуществляться централизованно.
Firewall должен так организовать открытый доступ к сети, чтобы открытые
информационные серверы были защищены firewall, но, в то же время, чтобы их можно
было отличить от остальных систем сети.
Firewall должен иметь возможность концентрировать и фильтровать доступ через
модемы.
Firewall должен содержать механизмы для регистрации графика и подозрительной
деятельности, а также для обработки регистрационных записей.
Если для firewall нужна операционная система типа UNIX, то в его состав
необходимо включить защищенную версию операционной системы, а также другие
средства для обеспечения целостности самого firewall. В такой операционной системе не
должно быть "лазеек".
Firewall должен быть разработан таким образом, чтобы можно было проверить его
надежность и корректность. Структура его должна быть простой для понимания и
обслуживания.
Firewall и все соответствующие системы необходимо своевременно
корректировать при обнаружении "лазеек" и "дыр".
На самом деле существует гораздо больше проблем и требований, однако многие
из них характерны только для конкретных сетей. Тщательное определение требований и
точная оценка риска зависят от требований сети, однако, не следует забывать, что
Internet постоянно меняется. Могут возникать новые проблемы, а ввод новых и
усовершенствование старых служб могут представлять определенные трудности для
каждой конкретной установки firewall.
5.4.6.4. Администрирование Firewall.
Одной из важнейших проблем, связанных с применением firewall, является
проблема его администрирования Без должного обслуживания firewall может стать
небезопасным и допускать нарушения, создавая иллюзию того, что сеть безопасна. В
политике безопасности должно быть четко отражено, насколько велико значение
надежного администрирования firewall.
В то же время наличие firewall не должно уменьшать внимания, уделяемого
администрированию систем сети. Совсем наоборот: если нарушитель преодолел firewall,
то ему ничего не стоит внести повреждения в слабо администрируемую сеть. Firewall ни
в коей мере не снижает потребность в высококвалифицированном администрировании
системы. В то же время firewall может допускать активное администрирование систем
сети, в противоположность реактивному администрированию. Благодаря барьеру,
создаваемому firewall, сети могут уделять больше времени выполнению
административных задач и меньше — реагированию на инциденты и контролированию
опасных ситуаций. На системах сети рекомендуется:
стандартизировать версии операционных систем и программное обеспечение для
того, чтобы легче было управлять средствами устранения угроз безопасности,
выбрать программу эффективной установки "заплат" и нового программного
обеспечения,
использовать службы централизованного администрирования сети, если в
результате можно получить лучшее администрирование и большую безопасность,
осуществлять периодический просмотр и проверку хост-систем на предмет
наличия "лазеек" и ошибок в конфигурации,
обеспечить наличие линий связи между администраторами системы и
администраторами, отвечающими за безопасность firewall для оповещения сети о новых
проблемах безопасности, сигналах тревоги, "заплатах" и другой относящейся к
безопасности информации.
Администрация firewall и систем сети должна предусмотреть вопросы, связанные с
расследованием инцидентов и принятием необходимых мер. NIST рекомендует, чтобы
организации определили для себя порядок действий при возникновении инцидентов, что
помогло бы им при столкновении с подозрительной деятельностью и нарушениями, а
также в обеспечении их последней информацией об угрозах компьютерной
безопасности. Из-за того, что природа угроз сети Internet постоянно меняется, очень
важно, чтобы угрозы были включены в процесс контролирования инцидентов.
Администраторы firewall должны знать о новых проблемах используемых продуктов или
о том, что деятельность нарушителя, при возникновении таковой, может быть
обнаружена подходящими средствами. В [3,5] содержится информация о создании групп
контролирования инцидентов NIST выпустил специальную публикацию о возможном
порядке действий при возникновении инцидентов, кроме того, эту информацию можно
получить в самой сети Internet.
5.5. Заключение
Сети, включенные в Internet, подвержены значительному риску быть атакованными
нарушителями или стать плацдармом для атаки на другие сети. Это обусловлено рядом
недостатков, присущих определенным службам Internet (см. Главу 4) По мнению
специалистов системы firewall в настоящее время могут служить достаточно надежным
барьером для защиты сетей от атак со стороны Internet. Необходимо отметить, что хотя
применение систем firewall и позволяет защититься от целого ряда угроз, они обладают
рядом недостатков и, кроме того, существуют угрозы, которым они не могут
противостоять.
Различные схемы применения Firewall предназначены для обеспечения
безопасности систем сети от угроз определенного вида. Для успешного противодействия
угрозам со стороны Internet должны применяться сочетания из основных типов Firewall.
Схема применения Firewall должна реализовывать или соответствовать требованиям
принятой в сети политики безопасности. Применение Firewall для защиты сетей требует
принятия дополнительных мер для защиты собственно системы Firewall.
Глава 6.
Основы технологии построения
защищенных ОС.
6.1. Подходы к обеспечению
безопасности ОС.
Ситуацию противостояния систем защиты и угроз безопасности можно
представить себе следующим образом. Существуют ОС со средствами защиты и
множество угроз безопасности, которые воздействуют на них (атакуют). Эта ситуация
представлена на рис. 6.1. Однако, множество угроз развивается не случайным образом —
никто не будет пытаться осуществлять угрозу, которая не имеет ни малейших шансов на
успех и не может преодолеть существующие системы защиты. Существование того или
иного вида угроз обуславливается наличием в ОС недостатков, описанных в п. 3.4. Таким
образом, недостатки в защите ОС как бы провоцируют появление средств нападения.
Ситуация напоминает систему с обратной связью — новые атаки приводят к появлению
новых средств защиты, а недостатки в средствах защиты приводят к появлению новых
средств нападения и т.д.
Рис. 6.1. Связь между ОС и угрозами их безопасности
Разорвать этот порочный круг бесконечного противостояния можно двумя
способами: создать эффективные и безупречно надежные средства защиты от каждого
вида нападения, преодолеть которые невозможно, или модернизировать ОС,
недостатки зашиты ОС, делающие возможным
осуществление угроз
Угрозы безопасности
и целостности
Операционные
системы
атаки
ликвидировав недостатки защиты, приводящие к успеху средства нападения. Рассмотрим
недостатки и преимущества того и другого метода.
Создание средств защиты от каждого вида угроз. Преимущества: защита не
зависит от специфики ОС и не требует модификации по мере развития ОС. Недостатки:
для создания эффективной системы безопасности необходимо проанализировать все
множество угроз и выработать эффективные механизмы противостояния для каждого из
видов угроз. Однако практика показывает, что данный путь является тупиковым
вследствие следующих факторов:
- множество угроз является открытым и постоянно расширяется и имеет
тенденцию экспоненциального роста (см. п. 1.2). Это означает, что все время будут
появляться новые угрозы, требующие новых мер защиты, т.к. старые против них
бессильны. Появление новых средств защиты, будет приводить к появлению новых
классов угроз и т.д. и т.п.
- множество угроз растет не только количественно, но и качественно. Поэтому
невозможно создать исчерпывающую классификацию угроз безопасности ВС и
предсказывать появление новых типов угроз. Это связано с тем, что для того, чтобы
угроза состоялась, она должна быть нового типа и принципиально отличаться от тех, на
которые рассчитаны системы защиты.
Устранение причин, приводящих к успешной реализации угроз. Недостатки:
зависит от специфики ОС, требует пересмотра некоторых принципов, лежащих в основе
работы ОС. Преимущества: не зависит от вида угроз, т. к. ликвидирует причину, а не
следствие. Данный метод более эффективен в реализации, чем создание средств защиты
от каждого вида угроз. Развитие ОС осуществляется планомерно и контролируемо, а
появление новых видов угроз происходит хаотично и непредсказуемо.
Приведенные рассуждения позволяют сделать следующий вывод: для
обеспечения адекватности разрабатываемой системы защиты современным угрозам
лучше проанализировать те причины, по которым произошли известные случаи
нарушения безопасности и ликвидировать их.
6.2. Задачи разработки
защищенных ОС.
В предыдущем параграфе было обозначено основное направление развития
защищенных ОС — ликвидация причин, приводящих к успешной реализации угроз
безопасности. Однако это не означает, что традиционная цель разработки защищенной
системы — удовлетворение заданным стандартам защищенности должна быть
отодвинута на второй план. Сопоставление причин нарушения безопасности (п. 1.4) и
требований к защищенным ОС позволяет утверждать, что устранение причин нарушения
безопасности не выходит за рамки стандартных требований к защите ОС. Просто этот
подход означает более строгую реализацию требований и их последовательное
применение к реальной ОС. Соответствие между причинами нарушения безопасности и
требованиями ГТК[2] и МО США [1] показано в таб. 6.1.
Причины нарушения
безопасности ОС
Требования ГТК Требования МО США
Выбор модели
безопасности,
несоответствующей
назначению или
архитектуре ВС
Управление доступом
Регистрация и учет
Политика безопасности
Неправильное внедрение
модели безопасности в
систему
Управление доступом
Политика безопасности
Непрерывность защиты
Ошибки, допущенные в
ходе программной
peaлизации систем
обеспечения безопасности
Обеспечение целостности Непрерывность защиты
Отсутствие идентификации
и/или аугентификации
субъектов и объектов
Управление доступом.
Регистрация и учет
Идентификация и
аутентификация
Отсутствие контроля
целостности средств
обеспечения безопасности
Обеспечение целостности
Целостность.
Адекватность.
Непрерывность
Наличие средств отладки и
тестирования в конечных
продуктах
Обеспечение целостности
Целостность.
Непрерывность
Таблица 6.1. Соответствие причин нарушения безопасности ОС
и требований к безопасности.
Таким образом, подход к созданию защищенной системы, основанный на
ликвидации причин нарушения безопасности, не противоречит реализации требований и
стандартов на защищенные системы, а является их расширением.
6.3. Методы ликвидации причин
существования угроз.
Выбор модели безопасности, соответствующей назначению архитектуре ВС.
Правильный выбор модели безопасности фактически является задачей не столько
специалистов по ОС, сколько специалистов по безопасности и секретности.
Существующие стандарты ограничивают обязательный список моделей только двумя —
дискретным и мандатным управлением доступом. Для большинства применений этих
двух моделей вполне достаточно. Существующие модели других типов широкого
распространения как модели, лежащие в основе ОС, не получили, обычно их используют
для разработки того или иного приложения. С другой стороны, исторически сложилось
так, что многие системы не поддерживают моделей дискретного и мандатного
управления доступом и даже не позволяют внедрить эти модели без существенного
нарушения принципов организации системы. Сложности при внедрении этих моделей
влекут за собой определенные компромиссы со стороны разработчиков, что является
недопустимым, т. к. приводит к искажению модели безопасности и ее некорректной
реализации (см. далее). Представляется целесообразным, чтобы ОС общего назначения
изначально поддерживали модели дискретного и мандатного управления доступом,
начиная с начальных стадий разработки.
Правильное внедрение модели безопасности. Здесь мы не будем останавливаться
на этом вопросе, т. к. далее он будет рассмотрен более подробно (см. п. 6.5).
Надежная идентификация и аутентификация объектов и субъектов. Данная
проблема носит чисто технический характер. В настоящее время существуют системы,
обеспечивающие надежность идентификации и аутентификации с заданной степенью
надежности. Для идентификации надежность обеспечивается уникальностью
используемых признаков, а для аутентификации — трудностью подделки. Для
реализации надежных алгоритмов идентификации и аутентификации пользователей
необходимы специальные аппаратные средства — магнитные карты, считыватели
физиологических параметров пользователя (отпечатков пальцев, сетчатки глаза и т.д.),
программная реализация этих методов несложна и может быть легко добавлена в любую
существующую систему. Для идентификации и аутентификации программных (без
участия человека) субъектов и объектов используются получившие интенсивное
развитие в последнее время алгоритмы т.н. электронной подписи. Выбор конкретных
механизмов, устройств и средств идентификации и аутентификации зависит от
предъявляемых требований к конкретной системе и можетбыть осуществлен независимо
от остальных решений используемых для обеспечения защиты.
Отсутствие ошибок в программной реализации систем обеспечения безопасности.
Методы и средства защиты, как и любое другое программное обеспечение подвержены
ошибкам реализации. Разумеется, ошибка в любом из компонент системы защиты ставит
под сомнение безопасность всей системы, поэтому ошибки в программном обеспечении,
отвечающем за безопасность, приводят не просто к потере функциональности, а к
дискредитации всей системы. Меры, направленные на решение этой проблемы,
относятся к области технологии программирования и надежности ПО. Эта проблема
представляет собой как бы область пересечения двух разных дисциплин — безопасности
и надежности ПО, т. к. надежность программ, реализующих защиту, определяет
безопасность системы.
Контроль целостности средств обеспечения безопасности. Данная проблема носит
чисто технологический характер, т.к. методы контроля целостности достаточно развиты
и существуют вполне надежные решения (та же цифровая подпись). Однако на практике,
как правило, эти методы применяются только для контроля целостности информации
(например, при передаче по каналу связи). Для решения этой проблемы необходимо в
первую очередь контролировать целостности механизмов, обеспечивающих защиту.
Наличие средств отладки и тестирования в конечных продуктах. Для решения этой
проблемы можно использовать только организационные меры. Все системы, для которых
безопасность имеет решающее значение должны (кроме всего прочего) иметь
сертификат, подтверждающий, что в них отсутствуют подобные возможности.
Естественно, что полную ответственность за выполнение этого требования может взять
на себя только разработчик.
Ошибки администрирования. Эта проблема упирается в человеческий фактор и не
может быть решена чисто техническими средствами. Для минимизации вероятности
появления подобных ошибок необходимо обеспечивать средства управления
безопасностью и контроля доступа удобным и практичным интерфейсом, по
возможности использовать автоматизированные системы управления. Кроме того,
можно предусмотреть специальные средства верификации, проверяющие конфигурацию
ВС на предмет неадекватного администрирования.
Итак, мы кратко рассмотрели основные методы ликвидации причин успешной
реализации угроз безопасности ОС. В данной работе мы подробно остановимся на
проблеме внедрения модели безопасности в ОС, и предложим возможные пути ее
решения.
6.4 Проблема внедрения модели
безопасности в ОС.
6.4.1. Критика внедрения моделей.
С проблемой внедрения модели безопасности столкнулись все разработчики
защищенных ОС. В результате существует некоторый набор частных решений этой
проблемы, которые, однако нельзя признать удовлетворительными. Рассмотрим самый
простой и очевидный пример — регулирование доступа к файлу, содержащему
информацию о пользователях, их идентификаторах и паролях(в ОС Unix /ete/passwd).
Применение к этому файлу той или иной схемы разграничения доступа не дает
приемлемого решения: если пользователю разрешен доступ только по чтению, то он не
может изменить свой пароль, если по чтению и записи, то он может поменять пароль не
только себе, но и другим, если у него вообще нет доступа к этому файлу, то он не сможет
узнать имена других
пользователей и будет вынужден работать с идентификаторами других
пользователей. Все эти варианты абсолютно неприемлемы. Выход находился в том, что
пользователям давалось право только на чтение, а администратору — на чтение и запись.
Это решает все проблемы, кроме одной — как пользователю изменить свой пароль (ведь
для этого необходимо осуществить запись в этот файл). Для выхода из создавшегося
положения используется неформальный подход — вводится специальная программа,
которая при запуске обладает правами администратора и изменяет для пользователя его
пароль. Недостатки такого подхода очевидны.
Во-первых, в используемой в системе безопасности появились исключения, что не
предусматривается ни одной моделью разграничения доступа.
Во-вторых, появилась новая проблема — т. к. программа, обладающая правами
администратора, может быть запущена любым пользователем, необходимо доказать, что
она не нанесет ущерба безопасности и целостности системы, а ее действия ограничатся
только изменением информации, относящейся к пользователю, который ее запустил.
В-третьих, эта программа представляет собой очень уязвимую точку в системе
защиты — значит необходимо обеспечить, а также постоянно контролировать ее
целостность.
Отметим, что при использовании этой схемы для пользователя доступ по записи к
файлу паролей возможен только с помощью этой специальной программы, что нарушает
принятый во многих ОС стиль работы и в некоторых ситуациях доставляет неудобства.
Рассмотренный пример, конечно, не представляет из себя неразрешимой проблемы,
однако он очень характерен — в современных ОС присутствует огромное количество
различных служб (сетевые службы, графический интерфейс, файловые системы и т.д.),
каждая из которых включает в себя файл, содержащий информацию о конфигурации
службы, режимах работы, пользователях и т.д. Очевидно, что это очень критичная
информация, однако при разграничении доступа к ней возникают примерно те же
проблемы.
Таким образом, существующее положение с внедрением модели безопасности в
ОС нельзя назвать удовлетворительным, т к остаются нерешенными следующие
проблемы:
1. Допускается исключение из правил, регулирующих доступ согласно модели
безопасности. Это означает, что теоретические достижения, связанные с доказательством
эффективности модели на практике оказываются утерянными, т. к. доказательство не
учитывает этих исключений.
2. Данный подход искусственно порождает новую проблему — проверку
корректности работы программ, представляющих собой исключение из модели
безопасности. Это приводит к необходимости формального доказательства корректности
работы этих программ, что представляет собой немалую проблему и не служит
непосредственной цели — обеспечению безопасности системы.
3. Безопасность всей системы зависит не только от реализации в ее ядре модели
безопасности, но и от корректности программ, являющихся внешними по отношению к
самой ОС. Это противоречит основным требованиям к безопасности для систем
высокого класса защищенности.
Итак, мы показали, что проблема внедрения модели безопасности весьма актуальна
и без ее эффективного решения создания защищенной системы невозможно. Для
решения этой проблемы необходимо формально постановить задачу внедрения
модели безопасности в ОС, после чего можно предложить ее решение.
6.4.2. Постановка задачи внедрения модели безопасности в ОС.
Рассмотрим подробнее проблему внедрения модели безопасности в ту или иную
ОС. Как было отмечено в главе 2, существующие модели безопасности достаточно
хорошо проработаны, формально доказаны и их надежность (с точки зрения теории) не
вызывает сомнений Особенно это относится к двум основным моделям, используемым в
качестве обязательных ГТК РФ[2] и МО США[1] — моделям дискретного и мандатного
управления доступом. Однако при детальном изучении этих моделей становится
очевидно, что все они достаточно далеки от практики, т к оперируют абстрактными
понятиями типа объект, субъект и т.д. В них отсутствуют такие понятия, как
пользователь, процесс, файл, каталог, удаленный пользователь, сетевое соединение
и т.д, которые используются для описания функционирования современных ОС. С одной
стороны это дает преимущество в виде свободы трактовать понятия объект и субъект по
отношению к различным ситуациям, а с другой — приводит к появлению проблемы
внедрения модели безопасности в реальную ОС. Эту проблему можно сформулировать
следующим образом: