Мандатное управление доступом windows

Разграничение доступа пользователей в ОС Windows. ПАК СЗИ НСД «Аккорд-Win64» (10/11)

Мандатный механизм управления доступом

Здравствуйте!

В данной лекции мы поговорим о мандатном механизме управления доступом, рассмотрим требования этого механизма и понятие используемой в нем решетки уровней конфиденциальности информации, приведем пример схемы реализации мандатного механизма управления доступом. А также поговорим, как происходит настройка уровня доступа пользователей и настройка уровня конфиденциальности (меток допуска) объектов в программно-аппаратном комплексе СЗИ от НСД «Аккорд-Win64», то есть настройка правил разграничения доступа с использованием данного механизма.

Итак,  как мы уже говорили в лекции про дискреционный механизм управления доступом – все элементы компьютерной системы, как известно, разделяются на множество субъектов и объектов. Будем называть их обобщенно — сущностями КС.

Мандатное управление доступом к объектам компьютерной системы предполагает выполнение следующих требований:

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

Решетка уровней конфиденциальности классически задается в числовом виде – «0», «2»,  … «15», где «0» — самый низкий уровень, а «15» — самый высокий (уровень «1» зарезервирован для более сложных задач). Но может быть задана и иначе, например, когда имеется всего 4 уровня конфиденциальности. Здесь ОД – это общедоступно, К – конфиденциально, С – секретно, СС – совершенно секретно.

Реализацию мандатного механизма управления доступом можно схематично изобразить следующим образом. Пусть, например, у нас есть Объект 1 (некоторый файл) и несколько субъектов (S1, S2, S3). Объект 1 имеет уровень конфиденциальности «Конфиденциально» и Субъект 2 имеет уровень доступа «Конфиденциально», Субъект 1 имеет уровень доступа «Секретно», а Субъект 3 – «Общедоступно». Слева мы видим решетку уровней конфиденциальности для данного случая. В соответствии с требованиями мандатной политики  управления доступом Субъект 1 (с более высоким уровнем доступа, чем у нашего файла) не может писать (W) в файл с уровнем доступа ниже, но может его читать (R). Субъект 2 (с таким же уровнем доступа, что и наш файл) может и писать в файл и читать его (RW) ), а Субъект 3 (с уровнем доступа ниже, чем наш файл) не может ни читать, ни писать в файл (RW) ), но может добавлять туда информацию без перезаписи (А) ).

Теперь давайте рассмотрим, как происходит задание правил разграничения доступа (ПРД) с использованием мандатного механизма в комплексе «Аккорд».

Для включения мандатного механизма разграничения доступа необходимо в главном окне программы «Настройка комплекса «Аккорд» в поле «Механизмы защиты» установить флаги «Мандатный» и «Контроль процессов». Установим их. Нажмем «Сохранить» и выйдем из программы.

Теперь необходимо выполнить настройку уровня доступа пользователей. Для этого зайдем в программу «Редактор прав доступа». После установки в настройках комплекса галочек «Мандатный» и «Контроль процессов» в главном окне данной программы на панели инструментов становятся активными кнопки «Уровень доступа пользователя» и «Установить мандатные метки допуска к объектам».

С помощью кнопки «Уровень доступа пользователя» можно установить, или изменить уровень доступа пользователя. Выберем пользователя из списка и обратим внимание на то, что в поле «Уровень доступа пользователя» по умолчанию установлен самый низкий уровень доступа — «Общедоступно».

Нажмем кнопку «Уровень доступа пользователя» и зададим ему уровень доступа, например, «Конфиденциально». Нажмем кнопку «Сохранить». В поле «Уровень доступа пользователя» появится заданное значение.

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

Далее необходимо открыть окно «Редактирование правил разграничения доступа» и в нем перейти на вкладку «Процессы».

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

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

Для этого нажмем кнопку «Новый». В появившемся окне в поле «Имя процесса» введем «*». Больше ничего менять не будем и нажмем «Сохранить». В списке «Процессов» видим, что появилась «*» и уровень доступа «Общедоступно». Это означает, что все процессы будут иметь метку допуска «Общедоступно».  Нажмем «Сохранить».

Далее можно присваивать уровни конфиденциальности (метки допуска) объектам.  Для этого нужно нажать кнопку «Установить мандатные метки допуска к объектам». Нажмем ее. Выводится окно со списком объектов.

По умолчанию всем объектам присваивается самый низкий уровень – «Общедоступно». Зададим метку допуска произвольному объекту (например, каталогу TEST на диске С:\). Для этого нажмем кнопку «Новый». Откроется окно «Атрибуты доступа к объектам», в котором слева выберем каталог TEST на диске С:. Для выбранного объекта можно изменить только два параметра – наследование прав доступа и метку допуска. «Метка допуска» выставляется выбором значения из списка.

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

А сейчас выберем, например, «Конфиденциально», нажмем кнопку «Сохранить», затем «Закрыть».

Видим, что этот каталог появился в списке с меткой допуска «Конфиденциально».

