Центр информации по операционным системам: Форумы / Безопасность / Защищенная распределенная операционная система

Центр информации по операционным системам :: Форумы :: Концепции :: Безопасность		<< Предыдущая тема \| Следующая тема >>
Защищенная распределенная операционная система

Переход на страницу 1 2 [3] 4 5
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

Dron

Воскресенье 08.01.2006 14:20

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Мне более симпатичны ACL... причем разрешающие...
То есть по умолчанию все запрещено.

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

Андрей Валяев

Наверх

gagar

Воскресенье 08.01.2006 15:28

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Полагаю, моя непосвященность кроме устройства операционных систем теперь уже распространяется и на механизмы защиты

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

Модель, кстати, очень старая... и не самая надежная!!! Есть такие штука, как скрытые каналы. Есть скрытая передача полномочий и т.д. Эта модель морально устарела. Есть модели невлияния, модели информационных потоков и т.д.

А теперь, если без теоретической чепухи... Если ты собираешься делать серьезную ОС для серьезных людей почитай те РД, что я тебе когда-то высылал... Там, например, есть пункт "Гарантии проектирования":

- Проектирование КСЗ должно начинаться с построения модели защиты;

Или еще цитата:

Мандатный принцип контроля доступа.
Для реализации этого принципа должны сопоставляться классификационные метки каждого субъекта и каждого объекта, отражающие их место в соответствующей иерархии. Посредством этих меток субъектам и объектам должны назначаться классификационные уровни (уровни уязвимости, категории секретности и т.п.), являющиеся комбинациями иерархических и неиерархических категорий. Данные метки должны служить основой мандатного принципа разграничения доступа.
КСЗ при вводе новых данных в систему должен запрашивать и получать от санкционированного пользователя классификационные метки этих данных. При санкционированном занесении в список пользователей нового субъекта должно осуществляться сопоставление ему классификационных меток. Внешние классификационные метки (субъектов, объектов) должны точно соответствовать внутренним меткам (внутри КСЗ).
КСЗ должен реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов:
- субъект может читать объект, только если иерархическая классификация в классификационном уровне субъекта не меньше, чем иерархическая классификация в классификационном уровне объекта, и неиерархические категории в классификационном уровне субъекта включают в себя все иерархические категории в классификационном уровне объекта;
- субъект осуществляет запись в объект, только если классификационный уровень субъекта в иерархической классификации не больше, чем классификационный уровень объекта в иерархической классификации, и все иерархические категории в классификационном уровне субъекта включаются в неиерархические категории в классификационном уровне объекта.
Реализация мандатных ПРД должна предусматривать возможности сопровождения: изменения классификационных уровней субъектов и объектов специально выделенными субъектами.
В СВТ должен быть реализован диспетчер доступа, т.е. средство, осуществляющее перехват всех обращений субъектов к объектам, а также разграничение доступа в соответствии с заданным принципом разграничения доступа. При этом решение о санкционированности запроса на доступ должно приниматься только при одновременном разрешении его и дискреционными, и мандатными ПРД. Таким образом, должен контролироваться не только единичный акт доступа, но и потоки информации

Да, я полностью согласен, что сам механизм мандатной политики ни в коем случае не должен быть в ядре!!! НИ В КОЕМ СЛУЧАЕ!!! Но, повторюсь опять, ГАРАНТИИ корректности построения модели на уровне пользователя должны предоставляться ЯДРОМ!!!

У нас "смешались в кучу кони, люди"...

С уважением, Горячев Игорь Александрович.

Наверх

gagar

Воскресенье 08.01.2006 15:43

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Читал невнимательно...

Заметил фразу " А т.к. доступ к системным объектам возможен только через шлюз, то изнасилование доступа исключено".

Возникают в голове непосвященного пользователя Вашей системы, помешанного на безопасности, три мысли.

Первая: А где расположен шлюз, не в ядре ли?

И что такое вообще шлюз?

Вторая: А в Windows разве не так сделано?

