Тщательный контроль доступа 1467

TURNER 9,999 SALES 7698 30

JAMES 9,999 SALES 7698 30

14строк(и) выбрано

PL/SQL procedure successfully completed.

Значение 9,999 в столбце SAL доказывает, что изменены все строки таблицы. Теперь попробуем выполнить удаление. Процедура DeleteAll создавалась так, чтобы она не могла удалять запись текущего зарегистрированного пользователя ни при каких условиях:

king@TKYTE816> exec tkyte.hrapp.deleteAll 13 строк(и) удалено

PL/SQL procedure successfully completed.

Впервые мы смогли удалить записи. Теперь попробуем создать новую запись:

king@TKYTE816> exec tkyte.hr app.insertNew(20)

PL/SQL procedure successfully completed.

king@TKYTli816> exec tkyte.hrapp.listEmps ename sal dname mgr dno king 9,999 accounting 10

(null) 1,111 RESEARCH 20

2 строк(и) выбрано

PL/SQL procedure successfully completed.

Понятно, что в данном случае это получится, поскольку применяются правила защиты для роли HR REP. Мы завершили тестирование всех трех ролей. Все требования выполнены, данные защищены, причем защита эта реализована прозрачно для приложений.

Проблемы

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

Целостность ссылок

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

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

1468

Глава 21

Рассмотрим следующие возможности.

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

Удаление данных из таблицы при наличии требования целостности сс1лок с кон-

струкцией ON DELETE CASCADE.

Изменение данных в таблице при наличии требования целостности ссылок с кон-

струкцией ON DELETE SET NULL.

Мы рассмотрим все три возможности на несколько надуманном примере двух таблиц - P (главная) и С (подчиненная):

tkyte@TKYTE816> create table p (x int primary key) ;

Table created.

tkyte@TKYTE816> create table c (x int references p on delete cascade); Table created.

Тайный канал

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

tkyte@TKYTE816> create or replace function pred function

2 (p schema in varchar2, p object in varchar2)

3 return varchar2

4 as

5 begin

6 return l=0;

7 end;

Function created.

И используем эту функцию для ограничения доступа с помощью оператора SELECT к таблице P:

tkyte@TKE816> begin

2 dbms rls.add policy

3 (objectname => P,

4 policy name => P POLICY,

5 policyfunction => predfunction,

6 statement types => select);

7 end;

PL/SQL procedure successfully completed.

Тщательный контроль доступа 1469

Теперь мы по-прежнему можем вставлять значения в таблицу P (а также изменять и удалять в ней данные), но не можем ничего выбрать из этой таблицы. Начнем с вставки строки в таблицу P:

tkyte@TKYTE816>insert into p values (1);

1 row created.

tkyte@TKYTE816> select * fromp; no rows selected

Условие не позволяет выбрать эту строку, но можно проверить ее наличие, просто вставив строку в таблицу С:

tkyte@TKYTE816>insert into c values (1); 1 row created.

tkyte@TKYTE816>insert into c values (2);

insert into c values (2) *

ERROR at line 1:

ORA-02291: integrity constraint (TKYTE.SYS C003873) violated - parent key not found

Итак, мы теперь знаем, что значение I содержится в таблице P, а значения 2 в ней нет, потому что в таблицу С удалось вставить строку со значением 1 и не удалось - со значением 2. Средства обеспечения целостности ссылок могут читать данные, несмотря на установленные средствами тщательного контроля доступа правила защиты. Это может стать сюрпризом для приложения, например, средства, генерирующего запросы на основе информации из словаря данных. Если запросить данные из таблицы С, все необходимые строки возвращаются. При попытке же соединения таблиц P и С будет получено пустое результирующее множество.

Следует также отметить, что подобный тайный канал получения данных из подчиненной таблицы возможен и для главной таблицы. Если бы аналогичное правило защиты было установлено не для таблицы P, а для С и для нее не была бы задана конструкция ON DELETE CASCADE (другими словами, требовалось бы только наличие соответствующего значения первичного ключа), можно было бы определить, какие значения столбца X есть в таблице С, удаляя строки из таблицы Р. Если в подчиненной таблице С есть строки с соответствующим значением, попытка удаления строки из таб-лиц1 P приведет к выдаче сообщения об ошибке, а если - нет, удаление пройдет успешно, хотя выбирать строки из таблицы С с помощью SELECT и нельзя.

Удаление строк

Это можно сделать при наличии конструкции ON DELETE CASCADE в требовании целостности. Если удалить правило для таблицы P и задать эту же функцию в качестве правила защиты для удаления из таблицы С следующим образом:

tkyte@TKYTE816> begin

2 dbms rls.drop policy

3 (TKYTE, P, P POLICY) ;

4 end;