Требования к заданию непротиворечивых правил доступа

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

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

Разрешенное (санкционированное) право доступа субъекта С, к объекту Оij будем обозначать: С_;-(/?)(.)_; (соответственно, С,(?)(ф — разрешено чтение, C_j(w)O_l — разрешена запись и т. д.), через С,(0)0, будем обозначать запрет доступа.

Требование. Не должно одновременно разрешаться право записи (го) и исполнения (х) к одному и тому же объекту доступа, что предотвращает утечку права исполнения (х): С,(х)0_;.

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

Проиллюстрируем сказанное на примере матрицы контроля доступа М, в которую соответствующим образом включим право исполнения х:

В результате этого имеем C,(r, w, d, х)0, (сформулированное требование не выполняется). Рассмотрим, в результате чего может произойти утечка права исполнения.

Пусть субъект С_{ воспользуется своим правом и модифицирует исполняемый объект О,.

В результате подобного действия появляется новый объект 0^₊₁ вместо объекта О, (новый, поскольку объект O_t как исполняемый объект наделяется новыми функциями — объекта Oj уже не существует). Это показано на матрице контроля доступа М, представленной ниже. Принципиальным в данном случае является то, что к новому объекту О_{к+ {} сохранятся все права доступа субъектов, назначенные для объекта Oj. Как видим, для данного примера имеем утечку правах: С₁(х)О_л+1.

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

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

Теперь сформулируем требования к назначению прав доступа на запись и чтение.

Для упрощения последующей записи будем считать везде, кроме случаев, где это не будет оговорено особо, что для множеств С = {С_р …, С,} и О = = {О_р …, О,} линейно упорядоченных множеств субъектов и объектов доступа число субъектов и объектов доступа совпадает. Соответственно разграничительная политика доступа субъектов к объектам описывается матрицей контроля доступа М, где М[С, О] — ячейка матрицы, содержит набор прав доступа субъекта из множества С = {С_р …, С,} к объекту из множества О = {Ор …, О/}. В любой момент времени система описывается своим текущим состоянием Q = (С, О, М).

Назначение правил доступа далее будем рассматривать в отношении расширения диагональной матрицы контроля доступа, характеризуемой следующим правилом назначения прав доступа: С_#.(®>, г, d)O_j; С_;(0)О_;, i ^ j, i= 1,…,/.

Утверждение. Реализующая диагональную матрицу доступа система безопасна относительно права записи (да) и относительно права чтения (г).

Доказательство. В системе, реализующей диагональную матрицу доступа, невозможно генерирование иных потоков, нежели чем С,(г, да, d)0_;, i =.

= 1…/, априори не вызывающих утечку прав R = {да, г}, так как обработка информации субъектами полностью изолирована — их доступ к объектам в нарушение данного правила невозможен.

Требование. Расширение диагональной матрицы доступа правом чтения (г) Сi®Oj при уже разрешенном в матрице праве чтения C_k®O_j допустимо только при разрешенном праве чтения С*(г)0, где i ^ j * k, i = 1, …, /; j = = 1,lk= 1,/, так как в противном случае открывается возможность несанкционированного обмена информацией между субъектами C_kPCj из-за образующейся при этом утечки права чтения С_А(г)0-.

Обратимся к рис. 9.1, иллюстрирующему утечку права чтения (г), происходящую при невыполнении сформулированного требования.

Рис. 9.1. Утечка права чтения (г).

На рис. 9.1 видим, что в случае разрешения права С_;(г)0_; при исходно заданном праве C_k®O_i с учетом того, что С, априори обладает правом записи С_;(да)0, организуется информационный поток чтения от в C_t путем реализации следующей последовательности действий: С,(г)0_;, С,(да)0₍, СДг)0,. Если право C_k®0_J ие разрешено, то присутствует утечка права чтения СДг)0_;. Как следствие, появляется возможность несанкционированного обмена информацией между субъектами C_t,[P]C_;, Из рис. 9.1 также видно, что сформулированное требование распространяется на все случаи, задаваемые условием: i^j^k, i= 1,…, lj = 1,…, /; k = 1,…, /.

Требование. Расширение диагональной матрицы доступа правом записи (да) С,(да)О_у при уже разрешенном в матрице праве записи С (да)О* допустимо только при разрешенном праве записи С₍(да)О_д, где j * k, i = 1,…, /;

j = 1,/;/<�'= 1, /, так как в противном случае открывается возможность несанкционированного обмена информацией между субъектами СДР]С_; из-за образующейся при этом утечки нрава записи СДгс^Оу,.

Обратимся к рис. 9.2, иллюстрирующему утечку права записи (да), происходящую при невыполнении сформулированного требования.

Рис. 9.2. Утечка права записи (да).

На рис. 9.2 видим, что в случае разрешения права С,(да)0_; при исходно заданном праве C (w)O_k с учетом того, что С_/ априори обладает правом чтения Cj®O_jt организуется информационный поток записи от С, в О_к путем реализации следующей последовательности действий: С_;(да)0_;, С (г)Оу, С.(да)(ф. Если право С_;(да)(не разрешено, то присутствует утечка права записи С,(да)0*, как следствие, возможность несанкционированного обмена информацией между субъектами CJPJC*. Из рис. 9.2 также видно, что сформулированное требование распространяется на все случаи, задаваемые условием i*j*k, i-l,…, i, j = 1,…, l;k= 1,…, /.

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

Пусть исходная матрица доступа М₁₍ имеет следующий вид:

И пусть требуется внести в матрицу доступа М_и правило С,(г, да)0₃. При этом, выполняя сформулированные требования к заданию правил доступа, получаем следующую матрицу доступа, М_д2:

Достаточно важным при определенной реализации метода контроля доступа является требование к праву переименования объекта.

Требование. Переименование объекта доступа не должно изменять прав доступа к этому объекту, в противном случае присутствует утечка прав R.

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

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

Если считать, что множество С = {С_р …, С,} — линейно упорядоченное множество субъектов доступа, a R = {R_v …, RJ — конечное множество прав доступа (чтение (г), запись (w), удаление (d), исполнение (х) и т. д., отсутствие прав доступа (0)) субъекта С, к объекту, созданному субъектом С_;; i = = 1,…, lyj — 1,…, /, то матрица контроля доступа М имеет следующий вид (условимся в строках матрицы указывать учетные данные субъектов, запрашивающих доступ к объектам, а в столбцах — учетные данные субъектов, унаследованные созданными объектами при их создании в системе):

В любой момент времени система описывается своим текущим состоянием Q = (С, С, М), М[С, С] — ячейка матрицы, содержит набор прав доступа. Будем обозначать Сj®Cj разрешением права доступа субъекту С, к объекту, созданным субъектом С., i= 1,lj = 1,/, где R = {х, w> г, d).

Для данной системы состояние = (С₀, С₀, М₀) следует считать безопасным относительно некоторого права R, если не существует последовательности действий (это не относится к действиям администратора, назначающего данные правила), в результате выполнения которых субъект С₀ приобретает право R доступа к объекту, созданному иным субъектом, исходно отсутствующее в ячейке матрицы М₀[С₀, С₀]. Если же право R, отсутствующее в ячейке матрицы М₀[С₀, С₀], приобретается субъектом С₀, то следует говорить, что произошла утечка нрава R, а система небезопасна относительно права R.

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

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

Относительно прав записи (хю) и чтения (г), для которых мандатным контролем доступа реализуется разграничительная политика доступа, правила доступа формализованы — априори заданы. Как следствие, в данном случае требуется не формировать требования к их корректному назначению, а проверить априори заданные правила доступа на предмет их корректности.

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

Проанализируем на ней выполнение сформулированного выше требования. При разрешении нрава чтения (г): С_;(г)0-, при исходно разрешенном в матрице доступа М праве чтения (г): СДг) О, одновременно с этим должно разрешаться и право чтения (г): СДг)0_;, где i *j * k, i = 1,…, i, j = 1,…, /; k = 1, …, /, что предотвращает возможность несанкционированного обмена информацией между субъектами СД Р|С_; из-за образующейся при этом утечки права чтения (г): С_к(г)О,.

Анализ проведем на примере разрешенного права доступа С₂(г)0,. При разрешенном нраве доступа С,(/)()₂ должно также быть разрешено право доступа С,(г)0,. Как видим, данное требование выполняется.

Относительно права записи — здесь реализуется диагональная матрица, следовательно, соответствующее требование выполняется.

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

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

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