Третья: А можно ли обойти шлюз? Впрочем, эта мысль скорее из-за незнания того, что такое шлюз

С уважением, Горячев Игорь Александрович.

Наверх

Dron

Понедельник 09.01.2006 01:02

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

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

Андрей Валяев

Наверх

gagar

Понедельник 09.01.2006 18:47

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Dron, а на что тебе указать пальцем?

Если нужны канкретные ссылки на конкретные модели и документы то пожалуйста:

Доступные книги:

- Малюк Анатолий Александрович, Информационная безопасность: концептуальные и методологические основы защиты информации. Учеб. пособие для вузов. – М.: Горячая линия – Телеком, 2004. – 280 с. ил.

- А. В. Домашев, М. М. Грунтович, В. О. Попов, Д. И. Правиков, И. В. Прокофьев, А. Ю. Щербаков, Программирование алгоритмов защиты информации. Учебное пособие. Издание второе, исправленное и дополненное. – М.: Издатель Молгачева С. В., Издательство «Нолидж», 2002. – 416 с., ил.

- Бурдаев О. В., Иванов М. А., Тетерин И. И, Ассемблер в задачах защиты информации / Под ред. И. Ю. Жукова – М.:КУДИЦ-ОБРАЗ, 2002. – 320 с.

- Лукацкий А. В, Обнаружение атак. – 2-е изд., перераб. и доп. – СПб.: БХВ-Петербург, 2003. – 608 с.: ил.

- Барсуков В.С., Водолазский В.В., Технологии электронных коммуникаций. Том 34. Интегральная безопасность информационно-вычислительных и телекоммуникационных сетей (Часть 1) – Москва, Россия, 1993г.

- Девянин П. Н. Модели безопасности компьютерных систем: Учеб. Пособие для студ. высш. учеб. заведений / Петр Николаевич Девянин. – М.: Издательский центр «Академия», 2005. – 144 с.

- Завгородний В.И., Комплексная защита информации в компьютерных системах: Учебное пособие. – М.:Логос: ПБОЮЛ Н.А. Егоров, 2001. – 264 с.: ил.

- Малюк А.А., Пазизин С.В., Погожин Н.С., Введение в защиту информации в автоматизированных системах: Учебное пособие для вузов. – 2-е издание. – М.: Горячая линия – Телеком, 2004. – 147 с.: ил.

- Девянин П.Н., Михальский О.О., Правиков Д.И., Щербаков А.Ю., Теоретические основы компьютерной безопасности: Учеб. пособие для вузов / П.Н. Девянин, О.О. Михальский, Д.И. Правиков и др. – М.: Радио и связь, 2000. – 192 с.: ил.

- Романцев Ю.В., Тимофеев П.А., Шаньгин В.Ф., Защита информации в компьютерных системах и сетях / под ред. В.Ф. Шаньгина. – М.: Радио и связь, 1999. – 328 с.

- Дэвид Бэндл, Защита и безопасность в сетях Linux. Для профессионалов (+CD). – СПб.: Питер, 2002. – 480 с.: ил.

- Корт С.С., Теоретические основы защиты информации: Учебное пособие. – М.: Гелиос АРВ, 2004. – 240 с., ил.

- Ховард М., Лебланк Д., Защищенный код: Пер.с англ,— 2-е изд., испр. М.: Издательско-торговый дом «Русская Редакция »,2004.— 704 стр.: ил.

- О. В. Казарин, Теория и практика защиты программ. - Москва, 2004, 450 с.

- О. В. Казарин, Безопасность программного обеспечения компьютерных систем. - Москва, МГУЛ, 2003, 212 с.

- Мельников Виталий Викторович, Безопасность информации в автоматизированных системах. – М.: Финансы и статистика, 2003. – 368 с.: ил.

Статьи перечислять не буду, у меня их порядка 1000

Официальные несекретные документы:

- ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения.

- ГОСТ Р 52069.0-2003. Защита информации. Система стандартов. Основные положения.

