KaiGai Kohei wrote:
> The attached patch is the first one in the series of reworks for
> the SE-PostgreSQL security policy.
>
> It updates the following items.
>
> * Changes in the definition of object classes
>
> This patch add new three object classes and modifies the definition
> of a few object classes.
> - db_database:{get_param set_param} is removed due to nonsense.
> - db_database:{superuser} is added to restrict privileges of
> database superuser.
> - db_table/db_column/db_tuple:{use} is removed due to nonsense.
> - New object classes: db_catalog, db_schema and db_sequence are added.
>
>
In the RUBIX policy I used the db_table use permission (could be called
open) to have a simple way to control access to the table as a whole,
much like a file open permission. While not absolutely necessary, I
think it is valuable. The other uses of the use permission I did not
use. Also, see my related comment below on the catalog/schema object
permissions.
> In the previous design, we have the following object hierarchy:
> [db_database]
> + [db_table]
> | + [db_column]
> | + [db_tuple]
> + [db_procedure]
> + [db_blob]
>
> The newly added db_schema should be placed between the db_database and
> the db_table and others. TYPE_TRANSITION rules follows the revised design.
>
> [db_database]
> + [db_schema]
> | + [db_table]
> | | + [db_column]
> | | + [db_tuple]
> | + [db_procedure]
> | + [db_sequence] (newly added object class)
> + [db_blob]
>
> (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
> although it can be used to communicate channel between multiple
> domains. So, it needs to be placed under the database.
>
> Currently, SE-PostgreSQL does not use db_catalog class, but it can be
> used for other DBMS's.
>
> In addition, this patch changes something.
>
> o The trusted procedure (sepgsql_trusted_proc_t) lost the
> db_database:{superuser} privilege, because it is invoked by
> unprived users to over the MAC restriction for a certain
> purpose, but it does not need to allow superpower in DAC.
>
Is it intended that the superuser privilege give only DAC override or
both MAC and DAC? Specifically, is it intended to override MLS or Type
enforcement?
> o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
> db_procedure:{install} privilege, because once installed procedure
> as a system internal entity can be invoked implicitly.
> We should not install trusted procedures for the purpose.
>
> o The db_schema:{add_object remove_object} newly added are controled
> via the "sepgsql_enable_users_ddl" boolean.
> Now we control user's DDLs on uncategorized objects as row-level
> checks on sepgsql_sysobj_t, but it can be revised with adding
> db_schema object class.
>
I think this also needs the equivalent of a "search" permission (or
open, or use). This gives a nice way to control some access to an entire
schema. That is, we want to use the schema (and catalog) as a mechanism
to cut off users from entire subtrees. This helps to ensure that a user
does not gain access to a newly created subordinate object. So, if a
user does not have search for a schema (or catalog), there is no way
they can access any present or future object in that schema (or
catalog). Analogous to a directory. Without this search control I would
continue to use the dir object class.
> o type_transition for user_sepgsql_XXXX_t is moved to outside of
> tunable_policy(`...'). IIRC, I said these should be inside of
> the tunable, but unprive ones cannot create/drop tables labeled
> as sepgsql_XXX_t anyway when the boolean is disabled.
> So, I reconsidered it should be placed out of the tunable.
>
> o {create drop setattr} permission for user_sepgsql_XXX is moved
> to inside of the tunable_policy, even if it is db_procedure
> class. I wonder why we didn't control CREATE FUNCTION statement
> by unpriv domains.
>
> o db_blob:{import export} on user_sepgsql_blob_t is allowed to
> unpriv domains. It seems to me a strange behavior that it is
> not allowed on the object created by unpriv domain itself.
>
> * Remaining items
> o When we allows an unpriv domain to access SE-PostgreSQL using
> postgresql_unpriv_client(), its default labeling behavior is
> same as unconfined domains. For example, functions created by
> them are labeled as "sepgsql_proc_t".
> Now I'm considering it should be user_sepgsql_XXXX_t, because
> I would like to handle unprefixed types as an object created
> by database administrator (unconfined domains).
> It helps correctness of db_procedure:{install} permission.
>
> o Because of db_schema object class, we can control user's DDLs
> without ad-hoc using row-level security on sepgsql_sysobj_t
> class. Now I think its purpose should be changed to prevent
> users accesses system catalogs directly.
>
Are you implying here the need for something like a search or open
permissions as I suggested above? If so, please disregard my previous
comment:-)
> Thanks,
>
--
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.
