Объектно-ориентированный подход в построении дискреционной политики безопасности Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 65.012.810

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД В ПОСТРОЕНИИ ДИСКРЕЦИОННОЙ ПОЛИТИКИ

БЕЗОПАСНОСТИ

С.В. Белим, С.В. Усов

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

Введение

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

В случае объектно-ориентированной модели компьютерной системы, как и для субъектно-объектного подхода, возможно определение элементарных операторов в рамках модели безопасности HRU [3]. Поскольку объектноориентированный подход предполагает разбиение объектов на классы, задаваемые списком полей и методов, то при построении модели HRU мы должны научиться обращаться не только с представителями классов, но и с самими классами. Во-первых, рассматривая классы в качестве реализации типов из модели типизированной матрицы доступов (ТАМ), построенной на основе HRU, мы получаем менее жесткие условия в критерии безопасности системы [6]. Во-вторых, возникает два варианта определения как локальных (привязанных к каждому объекту) матриц доступа, так и элементарных операторов, преобразующих эти матрицы.

Первый подход, классово-типизированный, отождествляет класс объекта с его типом, и матрица доступа к каждому объекту каждого класса строится как

Copyright © 2009 C.B. Белим, C.B. Усов.

Омский государственный университет им. Ф.М. Достоевского. E-mail: belim@univer.omsk.su

ТАМ с учетом объектно-ориентированного подхода к строению компьютерной системы.

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

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

1. Элементарные операторы модели HRU в объектно -ориентированной компьютерной системе

Будем рассматривать компьютерную систему в виде множества объектов O, имеющих открытые поля f и скрытые поля p, а также методы обработки полей s.

Все необходимые определения даны в работе [5], там же построена и модель системы безопасности для объектно-ориентированной компьютерной системы.

Матрица доступа M в данном случае - скрытое (private) поле объекта. От объекта к объекту даже одного класса (типа) содержание этого поля может отличаться, Строки матрицы объекта Oi соответствуют объектам компьютерной системы, столбцы - открытым (public) полям и методам объекта oi, элементом матрицы является некоторое подмножество множества R видов доступа к полю, если столбец элемента соответствует public полю объекта, и принимает значение 0 либо 1, если столбец элемента соответствует методу объекта, где ” 1” разрешает вызов метода, а ” 0” - запрещает.

Определим следующие элементарные операции для работы с матрицей доступов:

1) Create(oj,т) - создает объект oi класса т G Т, при этом O' = O U [oj}, а в матрице доступа объектов oi (г = j) добавляется строка, соответствующая объекту oj, причем Vf G oi.F oi.M'[oj,oi.f] = 0, Vs G oi.S oi.M'[oj,oi.s\ = 0, Матрица доступа объекта oj создается полностью пустой, 2) Destroy(oj) - уничтожает объект oj, при этом O' = O\[oj}, а в матрице доступа объектов oi (i = j) уничтожается строка, соответствующая объекту oj. 3) Enter(r,oj,oi.f)