- ГОСТ Р 50739-95. Средства вычислительной техники. Защита от несанкционированного доступа.

- ГОСТ Р 50922-96. Защита информации. Основные термины и определения.

- ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. В трех частях.

- ГОСТ Р 51624 - 2000. Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования.

Руководящие документы Государственной технической комиссии при Президенте Российской Федерации:

- Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения.

- Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации.

Кстати, кто не знвет, ОС - это СВТ!!!

- Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации.

- Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.

Список далеко не полный.

Теперь об ACL. Читал ваши опусы в ветке про безопасность ОС-21. То, что вы там напридумывали, уже давно придумано - лет 20 назад и очень хорошо проработано.

Только за 20 лет многое изменилось... Старые ОС уже не переделаешь, а новые по привычке пишут как старые...Да и новых-то нет. Одно копирование старых решений под разными названиями... Да, кстати, вы знаете почему в ОС Windows не применяется мандатная политика? Эта политика очень сложна для пользователей и требовательна к ресурсам. Microsoft это было надо? Раньше нет. Сейчас они, насколько мне известно, полностью пересматривают свое отношение к безопасности, и активно учатся у военных.

Что именно Вам нужно конкретное?

Исходный код? Увольте, господа, писать код в ближайшие пару месяцев я не намерен. Я еще не закончил проектные работы...

Математическая модель? У меня ее еще нет? Есть идеи. Я уже говорил, что я "теоритик". Прежде чем приступать к практике мне надо "высосать из пальца" десяток определений, доказать пару теорем. Мне важно рассмортеть задачу построения ЗРОС комплексно, а не латать дыры в защите...

Я пока не нашел "лекарство от всех болезней" в защите ОС. Я еще только ищу. И высказываю свои идеи. Одна из которых звучит так:

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

Я сформулировал некоторое утверждение. Теперь это утверждение нужно формально доказать, разработать реализацию и правила применения. Надеюсь это хоть понятно?

С уважением, Горячев Игорь Александрович.

Наверх

Thistle

Понедельник 09.01.2006 19:29

ID пользователя #484

Зарегистрирован: Суббота 05.11.2005 00:07
Сообщений: 65

Интересное название у книги "Программирование алгоритмов...." Я почему-то всегда думал, что алгоритмы реализуются, а программируются микропроцессоры и микроконтроллеры....

Как говорил один мой знакомый профессор физик "физику должны преподавать литераторы"... видимо в написании книг литераторы тоже должны участвовать!

Наверх

gagar

Понедельник 09.01.2006 21:36

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Да, а корабли по морю "ходют". Впрочем, замечание вполне корректное...

Наверх

gagar

Четверг 12.01.2006 22:08

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Приведу отрывок одной книги: А.Ю. Щеглов "Защита компьютерной информации от несанкционированного доступа".

----------------------------------------------

2.1. Основные механизмы защиты ОС.
Анализ выполнения современными ОС формализованных
требований к защите информации от НСД

2.1.1. Принципиальные различия в подходах
обеспечения защиты. Разность концепций

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

В связи с этим далее будем говорить лишь о возможном соответствии средств защиты современных ОС классу автоматизированных систем 1Г (защита конфиденциальной информации).

Примечание.
В общем случае возможна неоднозначная трактовка некоторых формализованных требований. Проиллюстрируем ска-занное примером. Рассмотрим требование «Для каждой пары (субъект — объект) в средстве вычислительной техники (СВТ) должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к дан-ному ресурсу СВТ (объекту)». Возникают вопросы: что понимается под условием «для каждой пары...», т.е. причисляются ли в данном требовании к «объектам» программы (процессы или исполняемые файлы), устройства и т.д., а к субъектам — процессы (программы)? Далее, что понимается под условием «должно быть задано явное и недвусмысленное перечисле-ние допустимых типов доступа (читать, писать и т.д.)», что значит «и т.д.», относится ли к нему, например, «исполнение» и др. В связи с этим автор далее будет трактовать все неоднозначности в пользу усиления механизмов защиты. Обоснован-ность подобного подхода мы увидим ниже, при анализе существующей статистики угроз.

