Chris,
What is your opinion about this reworks?
If its scale is too large to commit at once, I can separate it
into several pieces.
Thanks,
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,
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> refpolicy mailing list
> refpolicy@xxxxxxxxxxxxxx
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
