Вивчаємо мітки доступу до рядків в Oracle: приклади не самого очевидного поведінки захисту

попередня стаття серії












"Настала темрява,
Не ходи за ворота:
Хто на вулицю потрапив –
Заблукав і пропав ".
Корній Чуковський, "Крадене сонце"
 
“And neither the angels in heaven above,
Nor the demons down under the sea,
Can ever dissever my soul from the soul
Of the beautiful Annabel Lee …”
Edgar Allan Poe, “Annabel Lee”

Зміст



Анотація


Ця стаття є безпосереднім продовженням статті Вивчаємо мітки доступу до рядків в Oracle: завдання властивостей стовпця доступу в таблиці, і розглядає приклади поведінки кошти Label Security в Oracle, що не є очевидними для неспеціаліста з мандатних доступу до даних. Показана можливість страхувати користувача від непередбачених для його рівня секретності дій і неочевидна особливість видачі користувачеві засекречених даних.

Припускаються у статті стан бази і сценарні файли відповідають кінця попередньої статті.

Не тільки захист рядків, але і страховка користувачів


Одна з цікавих особливостей меточного ("мандатної") доступу в тому, що він дозволяє власникові певного рівня доступу заборонити правку рядків, не тільки більш секретних, ніж йому належить, але також і рядків, менш секретних. Це нагадує кастовість по частині дії; так би мовити, "що належить бику, не можна робити Юпітеру". У Oracle Label Security ця особливість знайшла втілення, у чому легко переконатися.

Створимо нового користувача і дамо йому повноваження роботи виключно з "секретними" рядками:

CONNECT / AS SYSDBA

CREATE USER secretmanager IDENTIFIED BY secretmanager;

GRANT minimal TO secretmanager;

CONNECT lbacsys/lbacsys

BEGIN
SA_USER_ADMIN.SET_USER_LABELS
(
POLICY_NAME        =>  “empsec_policy”
,USER_NAME         =>  “secretmanager”
,MAX_READ_LABEL    =>  “limited”
, MIN_WRITE_LABEL  =>  “limited”);
END;
/

(Зауважте, що раніше параметр MIN_WRITE_LABEL у процедурі SET_USER_LABELS ми не використовували; в результаті умолчательную поведінки Label Security для користувача HEAD було MIN_WRITE_LABEL = "OPEN", що легко перевіряється за довідковими таблицями).

Перевіримо тепер можливості SECRETMANAGER з читання і по зміні полів рядків, в тому числі поля мітки:

SQL> CONNECT secretmanager/secretmanager
Connected.
SQL> @phones












ENAME PNO
SMITH
ALLEN
WARD
JONES
MARTIN
BLAKE
CLARK
SCOTT
KING
TURNER
ADAMS
JAMES
FORD
MILLER
665-7282
882-3154
610-1718
100-6539
103-1983
193-3112
310-2673
680-4853
542-6672
293-1398
278-5105
932-6728
485-9127
865-6706

14 rows selected.

SQL> @updateallenpnumber
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
… … … …

SQL> @updateallen OPEN
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
… … … …

SQL> @updateallen LIMITED
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
… … … …

Неможливо поміняти ні "основну" рядок для Аллена, ні мітку доступу до її телефоном. Зверніть увагу: незважаючи на це користувачеві SECRETMANAGER видно всі рядки – як помічені більш слабкою міткою OPEN, так і помічені міткою LIMITED. А тепер переведемо телефон Аллена з категорії OPEN в категорію LIMITED і поспостерігаємо, що він може робити з рядком "своєї" категорії секретності:

SQL> CONNECT head/head
Connected.
SQL> @updateallen LIMITED

1 row updated.

SQL> CONNECT secretmanager/secretmanager
Connected.
SQL> @updateallenpnumber

1 row updated.

SQL> @updateallen LIMITED

1 row updated.

SQL> @updateallen OPEN

1 row updated.

SQL> @updateallen OPEN
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
… … … …