В качестве альтернативных реализаций ОС рассмотрим семейства UNIX и Windows (естественно, Windows NT/2000, т.к. о встроенных механизмах защиты ОС Windows 9x/Me говорить вообще не приходится).

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

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

Для иллюстрации из совокупности формализованных требований к системе защиты конфиденциальной информации (требований к дискреционному механизму управления доступом) рассмотрим следующие два требования [1]:
1. Право изменять правила разграничения доступа (ПРД) должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).
2. Должны быть предусмотрены средства управления, ограничивающие распространения прав на доступ.

Примечание.
С полным перечнем требований вы ознакомитесь в главе 11, когда непосредственно приступите к рассмотрению методов управления доступом.

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

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

Теперь в общих чертах рассмотрим концепцию, реализуемую в современных универсальных ОС (подроб-нее см. гл. 2). Здесь «владельцем» файлового объекта, то есть лицом, получающим право на задание атрибутов (или ПРД) доступа к файловому объекту, является лицо, создающее файловый объект. Т.к. файловые объекты создают конечные пользователи (иначе, для чего нужен компьютер?), то именно они и назначают ПРД к созда-ваемым им файловым объектам. Другими словами, в ОС реализуется распределенная схема назначения ПРД, где элементами схемы администрирования являются собственно конечные пользователи.

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

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

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

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

2.1.2. Основные встроенные механизмы защиты ОС и их недостатки

Кратко остановимся на основных механизмах защиты, встроенных в современные универсальные ОС. Сде-лаем это применительно к возможности реализации ими принятой нами для рассмотрения концепции защиты конфиденциальной информации.

Основные защитные механизмы ОС семейства UNIX

Защита ОС семейства UNIX в общем случае базируется на трех основных механизмах:
- идентификации и аутентификация пользователя при входе в систему;
- разграничении прав доступа к файловой системе, в основе которого лежит реализация дискреционной модели доступа;
- аудит, то есть регистрация событий.

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

Построение файловой системы и разграничение доступа к файловым объектам имеет особенности, прису-щие данному семейству ОС. Рассмотрим кратко эти особенности. Все дисковые накопители (тома) объединя-ются в единую ВИРТУАЛЬНУЮ ФАЙЛОВУЮ СИСТЕМУ путем операции монтирования тома. При этом со-держимое тома проецируется на выбранный каталог файловой системы. Элементами файловой системы явля-ются также все устройства, подключаемые к защищаемому компьютеру (монтируемые к файловой системе). Поэтому разграничение доступа к ним осуществляется через файловою систему.

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

Пользователь имеет уникальные символьный идентификатор (имя) и числовой идентификатор (UID). Сим-вольный идентификатор предъявляется пользователем при входе в систему, числовой используется операци-онной системой для определения прав пользователя в системе (доступ к файлам и т.д.).

Принципиальные недостатки защитных механизмов ОС семейства UNIX

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

Для начала отметим, что в ОС семейства UNIX, вследствие реализуемой ею концепции администрирования (не централизованная), невозможно обеспечить замкнутость (или целостность) программной среды. Это связано с невозможностью установки атрибута «исполнение» на каталог (для каталога данный атрибут ограни-чивает возможность «обзора» содержимого каталога). Поэтому при разграничении администратором доступа пользователей к каталогам, пользователь, как «владелец» создаваемого им файла, может занести в свой каталог исполняемый файл и, как его «владелец», установить на файл атрибут «исполнение», после чего запустить за-писанную им программу. Эта проблема непосредственно связана с реализуемой в ОС концепцией защиты ин-формации.

