Joshua Brindle wrote:
  

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.
    

It had been a headache what is the target of TYPE_TRANSITION for the root
object.
At the initial design, as you pointed out, I used the domain of server
process as the target to decide the security context of database itself.
Then, I got a suggestion that we can use the following notation to
represent the security context of new object is determined by only
the context of subject.

  TYPE_TRANSITION <subject context> <subject context> : <class> <new context>;

I could understand as an analogy of permission checks on the kernel
capability classes.

  

TYPE_TRANSITION <server context> <server context> : <class> <new context>;

TYPE_TRANSITION <subject context> <server context> : <class> <new context>;

Where the 1st has the potential to cover all permutations (but only one new context) and the latter opens the possibility to have different new contexts based upon the context of the subject, but could leave some permutations uncovered. I think the second case is more general and flexible and the first case could be viewed as a special case of the second.

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 also think we should not hold any hardcode context inside the DBMS.

  

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?
    

It is the case of deterministration for the root object.
When we set up the initial database, PostgreSQL with bootstraping mode also
performs as a client concurrently.
Please consider the "postgresql_t" represents the case when it performs
as a client, not only a server.

Thanks,