Как в Oracle VPD/RLS предотвращается утечка информации через предикаты злонамеренного пользователя?

Я читал документацию по Oracle VPD (виртуальная частная база данных, также известная как мелкозернистая безопасность, основа безопасности на основе меток), и есть кое-что, что мне трудно понять. Как VPD предотвращает утечку информации пользователем с помощью вредоносной функции в предложении WHERE?

Допустим, у вас есть политика VPD, которая создает статический предикат, такой как cust_no = SYS_CONTEXT('order_entry', 'cust_num'); (как в руководство по Oracle VPD).

Это приводит к переписыванию запросов, поэтому:

SELECT * FROM orders;

становится:

SELECT * FROM orders 
  WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num');

Хорошо, пока это идет. Но что, если пользователь напишет:

SELECT * FROM orders WHERE my_malicious_function(secret_column);

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

Согласно документам, переписчик VPD выдаст что-то вроде:

SELECT * FROM orders 
  WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num')
    AND my_malicious_function(secret_column);

но Oracle может изменить порядок подпунктов в WHERE. Что мешает ему сначала запустить my_malicious_function, если он думает, что это будет более дешевый или более избирательный предикат? (Маловероятно, когда условием безопасности является поиск SYS_CONTEXT, но очень вероятно, если условие является подзапросом к другой таблице или является самой UDF).

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

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


security oracle row-level-security
person Craig Ringer    schedule 05.11.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

«Вредоносная функция» запускается после применения политики VPD, поэтому она не может видеть скрытые данные.

Итак, в вашем примере следующий запрос:

SELECT * FROM orders WHERE my_malicious_function(secret_column);

Переписывается на:

SELECT * FROM (
  SELECT * FROM orders orders
  WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num')
)
WHERE my_malicious_function(secret_column);

Поэтому функция выполняется только для строк, удовлетворяющих предикату VPD.

См.: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_rls.htm#i1005326

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

select c1, c2, ... from tab tab where <predicate>

person Jeffrey Kemp    schedule 06.11.2013
comment
Ах, хорошо, так что документация чрезмерно упрощает процесс переписывания запроса, и на самом деле между предикатом VPD и предикатом, предоставленным пользователем, применяется порядок. Предположительно, какой-то флаг, чтобы остановить оптимизатор, который также проталкивает внешние условия в представление. Большое спасибо за ссылку. - person Craig Ringer; 06.11.2013
comment
Ради интереса, а что, если вредоносная функция является частью предиката, сгенерированного для VPD, и пытается (скажем) выбрать из таблицы, к которой она обычно не может получить доступ? Затем пользователь с более высокими/другими привилегиями получает доступ к таблице, затронутой политикой VPD, и запускает функцию вредоносного предиката. IOW, обратный случай, когда определитель политики VPD использует другого пользователя. Я подозреваю, что ответ на это будет заключаться в том, чтобы не давать права на настройку политики VPD ненадежным пользователям, но мне любопытно. - person Craig Ringer; 06.11.2013
comment
Вы правы — не давайте привилегии полиса VPD тому, кому вы не доверяете. - person Jeffrey Kemp; 06.11.2013