А теперь плохие новости

А теперь плохие новости

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

С возможностью при инсталляции Firebird 1.5 ограничивать местоположение внешних объектов, к которым может обращаться сервер, ситуация несколько улучшается. При этом риски не устраняются полностью- вы должны выполнить конкретные шаги по реализации этой возможности и созданию ограничений файловой системы операционной системы. Доступ по умолчанию к внешним файлам в инсталляторе установлен в NONE, и каталоги внешних функций ограничены деревом UDF. Ваша задача - позаботиться о системных ограничениях.

Системные таблицы, где Firebird хранит все метаданные, включая сами привилегии SQL, вовсе не защищены привилегиями SQL.

Совет, как наказать идиотов-пользователей и плохих парней

Мой уважаемый коллега Павел Цизар (Pavel Cisar) предложил прием устранения недостатка привилегий SQL по защите метаданных Firebird, когда идиоты- пользователи, минуя DDL, пытаются изменять метаданные в системных таблицах, внося в них беспорядок. Это также отражает злонамеренные попытки разрушить ваши метаданные с помощью скрипта. Вот данное решение.

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

Все, что нужно сделать, - это просто установить управление доступом к системным таблицам путем выполнения серии операторов GRANT ALL <системная таблица> то PUBLIC. После этого мы можем отменить любые права.

Я не знаю точного технического объяснения, каким именно образом это работает, но это мой совет. Оператор GRANT создает управляющий список доступа (Access Control List, ACL) для системной таблицы, который проверяется в коде. Какая-то ветвь в этом коде означает "предоставить всем все привилегии, если элемент ACL не найден для системной таблицы, иначе использовать ACL".

Следует помнить некоторые вещи.

• Эта установка не сохраняется после восстановления базы данных из резервной копии, следовательно, напишите скрипт, который вы будете использовать каждый раз для только что восстановленной базы данных.

• Вам нужно быть внимательным по поводу удаления прав SELECT у PUBLIC К некоторым системным таблицам, потому что функции API isc_biob_iookup_desc() и isc_array_iookup_bounds() зависят от этой возможности. От этого также могут зависеть некоторые инструментальные средства и библиотеки.

• Удаление прав записи в системные таблицы не ограничивает возможность их изменения обычным нормальным способом с использованием команд DDL. Предотвращается только бесполезная прямая корректировка системных таблиц.

Привилегия дает возможность пользователю иметь некий вид доступа к объекту в базе данных. Она предоставляется с помощью оператора GRANT и убирается с использованием оператора REVOKE.

Синтаксис разрешения доступа:

GRANT <привилегия> ON <объект>

ТО <пользователь>;

привилегия, предоставленная пользователю к объекту, создает разрешение. Синтаксис для удаления разрешений:

REVOKE <привилегия> ON <объект>

FROM <пользователь>;

Доступны некоторые варианты "центрального" синтаксиса. Мы рассмотрим их несколько позже.