Re: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner <warner@rubix.com>]

[-- Attachment #1: Type: text/plain, Size: 4476 bytes --]



KaiGai Kohei wrote:
> 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.
>
>   
It seems if you decide the context of the database using only the
subject's attributes itself, there will always be potential conflict
with other DBMS's. There is nothing in the type transition that
identifies the rule as applying to a sepostgresql dbms as opposed to any
other. It seems a bad way to do it. I would propose either:

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

or

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,
>   

[-- Attachment #2: Type: text/html, Size: 5318 bytes --]