[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

KaiGai Kohei kaigai at ak.jp.nec.com
Tue Mar 31 19:30:33 CDT 2009


The attached patch also reworks and fixes a few bugs in MLS/MCS policy
for SE-PostgreSQL. Could you check it please?

List of updates:
 * db_catalog, db_schema, db_sequence classes are newly constrained.
 * Removed permissions (db_database:{get_param set_param} and
   db_xxx:{use}) have gone away.
 * bugfix: MCS didn't constrain db_xxx:{getattr} permission.
 * bugfix: MCS didn't constrain db_procedure:{ drop getattr
           setattr relabelfrom } permission.
 * bugfix: MLS didn't constrain writer permission in db_procedure class.


KaiGai Kohei wrote:
> As we have discussed for the recent week, I have a plan to rework
> some of security policy for SE-PostgreSQL.
> The attached patch adds the significan changes, as follows.
> Could you give me any suggestion, approval or opposition?
> New object classes and permissions
> ----------------------------------
>  * db_catalog class
>    It shows the top level namespace in the database, and has a capability
>    to store a set of schemas. Some of implementation does not support
>    catalogs. In this case, we simply ignore this class and any schemas
>    are placed under the db_database directly.
>    It defines the following four permissions and inherited ones:
>      { search add_object remove_object associate }
>    Client should have db_catalog:{search} on the catalog when he refers
>    any schemas under the catalog, and he should also have
>    db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
>    when he tries to add or remove a shema within the catalog.
>    These permissions are an analogy of dir object class.
>    The db_catalog:{associate}, which I've not introduced yet but noticed
>    its necessity, is also checked when we create or relabel a schema
>    within the catalog, and the schema should have db_catalog:{associate}
>    on the catalog. It is an analogy of filesystem:{associate}.
>    It prevents a schema is labeled unexpectedly.
>  * db_schema class
>    It shows the second level namespace in the database, but it may be
>    the top level one in some of implementation (like PostgreSQL).
>    It has a capability to store a set of database objects (tables,
>    procedures and so on).
>    It defines the following four permissions and inherited ones:
>      { search add_object remove_object associate }
>    Their meanings are similar to ones in db_catalog class except for
>    the schema to be replaced by database objects.
>    Its security context can be computed with TYPE_TRANSITION between
>    the client as a subject and the database (or catalog, if availabel)
>    as a target.
>  * db_sequence class
>    It shows the sequential number generator objects. We can also use
>    them as a communication channel between two domains, so it is
>    necessary to apply security policy.
>    It inherits common database and defines the following two permissions:
>      { get_value set_value }
>    Client should have db_sequence:{get_value} when he fetch a value from
>    the sequence generator, and db_sequence:{set_value} when he set a
>    discretionary value. When he fetch a value from the sequence object,
>    it implicitly increments internal counter, but it is covered by the
>    get_value permission.
>    Its security context can be computed with TYPE_TRANSITION between
>    the client as a subject and the schema as a target.
> Change definition of object classes
> -----------------------------------
>  * db_database class
>    The db_database:{get_param set_param} is removed because these two
>    permissions are nonsense.
>    The db_database:{superuser} is newly added. It is checked when
>    client perform as database superuser. Stephen suggested it can
>    be separated to more finer grained privileges. It makes sense,
>    but this kind of separation which focuses on PostgreSQL makes
>    hard to port the concept for other database management systems.
>  * db_table/db_column/db_tuple:{use} permission
>    The db_xxx:{use} permission is integrated into db_xxx:{select}
>    permission, because it can hide the risk to infer invisible
>    information easily with well considered WHERE clauses.
> user_sepgsql_xxxx_t types
> -------------------------
>  * Currently, sepgsql_proc_t is assigned to the procedures created
>    by unprivileged and unprefixed clients, like httpd_t.
>    But I would like to handle it as a procedure created or relabeled
>    by database administrator.
>    Basically, we consider user defined procedures are untrusted, so
>    it should be checked before it becomes available for all the clients.
>    So, we don't allow to install them as system internal entities, and
>    don't allow unconfined domains to execute them directly.
>    My preference is the user_sepgsql_xxxx_t is also assigned to
>    procedures created by unprivileged and unprfixed client.
> A schema for temporary obejcts
> ------------------------------
>  * The sepgsql_schema_t is the default type for schema objects, and
>    rest of database objects within the schema is labeled with the chain
>    of TYPE_TRANSITION rules.
>    We have a characteristic scheme named as "pg_temp_*". Any database
>    objects within the schema are cleared after the session closed,
>    so its contents are always session local. We would like to assign
>    special types on the temporary schema and delivered database objects
>    withing the schema. In addition, users can create and use these
>    database objects independently from the sepgsql_enable_users_ddl.
> Booelean behavior: sepgsql_enable_users_ddl
> -------------------------------------------
>  * Because the current design does not care about actions on schema
>    objects, we need to assign separated label (sepgsql_sysobj_t) on
>    system informations and apply checks as row-level controls.
>    But db_schema object class enables to control user's DDLs in
>    the schema level checks mainly, so now sepgsql_enable_user_ddl
>    focuses on db_schema class permissions and {create drop setattr}
>    for any other database objects.
>    The attached patch allows users to modify tuples with sepgsql_sysobj_t
>    but not allows columns/tables. It means user can define database
>    objects with proper way (like CREATE TABLE), but prevents to
>    manipulate system information by hand.
>    In addition, this boolean controls only user_sepgsql_xxxx_t.
>    The unprefixed types are always not allowed to modify its definition
>    by unprivileges users.
> db_table:{lock} for reader actions
> ----------------------------------
>  * db_table:{lock} is also necessary for reader side actions due to the
>    implementation reason.
>    In PostgreSQL, FK constraints are implemented as trigger functions.
>    It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
>    and run a secondary query to check whether the action satisfies
>    FK constraints or not.
>    This query is described as:
>      SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
>    The "FOR SHARE" clause means explicit table lock and requires
>    db_table:{lock} permission. If we don't allow unpriv clients to
>    lock read-only tables, it disables to set up FK constraint which
>    refers read-only tables.
> Miscellaneous changes
> ---------------------
>  * The security context of a new database is decided via type_transition
>    on the server process's context. It enables to avoid conflicts when
>    we have multiple DBMSs in a system.
>  * It allows postgresql_t domain to write out messages to system audit.
>  * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
>  * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
>    because we don't need to run trusted procedure implicitly.
>  * Most of postgresql_role() are shared with postgresql_unpriv_client(),
>    except for "role $1 types sepgsql_trusted_proc_t;"
>  * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
> Thanks,

OSS Platform Development Division, NEC
KaiGai Kohei <kaigai at ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-mls-fixes.patch
Type: text/x-patch
Size: 7575 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090401/c475e053/attachment-0001.bin 

More information about the refpolicy mailing list