Объект, которому не присвоена метка допуска, считается общедоступным для всех пользователей.

Для сохранения изменений необходимо нажать «Сохранить».

Подведем итог, на данной лекции мы поговорили о мандатном механизме управления доступом, рассмотрели требования этого механизма, понятие используемой в нем решетки уровней конфиденциальности информации, пример схемы реализации мандатного механизма управления доступом. А также посмотрели, как происходит настройка уровня доступа пользователей и уровня конфиденциальности (меток допуска) объектов в программно-аппаратном комплексе СЗИ от НСД «Аккорд-Win64».

На следующей лекции мы поговорим о контроле процессов с использованием дискреционного и/или мандатного механизмов разграничения доступа.

Спасибо за внимание, до встречи на следующей лекции!

Картинка с сайта: habr.com

Мандатная модель управления доступом (Mandatory Access Control, MAC) — способ разграничения доступа с фиксированным набором полномочий. Обычно настоящий MAC используется в системах с повышенным требованиями к безопасности и стоит на службе всевозможных силовых ведомств и организаций, связанных с государственной или служебной тайной. 

Модель MAC

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

Если вы хорошо знакомы с моделью, можете сразу перейти к следующему разделу.

Основная идея

Абстрактная модель безопасности, реализуемая в классическом MAC (каким его знают сотрудники силовых ведомств), выглядит следующим образом (классическая картинка, иллюстрирующая модель Белла — Лападулы):

Картинка с сайта: habr.com

Модель MAC по своей сути является «электронной» реализацией бумажного «секретного» документооборота. В MAC имеются следующие «действующие лица»:

• Иерархия уровней доступа, которые обрабатываются в системе (обычно регистрируются в ОС). Для удобства часто задается в виде беззнаковых чисел (от 0 до значения, ограниченного реализацией). В этом случае для сравнения уровней доступа (выше/ниже/равно) используются простейшие арифметические операции (равно, меньше, больше).
• Объект с уровнем секретности. Любой файл, каталог в файловой системе, ячейка или запись в таблице БД, таблица в БД, сама БД, сетевой пакет и т.д. Объекту присваивается любое значение из иерархии уровней доступа. Для объекта допускается повышение уровня секретности (изменение до большего значения уровня, чем текущий). Понижение уровня секретности категорически не допускается (хотя вполне реализуемо при помощи определенных уловок).
• Субъект с уровнем доступа. Процесс какого-либо приложения либо сеанс пользователя (по сути тоже процесс приложения). Метка уровня доступа наследуется от субъекта всеми создаваемыми данным субъектом объектами. 

Значение уровня доступа субъекта или уровня секретности объекта обычно называют термином «мандатный уровень», «мандатная метка» или просто «метка» (в STCSEC данный термин называется «hierarchical classification level»). Просто, емко и почти однозначно. 

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

При проверке правомочности доступа субъекта к объекту согласно мандатной модели возможны следующие комбинации:

1. Мандатная метка субъекта равна мандатной метке объекта. В этом случае субъекту разрешено читать и изменять объект.
2. Мандатная метка субъекта выше мандатной метки объекта. Субъекту разрешено только читать объект: он его видит, но не может изменить.
3. Мандатная метка субъекта ниже мандатной метки объекта. Субъекту формально разрешено создать объект с более высокой мандатной меткой (так называемое «повышение уровня секретности объекта»). На практике у субъекта нет технической возможности для выполнения данной операции (он просто «не видит» изменяемый объект, например, файл или каталог с файлами).

Также в MAC существует такое понятие, как «категория» (в терминологии STCSEC данный термин называется «non-hierarchical categories»). Категории в MAC являются опциональными к применению. В практике реализации MAC категории используются для «горизонтального» разграничения доступа между различными подразделениями организации. В этом случае сотрудники, несмотря на один мандатный уровень, будут получать доступ только к тем категориям объектов, к которым для них открыт доступ согласно их метке.

Ограничения и уязвимости

MAC обладает своими ограничениями и особенностями:

1. Пользователи системы не могут самостоятельно определять доступ субъектов к объектам. Из всего арсенала управления доступом к объекту в MAC имеется только мандатная метка и мандатная категория, которые привязаны к этому объекту. Управление доступом субъектов к объектам осуществляют только администраторы.
2. Если пользователь хочет изменить мандатную метку объекта, автором которого он является, то ему необходимо перейти в сеанс целевой метки. Связано с тем, что пользователь не может указать метку по своему желанию, а может лишь передать метку объекту «по наследству». Одновременно пользователь может работать только в сеансе одной мандатной метки.
3. Так как MAC используется совместно с другими моделями управления доступом, возникают коллизии: иногда не так просто выяснить, в каком «слое» системы безопасности произошёл отказ в предоставлении доступа. Требуется тонкий «тюнинг» всех слоёв защиты.
4. Помимо самой настройки доступа посредством инструментария MAC требуется наличие регламента безопасности. В нем должно быть описано, что значат конкретные значения мандатных меток (это находится за пределами MAC), какие объекты как защищаются, какие субъекты имеют право на доступ. Без наличия согласованного регламента MAC сама по себе не даст security enhancement.
5. Использование MAC в распределенной сетевой инфраструктуре. Традиционный подход к настройке MAC — локально, вручную, при помощи администратора в соответствии с инструкцией. Есть решения, позволяющие реализовать централизованно управляемое хранилище MAC (вроде ALD), но они имеют свои особенности и сложности построения.

