Due to rewriting of queries by the <productname>PostgreSQL</productname> rule system, other tables/views than those used in the original query get accessed. When update rules are used, this can include write access to tables. PostgreSQLのルールシステムによる問い合わせの書き換えによって、オリジナルの問い合わせで使われたものではない他のテーブル/ビューがアクセスされます。 更新ルールを使うことによってテーブルへの書き込みアクセスを包含することができます。
Rewrite rules don't have a separate owner. The owner of
a relation (table or view) is automatically the owner of the
rewrite rules that are defined for it.
The <productname>PostgreSQL</productname> rule system changes the
behavior of the default access control system. With the exception of
<literal>SELECT</literal> rules associated with security invoker views
(see <link linkend="sql-createview"><command>CREATE VIEW</command></link>),
all relations that are used due to rules get checked against the
privileges of the rule owner, not the user invoking the rule.
This means that, except for security invoker views, users only need the
required privileges for the tables/views that are explicitly named in
their queries.
書き換えルールに別々の所有者はいません。
リレーション(テーブルまたはビュー)の所有者は自動的にそれに定義された書き換えルールの所有者となります。
PostgreSQLのルールシステムはデフォルトのアクセス制御システムの振舞いを変更します。
セキュリティ実行者ビュー(CREATE VIEW
を参照)に関連付けられているSELECT
ルールを除いて、ルールのために使用されるすべてのリレーションは、ルールを起動するユーザではなくルール所有者の権限でチェックされます。
このことは、セキュリティ実行者ビューを除き、ユーザは問い合わせで明記するテーブル/ビューに対しての権限だけあればよいことを示しています。
For example: A user has a list of phone numbers where some of them are private, the others are of interest for the assistant of the office. The user can construct the following: 例えば、以下のようにします。 あるユーザが、いくつかは個人用の、その他は事務所で秘書が利用するための、電話番号のリストを持っていたとします。 ユーザは次のようにして構築することができます。
CREATE TABLE phone_data (person text, phone text, private boolean); CREATE VIEW phone_number AS SELECT person, CASE WHEN NOT private THEN phone END AS phone FROM phone_data; GRANT SELECT ON phone_number TO assistant;
Nobody except that user (and the database superusers) can access the
<literal>phone_data</literal> table. But because of the <command>GRANT</command>,
the assistant can run a <command>SELECT</command> on the
<literal>phone_number</literal> view. The rule system will rewrite the
<command>SELECT</command> from <literal>phone_number</literal> into a
<command>SELECT</command> from <literal>phone_data</literal>.
Since the user is the owner of
<literal>phone_number</literal> and therefore the owner of the rule, the
read access to <literal>phone_data</literal> is now checked against the user's
privileges and the query is permitted. The check for accessing
<literal>phone_number</literal> is also performed, but this is done
against the invoking user, so nobody but the user and the
assistant can use it.
そのユーザ(とデータベースのスーパーユーザ)以外はphone_data
テーブルにアクセスできません。
しかし、GRANT
により秘書はphone_number
ビューに対しSELECT
できます。
ルールシステムはphone_number
からのSELECT
操作をphone_data
からのSELECT
操作に書き換えます。
そのユーザはphone_number
の所有者、したがってルールの所有者ですから、phone_data
の読み込みに対するアクセスはそのユーザの権限に従ってチェックされ、問い合わせを受け付けてもよいことになります。
phone_number
へのアクセスもチェックされますが、これは呼び出したユーザに対して行われますので、秘書とユーザ以外は使うことができません。
The privileges are checked rule by rule. So the assistant is for now the
only one who can see the public phone numbers. But the assistant can set up
another view and grant access to that to the public. Then, anyone
can see the <literal>phone_number</literal> data through the assistant's view.
What the assistant cannot do is to create a view that directly
accesses <literal>phone_data</literal>. (Actually the assistant can, but it will not work since
every access will be denied during the permission checks.)
And as soon as the user notices that the assistant opened
their <literal>phone_number</literal> view, the user can revoke the assistant's access. Immediately, any
access to the assistant's view would fail.
権限はルールごとにチェックされます。
ですから秘書だけが今のところ公開の電話番号を参照することができます。
しかし、秘書は別のビューを作成し、それにPUBLICに対するアクセス許可を与えることができます。
こうすると秘書のビューを通して誰もがphone_number
データを見ることができます。
秘書ができないことはphone_data
に直接アクセスするビューを作ることです
(実際には作成はできますが、アクセスは全て、権限チェックで拒絶されます)。
そして、秘書が独自のphone_number
ビューを開いたことにユーザが気付いた時点で、秘書の権限を取り上げることができます。
秘書のビューへのアクセスは即座に失敗に終わります。
One might think that this rule-by-rule checking is a security
hole, but in fact it isn't. But if it did not work this way, the assistant
could set up a table with the same columns as <literal>phone_number</literal> and
copy the data to there once per day. Then it's the assistant's own data and
the assistant can grant access to everyone they want. A
<command>GRANT</command> command means, <quote>I trust you</quote>.
If someone you trust does the thing above, it's time to
think it over and then use <command>REVOKE</command>.
このルールごとのチェックがセキュリティホールになると考える人がいるかもしれませんが、実際にはそうではありません。
もしこのように機能しないとなると、秘書はphone_number
と同じ列を持ったテーブルを用意して、1日1回データをそこにコピーするかもしれません。
そうなると、データは彼のものですから、誰にアクセス権を与えようが彼の自由です。
GRANT
は「あなたを信用しています」ということです。
信用している誰かがこのようなことを行った場合は、考えを変えてREVOKE
してください。
Note that while views can be used to hide the contents of certain
columns using the technique shown above, they cannot be used to reliably
conceal the data in unseen rows unless the
<literal>security_barrier</literal> flag has been set. For example,
the following view is insecure:
上に示したような手法を使ってある列の内容を隠すのにビューは使えますが、security_barrier
フラグが設定されていない限り、見えない行にあるデータを隠す信頼できる方法ではない事に注意してください。
例えば、以下のビューは安全ではありません。
CREATE VIEW phone_number AS SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
This view might seem secure, since the rule system will rewrite any
<command>SELECT</command> from <literal>phone_number</literal> into a
<command>SELECT</command> from <literal>phone_data</literal> and add the
qualification that only entries where <literal>phone</literal> does not begin
with 412 are wanted. But if the user can create their own functions,
it is not difficult to convince the planner to execute the user-defined
function prior to the <function>NOT LIKE</function> expression.
For example:
ルールシステムがphone_number
からのSELECT
をphone_data
からのSELECT
に書き換え、phone
が412で始まらない項目のみが必要だという条件を追加しますので、このビューは安全に見えます。
しかし、ユーザが自身の関数を作成できるのであれば、NOT LIKE
式の前にユーザ定義の関数を実行するようプランナを説得することは難しくありません。
例えば以下の通りです。
CREATE FUNCTION tricky(text, text) RETURNS bool AS $$ BEGIN RAISE NOTICE '% => %', $1, $2; RETURN true; END; $$ LANGUAGE plpgsql COST 0.0000000000000000000001; SELECT * FROM phone_number WHERE tricky(person, phone);
Every person and phone number in the <literal>phone_data</literal> table will be
printed as a <literal>NOTICE</literal>, because the planner will choose to
execute the inexpensive <function>tricky</function> function before the
more expensive <function>NOT LIKE</function>. Even if the user is
prevented from defining new functions, built-in functions can be used in
similar attacks. (For example, most casting functions include their
input values in the error messages they produce.)
プランナはより高価なNOT LIKE
の前に安価なtricky
関数を実行することを選びますので、phone_data
テーブルの人と電話番号はすべてNOTICE
として表示されます。
たとえユーザが新しい関数を定義できない場合でも、同様の攻撃で組み込み関数が使えます。
(例えば、ほとんどの型変換関数は生成するエラーメッセージに入力値を含んでいます。)
Similar considerations apply to update rules. In the examples of
the previous section, the owner of the tables in the example
database could grant the privileges <literal>SELECT</literal>,
<literal>INSERT</literal>, <literal>UPDATE</literal>, and <literal>DELETE</literal> on
the <literal>shoelace</literal> view to someone else, but only
<literal>SELECT</literal> on <literal>shoelace_log</literal>. The rule action to
write log entries will still be executed successfully, and that
other user could see the log entries. But they could not create fake
entries, nor could they manipulate or remove existing ones. In this
case, there is no possibility of subverting the rules by convincing
the planner to alter the order of operations, because the only rule
which references <literal>shoelace_log</literal> is an unqualified
<literal>INSERT</literal>. This might not be true in more complex scenarios.
同様の考慮は更新ルールにも適用できます。
前節の例において、データベースのテーブルの所有者はshoelace
ビューに対し、誰かにSELECT
、INSERT
、UPDATE
、DELETE
権限を与えることができます。
しかし、shoelace_log
に対してはSELECT
だけです。
ログ項目を書き込むルールアクションは支障なく実行され、また、他のユーザはログ項目を見ることができます。
しかし、他のユーザは項目を捏造したり、既に存在する項目を操作する、あるいは削除することはできません。
この場合、shoelace_log
を参照しているルールは条件のないINSERT
だけですので、操作の順序を変えるようにプランナを説得することでルールを破壊する可能性はありません。
これはより複雑な状況では正しくないかもしれません。
When it is necessary for a view to provide row-level security, the
<literal>security_barrier</literal> attribute should be applied to
the view. This prevents maliciously-chosen functions and operators from
being passed values from rows until after the view has done its work. For
example, if the view shown above had been created like this, it would
be secure:
ビューが行単位セキュリティを提供する場合には、そのビューにはsecurity_barrier
属性を付与するべきです。
これは、悪意を持って選ばれた関数や演算子が、ビューが適用されるより前に渡された行に対して実行されないようにします。
例えば、上記のビューが次のように定義された場合、これは安全です。
CREATE VIEW phone_number WITH (security_barrier) AS SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
Views created with the <literal>security_barrier</literal> may perform
far worse than views created without this option. In general, there is
no way to avoid this: the fastest possible plan must be rejected
if it may compromise security. For this reason, this option is not
enabled by default.
security_barrier
を付けて定義されたビューは、このオプションなしのビューよりも性能の劣る問い合わせ実行プランを生成します。一般的に、最も高速だが、セキュリティ上の問題がある問い合わせ実行プランを破棄しなければならないという状況は不可避です。そのため、このオプションはデフォルトでは有効になっていません。
The query planner has more flexibility when dealing with functions that
have no side effects. Such functions are referred to as <literal>LEAKPROOF</literal>, and
include many simple, commonly used operators, such as many equality
operators. The query planner can safely allow such functions to be evaluated
at any point in the query execution process, since invoking them on rows
invisible to the user will not leak any information about the unseen rows.
Further, functions which do not take arguments or which are not passed any
arguments from the security barrier view do not have to be marked as
<literal>LEAKPROOF</literal> to be pushed down, as they never receive data
from the view. In contrast, a function that might throw an error depending
on the values received as arguments (such as one that throws an error in the
event of overflow or division by zero) is not leak-proof, and could provide
significant information about the unseen rows if applied before the security
view's row filters.
プランナは副作用が無い関数をもう少し柔軟に扱います。
これらの関数はLEAKPROOF
属性を持っており、等価演算子など、単純で広く用いられる演算子も多く含まれます。
利用者に対して不可視な行に対するこれら関数の呼び出しはいかなる情報も漏えいさせないため、プランナはこれらの関数をどのような場所でも安全に実行させる事ができます。
さらに、引数をとらなかったり、セキュリティバリアビューから引数を渡されない関数は、ビューからデータを渡されることは決して無いため、プッシュダウンされるためのLEAKPROOF
をマークする必要はありません。
一方、受け取った引数の値に応じてエラー(例えばオーバーフローやゼロ除算など)を発生させるかもしれない関数は leak-proof ではありません。
これがもしセキュリティ・ビューの条件句でフィルタリングされるより前に適用されたなら、不可視行に関する何か重要な情報を与える事ができてしまいます。
It is important to understand that even a view created with the
<literal>security_barrier</literal> option is intended to be secure only
in the limited sense that the contents of the invisible tuples will not be
passed to possibly-insecure functions. The user may well have other means
of making inferences about the unseen data; for example, they can see the
query plan using <command>EXPLAIN</command>, or measure the run time of
queries against the view. A malicious attacker might be able to infer
something about the amount of unseen data, or even gain some information
about the data distribution or most common values (since these things may
affect the run time of the plan; or even, since they are also reflected in
the optimizer statistics, the choice of plan). If these types of "covert
channel" attacks are of concern, it is probably unwise to grant any access
to the data at all.
ビューがsecurity_barrier
属性付きで定義されたとしても、それは限定的な意味で安全である、つまり不可視な行の内容が潜在的に安全でない関数に渡される事がないという事を意図しているにすぎません。
利用者には不可視な行に対して何らかの推測を行う他の手段があるかもしれません。例えば、EXPLAIN
を用いて問い合わせ実行プランを見たり、ビューに対する問い合わせ実行時間を計測したりすることです。
悪意の攻撃者は不可視データの量を推測したり、分散や最頻値(なぜなら、これらはオプティマイザの統計情報を通じて実行プランの選択、ひいては実行時間に影響するかもしれません)に関する何らかの情報を得る事ができるかもしれません。
もし、この種の"隠れチャネル"攻撃に対する対策が必要であれば、とにかくデータに対するアクセスを許可するのは得策ではありません。