On Tue, Jan 15, 2013 at 3:02 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> This patch adds sepgsql the feature of name qualified creation label.
>
> Background, on creation of a certain database object, sepgsql assigns
> a default security label according to the security policy that has a set of
> rules to determine a label of new object.
> Usually, a new object inherits its parent (e.g table is a parent of column)
> object's label, unless it has a particular type_transition rule in the policy.
> Type_transition rule allows to describe a particular security label as
> default label of new object towards a pair of client and parent object.
> For example, the below rule says columns constructed under the table
> labeled as "sepgsql_table_t" by client with "staff_t" will have
> "staff_column_t", instead of table's label.
> TYPE_TRANSITION staff_t sepgsql_table_t:db_column staff_column_t;
>
> Recently, this rule was enhanced to take 5th argument for object name;
> that enables to special case handling exceptionally.
> It was originally designed to describe default security labels for files in
> /etc directory, because many application put its own configuration files
> here, thus, traditional type_transition rule was poor to describe all the
> needed defaults.
> On the other hand, we can port this concept of database system also.
> One example is temporary objects being constructed under the pg_temp
> schema. If we could assign a special default label on this, it allows
> unprivileged users (who cannot create persistent tables) to create
> temporary tables that has no risk of information leak to other users.
> Otherwise, we may be able to assign a special security label on
> system columns and so on.
>
> From the perspective of implementation on sepgsql side, all we need
> to do is replace old security_compute_create_raw() interface by new
> security_compute_create_name_raw().
> If here is no name qualified type_transition rules, it performs as if
> existing API, so here is no backword compatible issue.
>
> This patch can be applied on the latest master branch.
This looks OK on a quick once-over, but should it update the
documentation somehow?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company