Проектирование приложения с поддержкой MAC

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

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

Итак, что у нас есть в наборе:

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

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

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

С точки зрения десктопного приложения сценарий работы пользователя выглядит следующим образом:

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает приложение. Процесс приложения наследует мандатную метку.
2. Приложение взаимодействует с БД на PostgreSQL, отображая пользователю, к примеру, только записи таблиц БД с текущей мандатной меткой.

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

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает браузер с поддержкой MAC, в нашем примере — Mozilla Firefox («обычный» браузер для этих целей не подойдет). Процесс браузера наследует мандатную метку.
2. Пользователь запрашивает адрес ресурса приложения с поддержкой мандатных меток. Браузер формирует запрос, добавляя в него мандатную метку.
3. Запрос обрабатывает веб-сервер с поддержкой мандатных меток, в нашем примере — Apache Http Server. Веб-сервер (процесс которого работает в режиме минимальной мандатной метки) считывает мандатную метку запроса, находит приложение-обработчик запускает его процесс с переданной мандатной меткой.
4. Приложение взаимодействует с БД на PostgreSQL, ретранслируя в запросах мандатную метку.

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

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

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

Как избежать MAC, когда его уже не избежать

Картинка с сайта: habr.com

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

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

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

• Кроссплатформерность приложения (ограниченную только лишь возможностями языков программирования) и его независимость от среды выполнения.
• Возможность использования современных инструментов виртуализации (например, Docker) с целью автоматизации.
• Простоту тестирования и отладки функций, которые не связаны непосредственно с MAC.

Рекомендации:

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

При отладке и тестировании необходимо отлаживать (на стороне команды разработки) и тестировать (на стороне команды тестирования) оба режима работы приложения.

Разделяй и властвуй

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

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

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

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

Модулям приложения с различными парадигмами обработки мандатных меток не стоит знать друг о друге слишком много. Иначе это чревато возникновением больших и непредсказуемых проблем в части конфликтов доступа к различным объектам и т.д. Идея минимальной связности для модулей очевидна. В случае работы с MAC следует проявлять особую бдительность и следить за всеми «связями» модулей.

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

Классификация модулей по режимам обработки MAC

Картинка с сайта: habr.com

«BRING IT ON»: работа модуля в режиме минимальной мандатной метки

Картинка с сайта: habr.com

Мотивация для реализации данного механизма в модуле:

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

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

Примеры практических кейсов, для которых подходит использование режима минимальной мандатной метки:

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

«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки

Картинка с сайта: habr.com

Этот кейс чуть сложнее, но во многом похож на случай с минимальной мандатной меткой. С точки зрения пользователя работа с приложением меняется не сильно: все те же привычные списки записей, карточки и операции «Просмотр», «Редактировать» и «Сохранить». С той лишь разницей, что в данном режиме пользователь видит только те записи, которые соответствуют мандатной метке его текущего сеанса.

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

Данный кейс может быть полезен в следующих случаях:

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

C точки зрения реализации данный кейс не является очень простым, так как нам необходимо:

• Выбирать только те записи, которые соответствуют текущей мандатной метке, так как в соответствии с моделью Белла – Лападулы пользователь будет видеть записи текущей мандатной метки и всех мандатных меток, расположенных ниже по иерархии.
• Проверять мандатную метку перед выполнением какой-либо операции внесения изменений в запись. При попытке внести изменение в запись с мандатной меткой, отличающейся от мандатной метки сеанса, выполнение операции должно быть прервано.

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

Примеры практических кейсов, для которых подходит использование режима одной мандатной метки:

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

«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток

Картинка с сайта: habr.com

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

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

С точки зрения реализации пользовательского интерфейса обычно используются следующие шаблоны:

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

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

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

Для реализации такого режима необходимо заложить следующие функции:

• Функция получение мандатной метки текущего процесса приложения (сеанса пользователя).
• Функция получения мандатной метки записи (если речь идет о работе с записью в БД) или файла (если речь идет об обработке файлов).
• Функция получения мандатной метки записей БД/файлов в коллекции.

Примеры практических кейсов, для которых годится режим нескольких мандатных меток:

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

Взаимодействие приложения с окружающей средой

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

Картинка с сайта: habr.com

• Операционная система:
  • Параметры мандатной модели:
    • Иерархия мандатных меток ОС;
    • Мандатные разрешения (диапазоны меток, которые может использовать определенный пользователь) УЗ пользователей ОС.
  • Хранилище учетных данных пользователей;
  • Аутентификация в ОС (в том числе с учётом мандатной метки);
  • Другие механизмы управления доступом (дискреционные POSIX ACL, UNIX и т.д.);
  • Работа с ФС;
  • Управление процессами;
  • Работа с сетью;
