Stephen Smalley wrote: > On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote: >> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote: >>> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote: >>>> Hello, >>>> >>>> The attached patch enables to obtain the default security context of newly >>>> created database, defined at /etc/selinux/*/contexts/postgresql_contexts . >>>> >>>> The format is as follows: >>>> -------- >>>> # >>>> # Config file for SE-PostgreSQL >>>> # >>>> # <domain of client> <type of newly created database> >>>> unconfined_t sepgsql_db_t >>>> * sepgsql_db_t >>>> -------- >>>> >>>> '*' means default security context, if given key is not matched for any entry. >>>> >>>> This API requires the security context of client as a key, and it returns >>>> a security context to be attached for a newly created database. >>>> It has a type field defined in the right-hand of config file, and inherits >>>> user and lower-range field of given security context as a key. >>>> >>>> e.g) >>>> selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); >>>> returns "user_u:object_r:sepgsql_db_t:s0". >>> Chris is investigating the use of roles on objects in order to provide >>> more fully featured RBAC support without requiring use of per-role >>> domains. Hardcoding the use of object_r won't be future compatible for >>> that situation, and more generally we don't want to hardcode policy >>> information in libselinux at all. >>> >>> I'm also unclear as to why type_transition rules aren't a better way of >>> expressing the above, although I know you've been discussing this with >>> Chris for some time. Logically I'd expect the client domain to be the >>> source type of the transition, and the type for the newly created >>> database to be the new/result type of the transition. What to use as >>> the target type is less clear; we'd have a similar issue if we were to >>> use type_transitions for e.g. sockets. It could either be the client >>> domain both as source and target (self relationship, no related object) >>> or the client domain as source and the object manager domain as target. >>> >>> Chris, what is the objection to using type transitions here, as they are >>> for labeling new objects and this seems to fit that situation? >> I think KaiGai took my idea a little to far. My issue was just to have >> postgres determine what the default label for its objects are via >> postgresql_contexts. A derived role/type still makes sense to be stated >> via (type|role)_transition. I suspect there was confusion on this >> point. I mainly had an issue with statements like: >> >> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; >> type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; >> type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; >> type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; >> type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t; > > The first four statements don't make sense to me; the last one does make > sense (i.e. when a postgres client creates a new database, where the > only related "object" in view is that object manager's context, label > the new database with sepgsql_db_t). That last instance seems valid as > a way of expressing types for new databases; the first four statements > seem to be more suited to this postgres contexts configuration (as they > are independent of client domain entirely). When SE-PostgreSQL initializes itself, a server process is a client process in same time. The first four rules are necessary to attach proper context of any system object on initialization. It does not means something default. In the "default" behavior, if we have no type_transition, - a newly created database inherits the type of server process - a newly created table/procedure/largeobject inherits the type of database - a newly created column/tuple inherits the type of table >> which I feel should be instead be expressed in a postgresql_contexts >> file that says the default context for a database is ::seqpgsql_db_t, >> default context for table is ::sepgsql_sysobj_t, etc. >> >> This makes perfect sense staying as a type_transition in the policy: >> >> type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t; -- 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.
