Подход Transaction (т)
В данном подходе используются определения безопасных состояния, реализации и системы подхода Read-Write. Однако в подходе Transaction основной акцент делается на определении свойств безопасности функции переходов Т. При этом на Т накладывается дополнительное ограничение: за один шаг работы системы вносится только одно изменение в один из параметров, т.е. изменяется на один элемент множество доступов или одно из значений одной из функций. При этом остальные параметры остаются неизменными.
Определение 20. Функция переходов
обладает ss-свойством, если выполнены
условия:
• если
,
то
и f*=f;
• если
,
тo
,
b* = b
и
,
где
;
• если fo (о) ^ /о"(о), то
,
b* = b
и
,
где
.
Определение 21. Функция переходов обладает *-свойством, если выполнены условия:
• если
и
,
то
и f=f*;
• если
,
то b = b*,
или
,
где
,
или
,
где
.
140
Определение 22. Функция переходов Т безопасна, если она обладает ss-свойством и *-свойством.
Теорема BST-T. Система безопасна для безопасного начального состояния z0, ее функция переходов безопасна.
Доказательство. По аналогии с
доказательством теоремы А1 необходимо
показать, что если функция переходов
безопасна, то состояние
безопасно в смысле, определенном в
подходе Read-Write.
Этот факт, очевидно, следует из условий
определений 20 и 21. Таким образом, при
безопасном начальном состоянии любая
реализация системы, а следовательно, и
система в целом будут безопасными. •
В рамках подхода Transaction
можно рассмотреть вопрос о возможностях
смены уровня безопасности субъектов и
объектов. Пусть
– множество субъектов, имеющих право
менять уровень допуска субъекта x;
– множество субъектов, имеющих право
менять гриф секретности объекта у.
В этом случае в функции переходов
необходимо внести еще один параметр,
определяющий субъекта, дающего запрос
системе.
Определение 23. Функция переходов безопасна в смысле изменения уровней, если выполнены условия:
• если
,
то
;
• если
,
то
.
Таким образом, задавая множества сs(x) и со(у), можно рассматривать случаи, когда все субъекты могут менять уровни безопасности, никто не может, или только системный администратор может менять уровни безопасности.
Проблемы использования модели бл
Кроме отмеченной выше проблемы некорректного определения безопасности в модели БЛ возможно возникновение трудностей иного рода, возникающих при использовании модели БЛ в реальных компьютерных системах. Ниже по [12] мы рассмотрим ряд примеров программ, написанных на некотором абстрактном языке программирования высокого уровня, иллюстрирующих трудности практического использования положений классической модели БЛ.
Пример 1. Временной канал утечки информации.
Пусть:
F1 – секретный файл, который может содержать или запись "А" или запись "В",
F2 – несекретный файл;
S1 – субъект, работающий по программе:
Process S1 (F1: file):
Open F1 for read
While F1="A" Do End
Close F1
End;
S2 – субъект злоумышленник, работающий по программе:
Process S2(F1: file, F2: file):
Start S1(F1)
Wait 10 seconds
Open F2 for write
141
If stop S1 Then
Write "B" to F2
Else
Write "A" to F2
End If
Close F2
End;
Субъект-злоумышленник S2, не открывая на чтение секретные файлы, запускает процесс S1 и в зависимости от результатов его выполнения (процесс S1 либо сразу завершится, либо "зависнет") записывает информацию в несекретный файл. При этом предполагается, что злоумышленник S2 имеет уровень доступа секретно, так как S1 наследует права запустившего его процесса.
Пример 2. Каналы утечки информации через локальную и логическую переменные.
Пусть F1 и F2 – секретный и несекретный файлы соответственно. Приведенные ниже процедуры реализуют каналы утечки информации через локальную переменную (процедура P1) и логическую переменную (процедура P2).
Procedure P1 (F1: file, F2: file):
Open F1 for read
Read A from F1
Close
Open F2 for write
Write A to F2
Close F2
End;
Procedure P2 (F1: file, F2: file):
// Считаем, что файл F1 может содержать либо запись "А", либо запись "В"
Open F1 for read
If F1 = "A" Then
Close F1
Open F2 for write
Write "A" to F2
Else
Close F1
Open F2 for write
Write "B" to F2
End If
Close F2
End;
Для предотвращения возникновения каналов утечки информации через локальные или логические переменные при написании программ можно предложить руководствоваться следующими рекомендациями:
• открывать все файлы, необходимые для работы программы вначале ее выполнения;
• закрывать все файлы в конце выполнения программы;
• непосредственную обработку информации из открытых файлов осуществлять во внутренних процедурах, использующих только локальные
переменные.
Таким образом, без дополнительных уточнений свойств безопасности и порядка написания кода программ классическая модель БЛ не способна предотвратить возникновение некоторых каналов утечки информации. В тоже время слишком строгая политика безопасности может привес-142
ти к трудностям или даже невозможности практического использования системы защиты. Кроме того, как уже отмечалось выше, доопределение и усложнение свойств безопасности также несет в себе скрытую угрозу.