• Стороннее ПО без поддержки MAC;
• Стороннее ПО с поддержкой MAC:
  • СУБД (например, PostgreSQL):
    • Объекты БД (ячейки, строки, столбцы, схемы, таблицы, БД, кластеры, последовательности, функции и т.д.).
• Пользователь.

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

Взаимодействие MAC-совместимого приложения с операционной системой

Картинка с сайта: habr.com

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

Чего мы ожидаем от операционной системы в части MAC?

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

Наиболее вероятные потоки взаимодействий ОС и приложения изображены на схеме:

Картинка с сайта: habr.com

Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC

Большая часть приложений, которые могут использоваться в ОС с MAC, не умеют обрабатывать MAC. 

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

жилам витых пар

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

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

Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC

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

Пример популярного приложения с полноценной поддержкой мандатных меток — СУБД PostgresSQL. В определенных вариантах поставки данной СУБД реализована полная поддержка MAC под некоторые ОС с механизмами MAC, например: 

• Astra Linux: PostgreSQL, идущий в поставке дистрибутива версии SE.
• SELinux: расширение sepgsql.

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

• На уровне кластера.
• На уровне БД кластера.
• На уровне схемы БД кластера.
• На уровне таблицы схемы БД кластера.
• На уровне столбца таблицы схемы БД кластера.
• На уровне записи таблицы схемы БД кластера.

В результате в реализации MAC получается такая «матрешка»: каждый «родительский» уровень накладывает свои ограничения на все «дочерние» уровни. Поэтому при реализации взаимодействия с каждым подобным приложением с полноценной поддержкой MAC требуется учитывать его специфику работы. Универсальных рецептов нет.

Взаимодействие MAC-совместимого приложения с пользователем

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

Приложение с поддержкой MAC практически ничем не отличается от такового без MAC в части пользовательского интерфейса во всех режимах, за исключением режима одновременной работы с несколькими мандатными метками.

На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:

Выводы

Мы рассмотрели несколько аспектов разработки приложения с поддержкой MAC. Все случаи предусмотреть, разумеется, сложно. Большая часть особенностей мандатной модели зависит от реализации, доступной для применения в выбранной ОС.

Поддержка MAC приложением — это не дополнительная «фича» приложения. Это серьезное архитектурное решение, требующее планирования и проектирования. Наибольшая «боль» для проектировщика MAC-совместимого приложения:

• взаимодействие с инфраструктурой ОС (файловая система, сетевые взаимодействия, запуск процессов с нужной мандатной меткой в случае выполнения приложения на сервере);
• взаимодействие с прикладным ПО с встроенной поддержкой MAC (например, СУБД);
• взаимодействие с пользователем в части корректной обработки MAC-совместимых операций.

Картинка с сайта: habr.com

На этом пока все! Дополнения, личный опыт и комментарии к статье приветствуются!

Сталкивались ли вы с MAC в своей профессиональной деятельности?

Проголосовали 15 пользователей. Воздержались 4 пользователя.

From Wikipedia, the free encyclopedia

In computer security, mandatory access control (MAC) refers to a type of access control by which a secured environment (e.g., an operating system or a database) constrains the ability of a subject or initiator to access or modify on an object or target.^[1] In the case of operating systems, the subject is a process or thread, while objects are files, directories, TCP/UDP ports, shared memory segments, or IO devices. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, the operating system kernel examines these security attributes, examines the authorization rules (aka policy) in place, and decides whether to grant access. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.

In mandatory access control, the security policy is centrally controlled by a policy administrator and is guaranteed (in principle) to be enforced for all users. Users cannot override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions or assign security attributes.

Historically and traditionally, MAC has been closely associated with multilevel security (MLS) and specialized military systems. In this context, MAC implies a high degree of rigor to satisfy the constraints of MLS systems. More recently,^[when?] however, MAC has deviated out of the MLS niche and has started to become more mainstream. The more recent MAC implementations, such as SELinux and AppArmor for Linux and Mandatory Integrity Control for Windows, allow administrators to focus on issues such as network attacks and malware without the rigor or constraints of MLS.

Historically, MAC was strongly associated with multilevel security (MLS) as a means of protecting classified information of the United States. The Trusted Computer System Evaluation Criteria (TCSEC), the seminal work on the subject and often known as the Orange Book, provided the original definition of MAC as «a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity».^[2] Early implementations of MAC such as Honeywell’s SCOMP, USAF’s SACDIN, NSA’s Blacker, and Boeing’s MLS LAN focused on MLS to protect military-oriented security classification levels with robust enforcement.