Не в полном объеме реализуется дискреционная модель доступа, в частности не могут разграничивать-ся права доступа для пользователя «root» (UID = 0). Т.е. данный субъект доступа исключается из схемы управ-ления доступом к ресурсам. Соответственно все запускаемые им процессы имеют неограниченный доступ к защищаемым ресурсам. Как мы увидим позднее, с этим недостатком системы защиты связано множество атак, в частности:
- несанкционированное получение прав root;
- запуск с правами root собственного исполняемого файла (локально либо удаленно внедренного). При этом несанкционированная программа получает полный доступ к защищаемым ресурсам и т.д.

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

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

Что касается регистрации (аудита), то в ОС семейства Unix не обеспечивается регистрация выдачи до-кументов на «твердую копию», а также некоторые другие требования к регистрации событий.

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

Из приведенного анализа видно, что многие механизмы, необходимые с точки зрения выполнения форма-лизованных требований, большинством ОС семейства UNIX не реализуется в принципе, либо реализуется лишь частично.

Основные защитные механизмы ОС семейства Windows (NT/2000/XP)

Теперь кратко остановимся на основных механизмах защиты, реализованных в ОС семейства Windows, и проведем анализ защищенности ОС семейства Windows (NT/2000). Отметим, что здесь ряд объектов доступа (в частности, устройства, реестр ОС и т.д.) не являются объектами файловой системы. Поэтому возникает вопрос, как следует трактовать требование «Система защиты должна контролировать доступ наименованных субъек-тов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.)». То есть, не ясно, явля-ются ли объектами доступа, к которым, следуя формальным требованиям, необходимо разграничивать доступ пользователей, например, реестр ОС и т.д.

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

Также, как и для семейства ОС UNIX, здесь основными механизмами защиты являются:
- идентификация и аутентификация пользователя при входе в систему;
- разграничение прав доступа к ресурсам, в основе которого лежит реализация дискреционной модели доступа (отдельно к объектам файловой системы, к устройствам, к реестру ОС, к принтерам и др.);
- аудит, то есть регистрация событий.

Здесь явно выделяются (в лучшую сторону) возможности разграничений прав доступа к файловым объек-там (для NTFS) — существенно расширены атрибуты доступа, устанавливаемые на различные иерархические объекты файловой системы (логические диски, каталоги, файлы). В частности, атрибут «исполнение» может устанавливаться и на каталог, тогда он наследуется соответствующими файлами (в отличие от ОС семейства UNIX).

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

Принципиальные недостатки защитных механизмов ОС семейства Windows(NT/2000/XP)

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

В рамках этой концепции разграничения для файла приоритетнее, чем для каталога, а в общем случае — разграничения для включаемого файлового объекта приоритетнее, чем для включающего (более подробно данный вопрос анализируется в четвертой части книги). Это приводит к тому, что пользователь, создавая файл и являясь его «владельцем», может назначить любые атрибуты доступа к такому файлу (т.е. разрешить к нему доступ любому иному пользователю). При этом обратиться к этому файлу может пользователь (которому на-значил права доступа «владелец») вне зависимости от установленных администратором атрибутов доступа на каталог, в котором пользователь создает файл. Данная проблема непосредственно связана с реализуемой в ОС Windows концепцией защиты информации.

Далее, в ОС семейства Windows (NT/2000/XP) не в полном объеме реализуется дискреционная модель доступа, в частности, не могут разграничиваться права доступа для пользователя «Система». В ОС присутст-вуют не только пользовательские, но и системные процессы, которые запускаются непосредственно системой. При этом доступ системных процессов не может быть разграничен. Соответственно, все запускаемые систем-ные процессы имеют неограниченный доступ к защищаемым ресурсам. Как увидим ниже, с этим недостатком системы защиты связано множество атак, в частности, несанкционированный запуск собственного процесса с правами системного. Кстати, позднее мы увидим, что это возможно и вследствие некорректной реализации механизма обеспечения замкнутости программной среды.

