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

[Andy Warner <warner@rubix.com>]

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



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.
>
>   
>> 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.
>   
Actually, thats what I did. My choice of words (hardcoding) wasn't the best
>   
>> 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.
>   
I like to be in that loop
>
>
>   

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