The word «mandatory» in MAC has acquired a special meaning derived from its use with military systems. In this context, MAC implies an extremely high degree of robustness that assures that the control mechanisms can resist any type of subversion, thereby enabling them to enforce access controls that are mandated by the order of a government such as the Executive Order 12958. Enforcement is supposed to be more imperative than for commercial applications. This precludes enforcement by best-effort mechanisms. Only mechanisms that can provide absolute or near-absolute enforcement of the mandate are acceptable for MAC. This is a tall order and sometimes assumed unrealistic by those unfamiliar with high assurance strategies, and very difficult for those who are.

In some systems, users have the authority to decide whether to grant access to any other user. To allow that, all users have clearances for all data. This is not necessarily true of an MLS system. If individuals or processes exist that may be denied access to any of the data in the system environment, then the system must be trusted to enforce MAC. Since there can be various levels of data classification and user clearances, this implies a quantified scale for robustness. For example, more robustness is indicated for system environments containing classified «Top Secret» information and uncleared users than for one with «Secret» information and users cleared to at least «Confidential.» To promote consistency and eliminate subjectivity in degrees of robustness, an extensive scientific analysis and risk assessment of the topic produced a landmark benchmark standardization quantifying security robustness capabilities of systems and mapping them to the degrees of trust warranted for various security environments. The result was documented in CSC-STD-004-85.^[3] Two relatively independent components of robustness were defined: Assurance level and functionality. Both were specified with a degree of precision that warranted significant confidence in certifications based on these criteria.

The Common Criteria standard^[4] is based on this science and it intended to preserve the assurance level as EAL levels and the functionality specifications as Protection Profiles. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, TCSEC level C2^[5] (not a MAC-capable category) was fairly faithfully preserved in the Common Criteria, as the Controlled Access Protection Profile (CAPP).^[6] MLS Protection Profiles (such as MLSOSPP similar to B2)^[7] is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their Orange Book predecessors, focusing more on objectives. This gives certifiers more subjective flexibility in deciding whether the evaluated product’s technical features adequately achieve the objective, potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products. For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product.

Such an architecture prevents an authenticated user or process at a specific classification or trust-level from accessing information, processes, or devices in a different level. This provides a containment mechanism of users and processes, both known and unknown. An unknown program might comprise an untrusted application where the system should monitor or control accesses to devices and files.

A few MAC implementations, such as Unisys’ Blacker project, were certified robust enough to separate Top Secret from Unclassified late in the last millennium. Their underlying technology became obsolete and they were not refreshed. Today there are no current implementations certified by TCSEC to that level of robust implementation. However, some less robust products exist.

Starting with Windows Vista and Server 2008, Microsoft has incorporated Mandatory Integrity Control (MIC) in the Windows operating system, which adds integrity levels (IL) to running processes. The goal is to restrict access of less trustworthy processes to sensitive info. MIC defines five integrity levels: Low, medium, high, system, and trusted installer.^[8] By default, processes started at medium IL. Elevated processes receive high IL.^[9] Child processes, by default, inherit their parent’s integrity, although the parent process can launch them with a lower IL. For example, Internet Explorer 7 launches its subprocesses with low IL. Windows controls access to objects based on ILs. Named objects, including files, registry keys or other processes and threads, have an entry in their ACL indicating the minimum IL of the process that can use the object. MIC enforces that a process can write to or delete an object only when its IL is equal to or higher than the object’s IL. Furthermore, to prevent access to sensitive data in memory, processes can’t open processes with a higher IL for read access.^[10]

Apple Inc. has incorporated an implementation of the TrustedBSD framework in its iOS and macOS operating systems.^[11] (The word «mac» in «macOS» is short for «Macintosh» and has nothing to do with the abbreviation of «mandatory access control.») The command-line function sandbox_init provides a limited high-level sandboxing interface.^[12]

Version 5.0 and later of the Android operating system, developed by Google, use SELinux to enforce a MAC security model on top of its original UID-based DAC approach.^[13]

Linux and many other Unix distributions have MAC for CPU (multi-ring), disk, and memory. While OS software may not manage privileges well, Linux became famous during the 1990s as being more secure and far more stable than non-Unix alternatives.^{[citation needed]}

Amon Ott’s RSBAC (Rule Set Based Access Control) provides a framework for Linux kernels that allows several different security policy / decision modules. One of the models implemented is Mandatory Access Control model. A general goal of RSBAC design was to try to reach (obsolete) Orange Book (TCSEC) B1 level. The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1 (developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC). RSBAC requires a set of patches to the stock kernel, which are maintained quite well by the project owner.

Smack (Simplified Mandatory Access Control Kernel) is a Linux kernel security module that protects data and process interaction from malicious manipulation using a set of custom mandatory access control rules, with simplicity as its main design goal.^[14] It has been officially merged since the Linux 2.6.25 release.^[15]

TOMOYO Linux is a lightweight MAC implementation for Linux and Embedded Linux, developed by NTT Data Corporation. It has been merged in Linux Kernel mainline version 2.6.30 in June 2009.^[16] Differently from the label-based approach used by SELinux, TOMOYO Linux performs a pathname-based Mandatory Access Control, separating security domains according to process invocation history, which describes the system behavior. Policy are described in terms of pathnames. A security domain is simply defined by a process call chain, and represented by a string. There are 4 modes: disabled, learning, permissive, enforcing. Administrators can assign different modes for different domains. TOMOYO Linux introduced the «learning» mode, in which the accesses occurred in the kernel are automatically analyzed and stored to generate MAC policy: this mode could then be the first step of policy writing, making it easy to customize later.