В ОС семейства Windows (NT/2000/XP) невозможно в общем случае обеспечить замкнутость (или це-лостность) программной среды. Это связано совершено с иными проблемами, чем в ОС семейства UNIX, в которых невозможно установить атрибут «исполнение» на каталог. Давайте выясним, в чем сложности у ОС Windows в этом вопросе.

Рассмотрим два способа, которыми в общем случае можно реализовать данный механизм (подробнее об этом читайте в соответсвующих главах), и покажем их несостоятельность в ОС Windows. Итак, механизм замк-нутости программной среды в общем случае может быть обеспечен:
- Заданием списка разрешенных к запуску процессов с предоставлением возможности пользователям за-пускать процессы только из этого списка. При этом процессы задаются полнопутевыми именами, причем средствами разграничения доступа обеспечивается невозможность их модернизации пользова-телем. Данный подход просто не реализуется встроенными в ОС механизмами.
- Разрешением запуска пользователями программ только из заданных каталогов при невозможности мо-дернизации этих каталогов. Одним из условий корректной реализации данного подхода является запрет пользователям запуска программ иначе, чем из, соответствующих каталогов. Некорректность реализа-ции ОС Windows данного подхода связана с невозможностью установки атрибута «исполнение» на устройства ввода (дисковод или CD-ROM). В связи с этим при разграничении доступа пользователь может запустить несанкционированную программу с дискеты, либо с диска CD-ROM (как далее уви-дим - это очень распространенная атака на ОС данного семейства).

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

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

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

Возвращаясь к обсуждению недостатков, отметим, что в ОС семейства Windows (NT/2000/XP) невозможно встроенными средствами гарантированно удалять остаточную информацию. В системе просто отсутст-вуют соответствующие механизмы.

Кроме того, ОС семейства Windows (NT/2000/XP) не обладают в полном объеме возможностью контро-ля целостности файловой системы. Встроенные механизмы системы позволяют контролировать только соб-ственные системные файлы, не обеспечивая контроль целостности файлов пользователя. Кроме того, они не решают важнейшую задачу данных механизмов — контроль целостности программ (приложений) перед их запуском, контроль файлов данных пользователя и др.

Что касается регистрации (аудита), то в ОС семейства Windows (NT/2000/XP) не обеспечивается регист-рация выдачи документов на «твердую копию», а также некоторые другие требования к регистрации событий.

Опять же, если трактовать требования к управлению доступом в общем случае, то при защите компьютера в составе ЛВС необходимо управление доступом к хостам (распределенный пакетный фильтр). В ОС семейст-ва Windows (NT/2000/XP) механизм управления доступа к хостам в полном объеме не реализуется.

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

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

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

Выводы

С учетом сказанного можем сделать важный вывод относительно того, что большинством современных универсальных ОС не выполняются в полном объеме требования к защите АС по классу 1Г. Это значит, что, учитывая требования нормативных документов [1, 2], они не могут без использования добавочных средств за-щиты применяться для защиты даже конфиденциальной информации. При этом следует отметить, что основ-ные проблемы защиты здесь вызваны не невыполнимостью ОС требований к отдельным механизмам защиты, а принципиальными причинами, обусловленными реализуемой в ОС концепцией защиты. Концепция эта осно-вана на реализации распределенной схемы администрирования механизмов защиты, что само по себе является невыполнением формализованных требований к основным механизмам защиты.

Наверх

Freeman

Пятница 13.01.2006 00:56

ID пользователя #3

Зарегистрирован: Четверг 01.07.2004 14:57
Сообщений: 207

А нельзя сказать короче? Ведь достаточно права rwx заменить на cadre.

Наверх

Dron

Пятница 13.01.2006 10:31

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Да уж... развернуто...

Я по работе часто сталкиваюсь с паранойей безопасников... (у меня всетаки фирма с названием Информзащита

)

Но мне кажется, что путь паранойей на тему что куда можно записывать, а что куда нельзя... и всякими секретностями пусть парятся они сами...

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

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

Андрей Валяев

Наверх

Переход на страницу 1 2 [3] 4 5
Перейти: Наверх