- вносит право доступа r в oi.M[oj,oi.f \, при этом матрица доступа изменяется по правилу: oi.M'[oj,oi.f\ = oi.M[oj,oi.f\ U [r}, 4) Delete(r,oj,oi.f) - удаляет право r доступа из oi.M[oj,oi.f\, при этом матрица доступа изменяется по

правилу: o,i.M'[oj ,oi.f\ = oi.M [oj, ofW^}, 5) Grant(oj ,oi.s) - разрешает вызов объекту oj метода oi.s, при этом матрица доступа изменяется по правилу:

0.1.M'[oj ,o,i.s\ = 16) Deprive(oj, oi.s) - запрещает вызов объекту oj метода oi.s, при этом матрица доступа изменяется по правилу: oi.M'[oj,oi.s] = 0,

В дальнейшем будем сокращать запись oi.M[oj,oi.f\ до Mi[j,f\ и запись

01.M [oj ,oi.s\ до Mi[j,s\.

2. Определения

t

будем понимать пару Q(t) = (O(t),M(t)), где O(t) = [oj} - множество всех объектов системы в момент времени t, a M(t) = [oj.M[\(t)} - семейство всех

t

Q(0)

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

Команда y(x\,..., xY) :

if ~ условная часть (представляет собой конъюнкцию значений логических выражений вида, r G Mj\j, f \ или Mj\j, s\ = 1)

then — последовательность элементарных операций.

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

Факт перехода системы под действием команды y из состояния Q(t), в котором она находилась в момент времени t, в состояние Q(t + 1), в котором она находилась в следующий момент времени t+1, будем записывать в сокращенном виде: Q(t) Q(t + 1).

Определение 2. HEU-модель системы безопасности называется монооперационной, если каждая команда в этой системе содержит только одну элементарную операцию.

Определение 3. HRU-модель системы безопасности называется монотонной, если каждая команда в этой системе содержит только одно условие.

Определение 4. HRU-модель системы безопасности объектноориентированной компьютерной системы называется монотонной, если команды этой системы не содержат операций Delete Deprive и Destroy.

Определение 5. Будем говорить, что состояние системы Q(t) допускает утечку права доступа r G R, если существуют такие команда y, объект oj и поле of объекта oi; что r / Mi[j, f\(t), но r G Mi[j, f\(t + 1^, где Q(t) Q(t + 1),

Определение 6. Будем говорить, что состояние системы Q(t) допускает утечку права вызова, если существуют такая команда y, объект oj и метод oi.s объекта o^ что Mi[j, f\(t) = 0, но Mi,[j, f\(t + 1) = 1, где Q(t) Q(t + 1),

Определение 7. Будем говорить, что система г-безоиасиа, если не существует такой последовательности команд y1... Yt, что Q(t — 1) ^lt Q(t), t = 1, 2.. .T, и Q(T) допускает утечку права r либо утечку права вызова,

3. Случаи, допускающие проверку безопасности модели HRU объектно-ориентированной компьютерной системы

r

безопасности системы для объектно-ориентированной системы. Разрешимость аналогичной проблемы для HRU-моделей субъектно-объектных систем уже была доказана для некоторых частных случаев, А именно в [4] - для монооперационных систем и в [2] - для монотонных моноуеловных систем. Наша цель

- повторить эти результаты в рамках HRU-модели объектно-ориентированной системы,

r

монооперационной объектно-ориентированной модели.

r

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

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

Поскольку система монооперационна, мы можем называть команду по единственной элементарной операции, которую она содержит.

Будем искать цепочку команд наименьшей длины, переводящую систему в

r

не должна содержать команд, не изменяющих ни одну матрицу доступа (как,

r r

Допустим,

Q(0) ^ Q(1) ^ • • • ^т-1 Q(T — 1) ^7Т Q(T),

где Q(T) допускает утечку права r Є R в ячейку Mi[j, f ](T),

Обратим внимание, что условия команд проверяют лишь наличие права в ячейке матрицы доступа, а не его отсутствие. Таким образом, если мы выкинем все команды Delete и Destroy из цепочки, все права доступа, находившиеся в определенной ячейке в состоянии Q(T), останутся там и после удаления указанных команд. Возможно, появятся новые права - и это может привести к появлению состояния, допускающего утечку права r в момент t < T, что только укоротит цепочку.

Однако, если для некоторого t < T право r лежало в M\[i,f](t), удаление команд Delete(r,Oj,Oi.f), Destroy(oj), Destroy(o-i), выполненных после момента t, приведет к тому что право r останется в Mi[j,f](T) и состоявие Q(T) более не будет допускать утечки этого права, В этом случае хотя бы одну из перечисленных команд необходимо оставить в цепочке.

Отыщем первую команду Create в рассматриваемой цепочке,

(а) Такой команды нет. Значит, все команды Destroy можно удалить, поскольку среди них отсутствуют команды Destroy(oj), Destroy(oi)\ если бы таковые присутствовали, ячейки Mi[i,f](T) просто бы не существовало. Возможно, в цепочке присутствует команда Delete(r, oj, oi.f), Все остальные команды - это команды Enter, и их не более |R||O|2N, Здесь N - максимальное количество полей и методов в классе объектно-ориентированной модели. Заметим, что эту оценку можно улучшить, если различать в доказательстве поля и методы класса до следующей: (iRlNf + Ns)IOI2, где Nf - максимальное количество полей, aNs- максимальное количество методов в классе объектно-ориентированной модели. Действительно, в матрицу доступа объекта не удастся внести более (IRlNf + Ns)|O| прав, а команды, не изменяющие матрицы доступа, мы из цепочки выкидываем,

(б) Нашлась команда Create(ok,тк), тк Е Т. Если ok / O(0), то перед ней нет команды Destroy (ok), а после нее все такие команды можно удалить.

Если ok Е O(0) к отлично от i и j то перед командой Create(ok, тк) найдется Destroy(ok)

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

Наконец, ok Е O(0), к = i или к = j. По соображениям, изложенным выше, одну пару команд вида, Destroy(ok) - Create(ok,тк) (если их несколько, то первую) придется оставить. Остальные из цепочки можно удалить: действительно, если в момент выполнения команды Destroy(oi), где l = i или l = j, r Е R лежит в Mi[j,f](t), то утечка права уже произошла (и цепочку можно сократить), если же r / Mi[j, f ](t), удаление пары Destroy(ol) - Create(ol, т1) не вызовет появления права r Е R в Mi [j, f ] вплоть до момента ti выполнения команды Create(ol,т1). По аналогичной причине команду Delete(r,oj,oi.f) можно удалить так же.

Далее, не имеет смысла оставлять более одной команды вида Create(ok,тк) для каждого класса тк Е Т. Действительно, второй созданный класс ol того же типа тк можно отождествить с первым, ok, выкинув из цепочки операцию Create(ol,тк) и заменив далее в аргументах команд цепочки ol на ok. Такое

ol

воссоздан, a l совпадает с j (или i): действительно, созданная с нуля строка для oj oi

Mk Mk

| Т| Create

Destroy Delete Enter

|R|(|O| + |Т| + 1)2N + |R|(|O| + |T|)N, Здесь второе слагаемое отвечает за заполнение строк, соответствующих ранее удаленному, а теперь воссозданному oi oj

Таким образом, теорема доказана, ■

r

моноусловной монотонной объектно-ориентированной модели,.

r

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

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

Будем искать цепочку команд наименьшей длины, переводящую систему в

r

не должна содержать команд, не изменяющих ни одну матрицу доступа (как,

r r

Допустим,

Q(0) ^ Q(1) ^ ••• ^Т-1 Q(T — 1) ^7Т Q(T),

где Q(T — 1) допускает утечку права r Е R в ячейку Mj\j, f](T — 1) посредством выполнения команды yt-

Условие выполнения команды yT требует наличия права доступа r1 в ячейке Mi1 [j1, f1 ](T — 1), которое добавлено туда некоторой командой jt, t < T. Таким образом, команды Yt+1... YT-1 можно выкинуть из цепочки, поскольку они заполняют ячейки, содержание которых нам не потребуется для утечки пра-r

Create(ok,тк) (к может совпадать с i или с j), если она встретилась па выки-

Yt

доступа r2 в ячейке Mi2 [j2, f2](t — 1), которое добавлено туда некоторой командой y[-> t < t, и мы вновь можем отказаться от промежуточных команд, кроме Create

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

Q(0) *7i Q(1) ^ ••• ^т-1 Q(T — 1) ^7Т Q(T)

уже выкинуты лишние команды.

Теперь добьемся того, чтобы в условии команд цепочки встречалось не более одного нового (то есть отсутствовавшего в начальном состоянии системы) объекта каждого типа. Допустим, первым был создан объект ok тип а тк Е Т, а

Yt ol

позже. Подставив вместо него ok, получаем команды Yt на месте Yt в цепочке,

ol

ol ok

ok

ok T

Т

ектов, которые встретятся в условиях команд цепочки, либо заносит право в ячейку матрицы доступа уже существующего объекта, причем наличие этого права также потребуется в условии одной из команд цепочки. На самом деле команда может выполнять сразу несколько из этих «полезных» элементарных операций, что приведет лишь к сокращению длины цепочки, В любом случае, ее длина не превышает |R|(|O| + |T|)2N + |Т|. ■

r

объектно-ориентированной модели.

Доказательство данной теоремы практически не отличается от классического доказательства со сведением к проблеме остановки машины Тьюринга, предложенного в работе [3]. Отличие заключается лишь в том, что лента машины Тьюринга собирается из ячеек не одной матрицы доступа, как было в случае стандартной HRU-модели, а нескольких.

Литература

1. Harrison, М.A. Theoretical issues concerning protection in operating systems / M.A. Harrison. - University of California at Berkeley, CSD-84-170, 1984.

2. Harrison, M.A. Monotonic protection systems / M.A. Harrison, W.L. Ruzzo / In R.A. DeMillo, D.P. Dobkin, A.K. Jones, R.J. Lipton, editors. - Foundations of Secure Computation. - Academic Press, Inc., 1978. - P. 461-471.

3. Harrison, M.A. Protection in operating systems / M.A. Harrison, W.L. Ruzzo, J.D. Ullman. - Communications of the ACM, 19(8):461—471, August 1976.

4. Tripunitara, M.V. The Foundational work of Harrison-Ruzzo-Ullman Revisited / M.V. Tripunitara, N. Li. - 2006.

5. Белим, С.В. Объектно-ориентированная модель компьютерной системы / С.В. Белим, С.Ю. Белим // Математические структуры и моделирование. - 2008. -Вып. 18. - С. 98-101.

6. Sandhu, R.S. The Typed Access Matrix Model / R.S. Sandhu // Proceedings of IEEE Symposium on Security and Privacy, Oakland, California, May 4-6, 1992. - P. 122-136.