Очевидно, користувач може читати як "свої" рядки, так і менш секретні, а ось змінювати менш секретні, ніж йому належить, рядки він не зможе. У наведеному прикладі таємний SECRETMANAGER знизив секретність рядки і втратив колишню можливість рядок ред. Ну, а більш секретні рядки він навіть не побачить!

Видача даних: нічого зайвого?


На завершення знайомства з меточним доступом до рядків в Oracle мені хотілося б підкреслити, що навіть без урахування структури міток, привілеїв, групування користувачів і багато чого іншого, велика частина якого в цих статтях не розглядалася, мандатний метод доступу не так прямолінійний у поведінці, як міг би здатися спочатку.

Розглянемо звичайну видачу даних, помічених мітками доступу. Згадаймо, що до цих пір в таблиці PHONE у нас було по одному номеру телефону на кожного співробітника. Спробуємо додати другий телефон Аллену, а так як сценарій phones.sql використовує для видачі на екран напіввідкрите з'єднання, вживання його залишиться коректним і для цих нових даних. Інтерес представляє випадок, коли телефони Аллена (коли їх стане два) будуть мати позначку LIMITED, і коли до них звернеться користувач EMPLOYEE. Інтуїція підказує, що "невидимі" телефони Аллена будуть оброблятися напіввідкритим з'єднанням подібно пропущеному значенням (NULL), і в результаті вибірки ми побачимо кілька рядків для Аллена з пропущеними значеннями номерів телефону. А що насправді?

Додамо до таблиці PHONE для Аллена новий телефон і "засекретимо" обидва:

CONNECT head/head

INSERT INTO scott.phone
SELECT empno, “111-2222”, empsec_label
FROM scott.phone
WHERE empno = (SELECT empno FROM scott.emp WHERE ename=”ALLEN”)

@updateallen LIMITED

Перевіряємо:

SQL> @phones












ENAME PNO
SMITH
ALLEN
ALLEN
WARD
JONES
MARTIN
BLAKE
CLARK
SCOTT
KING
TURNER
ADAMS
JAMES
FORD
MILLER
665-7282
111-2222
882-3154
610-1718
100-6539
103-1983
193-3112
310-2673
680-4853
542-6672
293-1398
278-5105
932-6728
485-9127
865-6706

15 rows selected.

SQL> CONNECT employee/employee
Connected.
SQL> @phones





































ENAME PNO
ALLEN   
WARD 610-1718
MARTIN 103-1983
BLAKE  
CLARK  
KING  
TURNER 293-1398
JAMES 932-6728
MILLER 865-6706

9 rows selected.

Меточний доступ в Oracle справедливо показав користувачеві EMPLOYEE ім'я Аллена (його рядок у таблиці EMP у відкритому доступі), і не показав його телефони (ми закрили доступ до телефонів Аллена в таблиці PHONE), але от тільки відкрите з'єднання таблиць EMP і PHONE показало "відсутність" (на ділі – недоступність) телефону одним рядком, а не двома! Нічого зайвого: телефон недоступний, а скільки їх недоступне – не повідомляється. Якщо ж зробити один з телефонів Аллена відкритим, інформація про наявність другого, недоступного телефону і зовсім пропаде:

SQL> CONNECT head/head
Connected.
SQL> UPDATE scott.phone
2  SET
3    empsec_label
4  = CHAR_TO_LABEL ( “empsec_policy”, “OPEN” )
5  WHERE
6    pno = “111-2222”
7  /

1 row updated.

SQL> CONNECT employee/employee
Connected.
SQL> @phones





































ENAME PNO
ALLEN  111-2222 
WARD 610-1718
MARTIN 103-1983
BLAKE  
CLARK  
KING  
TURNER 293-1398
JAMES 932-6728
MILLER 865-6706

9 rows selected.

Не думаю, що така поведінка для всіх очевидно, а значить наведені вище приклади можуть виявитися недаремними.


Посилання по темі



Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*