begriffs open source - ai-pg/blob - full-docs/txt/rules-privileges.txt

   1
   2 39.5. Rules and Privileges #
   3
   4    Due to rewriting of queries by the PostgreSQL rule system, other
   5    tables/views than those used in the original query get accessed. When
   6    update rules are used, this can include write access to tables.
   7
   8    Rewrite rules don't have a separate owner. The owner of a relation
   9    (table or view) is automatically the owner of the rewrite rules that
  10    are defined for it. The PostgreSQL rule system changes the behavior of
  11    the default access control system. With the exception of SELECT rules
  12    associated with security invoker views (see CREATE VIEW), all relations
  13    that are used due to rules get checked against the privileges of the
  14    rule owner, not the user invoking the rule. This means that, except for
  15    security invoker views, users only need the required privileges for the
  16    tables/views that are explicitly named in their queries.
  17
  18    For example: A user has a list of phone numbers where some of them are
  19    private, the others are of interest for the assistant of the office.
  20    The user can construct the following:
  21 CREATE TABLE phone_data (person text, phone text, private boolean);
  22 CREATE VIEW phone_number AS
  23     SELECT person, CASE WHEN NOT private THEN phone END AS phone
  24     FROM phone_data;
  25 GRANT SELECT ON phone_number TO assistant;
  26
  27    Nobody except that user (and the database superusers) can access the
  28    phone_data table. But because of the GRANT, the assistant can run a
  29    SELECT on the phone_number view. The rule system will rewrite the
  30    SELECT from phone_number into a SELECT from phone_data. Since the user
  31    is the owner of phone_number and therefore the owner of the rule, the
  32    read access to phone_data is now checked against the user's privileges
  33    and the query is permitted. The check for accessing phone_number is
  34    also performed, but this is done against the invoking user, so nobody
  35    but the user and the assistant can use it.
  36
  37    The privileges are checked rule by rule. So the assistant is for now
  38    the only one who can see the public phone numbers. But the assistant
  39    can set up another view and grant access to that to the public. Then,
  40    anyone can see the phone_number data through the assistant's view. What
  41    the assistant cannot do is to create a view that directly accesses
  42    phone_data. (Actually the assistant can, but it will not work since
  43    every access will be denied during the permission checks.) And as soon
  44    as the user notices that the assistant opened their phone_number view,
  45    the user can revoke the assistant's access. Immediately, any access to
  46    the assistant's view would fail.
  47
  48    One might think that this rule-by-rule checking is a security hole, but
  49    in fact it isn't. But if it did not work this way, the assistant could
  50    set up a table with the same columns as phone_number and copy the data
  51    to there once per day. Then it's the assistant's own data and the
  52    assistant can grant access to everyone they want. A GRANT command
  53    means, “I trust you”. If someone you trust does the thing above, it's
  54    time to think it over and then use REVOKE.
  55
  56    Note that while views can be used to hide the contents of certain
  57    columns using the technique shown above, they cannot be used to
  58    reliably conceal the data in unseen rows unless the security_barrier
  59    flag has been set. For example, the following view is insecure:
  60 CREATE VIEW phone_number AS
  61     SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
  62
  63    This view might seem secure, since the rule system will rewrite any
  64    SELECT from phone_number into a SELECT from phone_data and add the
  65    qualification that only entries where phone does not begin with 412 are
  66    wanted. But if the user can create their own functions, it is not
  67    difficult to convince the planner to execute the user-defined function
  68    prior to the NOT LIKE expression. For example:
  69 CREATE FUNCTION tricky(text, text) RETURNS bool AS $$
  70 BEGIN
  71     RAISE NOTICE '% => %', $1, $2;
  72     RETURN true;
  73 END;
  74 $$ LANGUAGE plpgsql COST 0.0000000000000000000001;
  75
  76 SELECT * FROM phone_number WHERE tricky(person, phone);
  77
  78    Every person and phone number in the phone_data table will be printed
  79    as a NOTICE, because the planner will choose to execute the inexpensive
  80    tricky function before the more expensive NOT LIKE. Even if the user is
  81    prevented from defining new functions, built-in functions can be used
  82    in similar attacks. (For example, most casting functions include their
  83    input values in the error messages they produce.)
  84
  85    Similar considerations apply to update rules. In the examples of the
  86    previous section, the owner of the tables in the example database could
  87    grant the privileges SELECT, INSERT, UPDATE, and DELETE on the shoelace
  88    view to someone else, but only SELECT on shoelace_log. The rule action
  89    to write log entries will still be executed successfully, and that
  90    other user could see the log entries. But they could not create fake
  91    entries, nor could they manipulate or remove existing ones. In this
  92    case, there is no possibility of subverting the rules by convincing the
  93    planner to alter the order of operations, because the only rule which
  94    references shoelace_log is an unqualified INSERT. This might not be
  95    true in more complex scenarios.
  96
  97    When it is necessary for a view to provide row-level security, the
  98    security_barrier attribute should be applied to the view. This prevents
  99    maliciously-chosen functions and operators from being passed values
 100    from rows until after the view has done its work. For example, if the
 101    view shown above had been created like this, it would be secure:
 102 CREATE VIEW phone_number WITH (security_barrier) AS
 103     SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
 104
 105    Views created with the security_barrier may perform far worse than
 106    views created without this option. In general, there is no way to avoid
 107    this: the fastest possible plan must be rejected if it may compromise
 108    security. For this reason, this option is not enabled by default.
 109
 110    The query planner has more flexibility when dealing with functions that
 111    have no side effects. Such functions are referred to as LEAKPROOF, and
 112    include many simple, commonly used operators, such as many equality
 113    operators. The query planner can safely allow such functions to be
 114    evaluated at any point in the query execution process, since invoking
 115    them on rows invisible to the user will not leak any information about
 116    the unseen rows. Further, functions which do not take arguments or
 117    which are not passed any arguments from the security barrier view do
 118    not have to be marked as LEAKPROOF to be pushed down, as they never
 119    receive data from the view. In contrast, a function that might throw an
 120    error depending on the values received as arguments (such as one that
 121    throws an error in the event of overflow or division by zero) is not
 122    leakproof, and could provide significant information about the unseen
 123    rows if applied before the security view's row filters.
 124
 125    For example, an index scan cannot be selected for queries on security
 126    barrier views (or tables with row-level security policies) if an
 127    operator used in the WHERE clause is associated with the operator
 128    family of the index, but its underlying function is not marked
 129    LEAKPROOF. The psql program's \dAo+ meta-command is useful to list
 130    operator families and determine which of their operators are marked as
 131    leakproof.
 132
 133    It is important to understand that even a view created with the
 134    security_barrier option is intended to be secure only in the limited
 135    sense that the contents of the invisible tuples will not be passed to
 136    possibly-insecure functions. The user may well have other means of
 137    making inferences about the unseen data; for example, they can see the
 138    query plan using EXPLAIN, or measure the run time of queries against
 139    the view. A malicious attacker might be able to infer something about
 140    the amount of unseen data, or even gain some information about the data
 141    distribution or most common values (since these things may affect the
 142    run time of the plan; or even, since they are also reflected in the
 143    optimizer statistics, the choice of plan). If these types of "covert
 144    channel" attacks are of concern, it is probably unwise to grant any
 145    access to the data at all.