SUSE Linux and Ubuntu 7.10 have added a MAC implementation called AppArmor, which utilizes the Linux Security Modules (LSM) interface of Linux 2.6. LSM provides a kernel API that allows modules of kernel code to govern ACL (DAC ACL, access-control lists). AppArmor is not capable of restricting all programs and is optionally in the Linux kernel as of version 2.6.36.^[17]

grsecurity is a patch for the Linux kernel providing a MAC implementation (precisely, it is an RBAC implementation). grsecurity is not implemented via the LSM API.^[18]

Astra Linux OS developed for Russian Army has its own mandatory access control.^[19]

FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and multilevel security.

Sun’s Trusted Solaris uses a mandatory and system-enforced access control mechanism (MAC), where clearances and labels are used to enforce a security policy. However note that the capability to manage labels does not imply the kernel strength to operate in multilevel security mode^{[citation needed]}. Access to the labels and control mechanisms are not^{[citation needed]} robustly protected from corruption in protected domain maintained by a kernel. The applications a user runs are combined with the security label at which the user works in the session. Access to information, programs and devices are only weakly controlled^{[citation needed]}.

• P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998.
• P. A. Loscocco, S. D. Smalley, Meeting Critical Security Objectives with Security-Enhanced Linux Archived 2017-07-08 at the Wayback Machine Proceedings of the 2001 Ottawa Linux Symposium.
• ISO/IEC DIS 10181-3, Information Technology, OSI Security Model, Security FrameWorks, Part 3: Access Control, 1993
• Robert N. M. Watson. «A decade of OS access-control extensibility». Commun. ACM 56, 2 (February 2013), 52–63.

• Weblog post on the how virtualization can be used to implement Mandatory Access Control.
• Weblog post from a Microsoft employee detailing Mandatory Integrity Control and how it differs from MAC implementations.
• GWV Formal Security Policy Model A Separation Kernel Formal Security Policy, David Greve, Matthew Wilding, and W. Mark Vanfleet.

Картинка с сайта: abuzov.com

Статья о разграничении прав доступа в операционных системах Windows: дискретном и мандатном. В статье рассматриваются разграничения прав доступа к папкам и файлам на уровне операционной системы Windows и с помощью Secret Net.

Дискретное разграничение прав доступа

Для того, что бы настроить правила безопасности для папок нужно воспользоваться вкладкой «Безопасность». В Windows XP эта вкладка отключена по умолчанию. Для ее активации нужно зайти в свойства папки (Меню «Сервис» -> «Свойства папки» ->  «Вид») и снять флажок «Использовать простой общий доступ к файлам».

Картинка с сайта: abuzov.com

Основные права доступа к папкам

В файловой системе NTFS в Windows XP существует шесть стандартных разрешений:

1. Полный доступ;
2. Изменить;
3. Чтение и выполнение;
4. Список содержимого папки;
5. Чтение;
6. Запись.

В Windows 10 нет стандартного разрешения «Список содержимого папки».

Эти разрешения могут предоставляться пользователю (или группе пользователей) для доступа к папкам и файлам. При этом право «Полный доступ» включат в себя все перечисленные права, и позволяет ими управлять.

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

Создайте папки по названиям разрешений, всего у вас будет 6 папок для Windows XP и для Windows 10. Я рассмотрю на примере Windows XP, на «десятке» вам будет проще. Скачайте папки по ссылке и скопируйте в них содержимое (не сами папки, а то, что в них находится).

Картинка с сайта: abuzov.com

Отройте вкладку «Безопасность» в свойствах папки «Список содержимого папки». У меня есть пользователь user, вы можете добавить своего. Для того, что бы изменить право на объект нужно выбрать пользователя и указать ему разрешение, в данном случае «Список содержимого папки». Затем нажмите «Применить» и «ОК».

Картинка с сайта: abuzov.com

По аналогии установите права для соответствующих папок.

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

Картинка с сайта: abuzov.com

«Список содержимого папки» — предоставляет возможность просмотра файлов и папок в текущем каталоге. То есть вы можете посмотреть, что есть в папке, но запустить и открыть ничего не получиться.

«Чтение» — предоставляет возможность открывать в папке все файлы, кроме исполняемых файлов (например, с расширением .exe).

«Чтение и выполнение» — предоставляет возможность открывать в данном каталоге все файлы.

«Запись» — предоставляет возможность добавления файлов в папку без права на доступ к вложенным в него объектам, в том числе на просмотр содержимого каталога.

«Изменить» — предоставляет возможность открывать и создавать (изменять) файлы в папке.

«Полный доступ» — предоставляет все возможности для работы с папкой и вложенными файлами, включая изменение разрешений.

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

Картинка с сайта: abuzov.com

