Christopher J. PeBenito wrote: > On Tue, 2008-05-27 at 14:34 -0400, 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). > > If we have a default contexts configuration, then none of the above > statements would be needed: speaking of the last statement, in the > absence a type_transition, clients that create databases would still get > sepgsql_db_t as the type for the database, since that is the default > database type. As I wrote in the reply to Stephen, it is not a default context. These rules are used to initialize SE-PostgreSQL itself with proper security context. I thought you concerned about using a domain of server process as a target of type_transition because its relationship is not clear like ones between a directory and files. > Nonetheless, it sounds like you don't have a problem with the libselinux > change, as long as its just for the default contexts only, right? Then > creating objects with something other than the default context would be > the job of type_transition. What do you think the type_transition rules on db_database class should be described as a relationship between a client process and ... ? I don't think we need default contexts for any database object managed under database itself (like table, column, procedure, ...). We can describe it with type_transition enough. The matter is how to decide the root of type_transition in the world of database. Does it come from a server process? client process itself? configuration file? or initial context? Thanks, >>> 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.
