From: warner@rubix.com (Andy Warner)
Date: Fri, 10 Dec 2010 13:18:56 +0100
Subject: [refpolicy] [PATCH] New database object classes
In-Reply-To: <4D01F7A4.90708@ak.jp.nec.com>
References: <4D01F7A4.90708@ak.jp.nec.com>
Message-ID: <4D021AB0.9040900@rubix.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On 12/10/2010 10:49 AM, KaiGai Kohei wrote:
> The attached patch adds a few database object classes, as follows:
>
> * db_schema
> ------------
> A schema object performs as a namespace in database; similar to
> directories in filesystem.
> It seems some of (but not all) database objects are stored within
> a certain schema logically. We can qualify these objects using
> schema name. For example, a table: "my_tbl" within a schema: "my_scm"
> is identified by "my_scm.my_tbl". This table is completely different
> from "your_scm.my_tbl" that it a table within a schema: "your_scm".
> Its characteristics is similar to a directory in filesystem, so
> it has similar permissions.
> The 'search' controls to resolve object name within a schema.
> The 'add_name' and 'remove_name' controls to add/remove an object
> to/from a schema.
> See also,
>   http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
>
> In the past discussion, a rubix folks concerned about no object
> class definition for schema and catalog which is an upper level
> namespace. Since I'm not certain whether we have a disadvantage
> when 'db_schema' class is applied on catalog class, I don't add
> this definition yet.

>From my point of view, as a rubix folk, I see no disadvantage in using
the db_schema class for catalogs. As we are now overloading the dir
object class, using the db_schema for both schemata and catalogs is an
improvement. For us in the foreseeable future, there is no functional
distinction.

I do think that the SQL spec does allow things to be associated with a
named schema that may not be associated with a catalog. For instance, a
character set. But, don't quote me on that:-)

Forgive me for my ignorance, but when a patch like this is submitted to
the refpolicy, will it eventually make it into Fedora and/or RHEL 6?

> Default security context of 'db_table' and 'db_procedure' classes
> get being computed using type_transition with 'db_schema' class,
> instead of 'db_database' class. It reflects logical hierarchy of
> database object more correctly.
>
>
> * db_view
> ----------
> A view object performs as a virtual table. We can run SELECT
> statement on views, although it has no physical entities.
> The definition of views are expanded in run-time, so it allows
> us to describe complex queries with keeping readability.
> This object class uniquely provides 'expand' permission that
> controls whether user can expand this view, or not.
> The default security context shall be computed by type transition
> rule with a schema object that owning the view.
>
> See also,
>   http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
>
>
> * db_sequence
> --------------
> A sequence object is a sequential number generator.
> This object class uniquely provides 'get_value', 'next_value' and
> 'set_value' permissions. The 'get_value' controls to reference the
> sequence object. The 'next_value' controls to fetch and increment
> the value of sequence object. The 'set_value' controls to set
> an arbitrary value.
> The default security context shall be computed by type transition
> rule with a schema object that owning the sequence.
>
> See also,
>   http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
>
>
> * db_language
> --------------
> A language object is an installed engine to execute procedures.
> PostgreSQL supports to define SQL procedures using regular script
> languages; such as Perl, Tcl, not only SQL or binary modules.
> In addition, v9.0 or later supports DO statement. It allows us to
> execute a script statement on server side without defining a SQL
> procedure. It requires to control whether user can execute DO
> statement on this language, or not.
> This object class uniquely provides 'implement' and 'execute'
> permissions. The 'implement' controls whether a procedure can
> be implemented with this language, or not. So, it takes security
> context of the procedure as subject. The 'execute' controls to
> execute code block using DO statement.
> The default security context shall be computed by type transition
> rule with a database object, because it is not owned by a certain
> schema.
>
> In the default policy, we provide two types: 'sepgsql_lang_t' and
> 'sepgsql_safe_lang_t' that allows unpriv users to execute DO
> statement. The default is 'sepgsql_leng_t'.
> We assume newly installed language may be harm, so DBA has to relabel
> it explicitly, if he want user defined procedures using the language.
>
> See also,
>   http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
>   http://developer.postgresql.org/pgdocs/postgres/sql-do.html
>
> P.S)
> I found a bug in MCS. It didn't constraint 'relabelfrom' permission
> of 'db_procedure' class. IIRC, I fixed it before, but it might be
> only MLS side. Sorry.
>
> Thanks,
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101210/eccd8e4e/attachment.html