Картинка с сайта: abuzov.com

Картинка с сайта: abuzov.com

Элементы разрешений на доступ

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

Просмотреть элементы разрешений на доступ можно, нажав на кнопку «Дополнительно» во вкладке «Безопасность» и выбрав любой элемент разрешений.

Картинка с сайта: abuzov.com

Поэкспериментируйте с элементами и проверьте, как они работаю.

Владелец файла

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

Узнать, какой пользователь является владельцем файла или папки можно на закладке «Владелец» в дополнительных параметрах безопасности.

Картинка с сайта: abuzov.com

Наследование прав доступа

В файловой системе NTFS поддерживается наследование разрешений. Если вы устанавливаете разрешение на папку, то оно наследуется для всех вложенных файлов и папок.

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

Для изменения унаследованных разрешений нужно открыть вкладку «Разрешения» в дополнительных параметрах безопасности. Там же можно отключить наследование разрешений.

Картинка с сайта: abuzov.com

Запреты

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

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

Картинка с сайта: abuzov.com

Разграничение прав доступа с помощью Secret Net (на примере версии 5.1)

При использовании Secret Net доступ к файлам осуществляется, в случае если пользователю присваивается соответствующий уровень допуска. В примере я использую Windows XP с установленным программным продуктом Secret Net 5.1.

Первым делом нужно запустить локальные параметры безопасности от имени Администратора: «Пуск –> Программы –> Secret Net 5 –> Локальная политика безопасности».

Картинка с сайта: abuzov.com

Далее необходимо перейти в «Параметры Secret Net» –>  «Настройка подсистем» –> «Полномочное управление доступом: название уровней конфиденциальности».

Картинка с сайта: abuzov.com

Введите названия уровней. У меня это:

• Низший – Общедоступно.
• Средний – Конфиденциально.
• Высший – Секретно.

Картинка с сайта: abuzov.com

Настройка субъектов

Настройка субъектов в Secret Net производится в группе «Локальные пользователи и группы». Зайдите в меню «Пуск» –>  «Программы» –>  «Secret Net 5» –> «Управление компьютером» –>  «Локальные пользователи и группы» –> «Пользователи».

Что бы настроить права администратора нужно выбрать учетную запись «Администратор» и перейти на вкладку Secret Net 5. Установим уровень доступа «секретно».

Картинка с сайта: abuzov.com

Далее установите все флажки.

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

Картинка с сайта: abuzov.com

После установки всех флажков нажмите «Применить» и «ОК».

Создадим нового пользователя. Для этого нужно перейти «Локальные пользователи и Группы» –> «Пользователи». Создайте новых пользователей, я назову их «Конфиденциальный» и «Секретный». По аналогии с пользователем Администратор  установите для новых пользователей аналогичные уровни доступа и настройки как на рисунках ниже.

Картинка с сайта: abuzov.com

Картинка с сайта: abuzov.com

Картинка с сайта: abuzov.com

Настройка объектов

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

Автоматическое присваивание категории конфиденциальности можно включить или отключить в окне настройки свойств папки. Этот параметр может редактировать только пользователь, у которого есть права на «Редактирование категорий конфиденциальности».

Картинка с сайта: abuzov.com

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

Попробуйте создать в паке новый файл или каталог, а после чего изменить ее уровень (повысить) и установить флажок «Автоматически присваивать новым файлам». У вас появиться окно «Изменение категорий конфиденциальности».

Выберите пункт «Присвоение категорий конфиденциальности всем файлам в каталоге» и нажмите «ОК» для присвоения категории конфиденциальности всем файлам кроме скрытых и системных файлов.

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

Если пользователь с категорией «Общедоступно» попробует прочитать или удалить документ, то он получит соответствующие ошибки.

Картинка с сайта: abuzov.com

Картинка с сайта: abuzov.com

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

Если вы зайдете под пользователем «Секретный» то вы сможете повысить уровень конфиденциальности файлов и работать с ними.

Картинка с сайта: abuzov.com

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

Контроль потоков данных

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

Для этого нужно запустить «Локальные параметры безопасности»: «Пуск» – «Программы» –> «Secret Net 5» –>  «Локальная политика безопасности», затем перейти в группу «Параметры Secret Net» –>  «Настройки подсистем» и выбрать параметр  «Полномочное управление доступом: Режим работы» и включить контроль потоков. Изменения вступят в силу после перезагрузки компьютера.

Картинка с сайта: abuzov.com

Если зайти (после перезагрузки) под пользователем «Секретный» появиться выбор уровня конфиденциальности для текущего сеанса. Выберите секретный уровень.

Картинка с сайта: abuzov.com

Если вы откроете файл с уровнем «Конфиденциально», отредактируете его и попробуете сохранить под другим именем и в другую папку, то вы получите ошибку, так как уровень сеанса (секретный) выше, чем уровень файла (конфиденциальный) и включен контроль потоков данных.

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

Основные модели управления доступом:

• дискреционная
• мандатная
• ролевая

