Andy Warner wrote: > > > KaiGai and I talked about this a bit already, and I'll preface my > response by saying that my memory of it is poor. Also, this issue was > one of my first practical introductions to selinux, so I'm sure I was > shooting in the dark. But, the main issue revolved around the type > transition rule for the database object. It seems to me, what makes it > special is that it has no parent object. It seems equivalent to writing > a type transition rule for creating the OS root directory, except in our > DBMS case we can have more than one type (each dbms has their own). > > A rule for sepostgres is: > > type_transition sepgsql_client_type sepgsql_client_type : db_database > sepgsql_db_t; > > Where I believe the standard user_t and such had the sepgsql_client_type > attribute. So, with that rule in place I think it was impossible for > rubix to have a similar rule, if our client_type's overlapped. Which > seems likely, as the user_t is a likely candidate for a client. For > instance, if I did this: strange, I thought he/we decided to use the domain of the dbms as the target for that type_transition. That would solve this particular problem, I'd have to go back in archives to understand why this path was chosen, or perhaps KaiGai remembers. > > type_transition rubix_client_type rubix_client_type : db_database > rubix_db_t; (where rubix_client_type contained user_t) > > I think it would not compile because its ambiguous, right? So, what I > did was write a rule like this: > > type_transition rubix_client_type rubix_t : db_database rubix_db_t; > > and hard-coded the rubix_t into the avc_compute_create call. The rubix_t > is actually the type of our server process. Prior to doing that, I could > not find a way to not have a database be created with a sepgsql_t type. > If you just used the dbms domain as the target you wouldn't need to hardcode anything. > I see (now) that the reference policy also has the rule: > > type_transition postgresql_t postgresql_t : db_database sepgsql_db_t; > > Obviously, the above would never conflict with another dbms's rules. If > that single type transition rule satisfied all of seposgresql's needs, > then that would eliminate the need for the conflicting rule. Though, I > assume thats dependent on the internals of seposgresql. >> This is for internally created db objects? Why are both this and the client -> client transitions needed? <snip> >> >> Yes, I don't mean they'd be using an identical policy but shared >> templates/interfaces that worked with both would certainly make it easier to >> target both systems without really needing to know the intricacies of each >> systems enforcement. >> > Sounds like a good goal. > It may be a pipe dream, like having a common policy for all MTA's. At least if there is some consensus on the internal object model, and since SQL is pretty much the same everywhere this may actually stand a chance. -- 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.