Дискреционное управление доступом (discretionary access control, DAC)

http://ru.wikipedia.org/wiki/Дискреционное_управление_доступом

управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа. Субъект с определенным правом доступа может передать это право любому другому субъекту.

На курсе «Операционные системы» вы работали с этой моделью доступа.

Пример: когда вы расписываете доступ к файлу, вы указываете

1. имя владельца файла (субъект)
2. права на чтение
3. права на запись
4. права на запуск на выполнение

Примеры субъектов:

• пользователь
• программа выполняющаяся под именем пользователя

Примеры объектов:

• файлы
• каталоги
• внешние накопители (CD,DVD,USB и т.д.)
• принтер
• сетевой адаптер

Картинка с сайта: moodle.kstu.ru

Рис. Дискреционное управление доступом

Достоинства:

• простата реализации
• гибкость (пользователь может описать доступ к своим ресурсам)

Недостатки: 

• излишняя детализированность (приводит к запутанности)
• сложность администрирования
• пользователь может допустить ошибку при назначении прав

Пример дискреционного управления доступом к файлам в LINUX.

ls -l
drwxr-xr-x. 2 root root 4096 янв. 30 18:37 anaconda
drwxr-x—. 2 root root 4096 апр. 1 21:27 audit
-rw-r—r—. 1 root root 12094 апр. 2 03:33 boot.log
-rw——-. 1 root utmp 384 апр. 2 15:25 btmp
-rw——-. 1 root utmp 1536 марта 15 07:41 btmp-20120401
-rw—w—-. 1 root 997 0 янв. 30 18:35 clamav-milter.log
drwxr-xr-x. 2 root root 4096 янв. 30 14:44 ConsoleKit
-rw-r—r—. 1 root root 267059 апр. 2 15:25 cron
-rw-r—r—. 1 root root 1241791 апр. 1 03:22 cron-20120401
-r———. 1 root root 94710 марта 13 12:51 dracut.log-20120314
drwx——. 2 root root 12288 апр. 1 03:22 httpd
drwxr-xr-x. 2 root root 4096 февр. 6 12:26 iptraf-ng
-rw-r—r—. 1 root root 292000 апр. 2 15:25 lastlog
drwxr-xr-x. 2 root root 4096 янв. 30 18:34 mail
-rw-r——. 1 mysql mysql 3277 апр. 2 12:04 mysqld.log
-rw-r——. 1 mysql mysql 587151 февр. 17 10:18 mysqld.log-20120217
drwxr-x—. 4 nagios nagios 4096 апр. 2 15:25 nagios
drwxr-xr-x. 2 ntp ntp 4096 окт. 6 19:38 ntpstats
drwx——. 2 root root 4096 июня 2 2011 ppp
drwxr-xr-x. 2 root root 4096 янв. 30 16:44 prelink
drwxr-x—. 2 squid squid 4096 апр. 1 03:22 squid
drwxr-x—. 2 root root 4096 дек. 20 01:24 sssd
-rw-rw-r—. 1 root utmp 112128 апр. 2 15:25 wtmp
-rw——-. 1 root root 12381 марта 13 17:05 yum.log 

Мандатное управление доступом (Mandatory access control, MAC) 

http://ru.wikipedia.org/wiki/Мандатное_управление_доступом

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

Картинка с сайта: moodle.kstu.ru

Рис. Мандатное управление доступом

Достоинства:

• простата построения общей схемы доступа
• простата администрирования

Недостатки:

• проблема разграничения пользователей одного уровня
• пользователь не может назначать доступ к объекту

Мандатная модель не реализована в Windows, но можно поставить дополнительные средства защиты (например: Secret Net, Аккорд и т.д.).

В Linux система встроена на уровне ядра — SELinux (Security-Enhanced Linux — Linux с улучшенной безопасностью — http://ru.wikipedia.org/wiki/SELinux) .  

Ролевое управление доступом (Role Based Access Control, RBAC)  

http://ru.wikipedia.org/wiki/Ролевое_управление_доступом 

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

В модели присутствуют:

• пользователи
• роли
• объекты

Рассмотрим модель на примере MOODLE.

Роли в MOODLE:

• Manager — манеджеры может создавать и изменять курсы. 
• Создатели курса — могут создать курс и преподавать в нем.  
• Преподаватель  — могут делать все в курсе (но не могут создать курс).  
• Non-editing teacher — (ассистент) могут преподавать, но не могут изменять. 
• Студент — могут обучатся на курсе (записанный на курс). 
• Guest — пользователи без авторизации.
• Authenticated user — пользователи прошедшие аутентификацию (не записанный на курс).

Роли могут быть глобальными или «локальными». 

Типы контекста, где роли могут быть назначены:

• Manager — Система, Категория, Курс. 
• Создатели курса — Система, Категория.  
• Преподаватель  — Курс, Модуль элемента курса.  
• Non-editing teacher — Курс, Модуль элемента курса. 
• Студент — Курс, Модуль элемента курса.. 
• Guest — нигде.
• Authenticated user — нигде.