Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

Christopher J. PeBenito wrote:
> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> I'm out of arguments; clearly I'm in the minority on this issue.  I
>>>>> already said I wouldn't block the policy over this, so KaiGai, if you
>>>>> would send a last patch based on the revisions I made [1], let see if we
>>>>> can finally get this merged.
>>>>>
>>>>> [1] http://marc.info/?l=selinux&m=120999566809541&w=2
>>>> I'll submit a revised version later.
>>>> (Now we cannot update SVN repository, due to server maintenance.)
>>>>
>>>> Before this, I want to modify the following points:
> 
>>>> - postgresql_unconfined() interface should also associate a domin
>>>>   with sepgsql_client_type, not only sepgsql_unconfined_type.
>>>>   dontaudit rules on row-level logs are not disabled for unconfined
>>>>   clients. And, it's not useful to write additional policy module.
>>> I don't understand what you mean about the dontaudits.  Otherwise, you
>>> should recheck the unconfined rules.  I'm fairly sure I copied anything
>>> relevant from the client rules into unconfined so I didn't have to add
>>> both attributes in postgresql_unconfined().
>> A table can contain massive tuples in generally. If 50% of 1,000,000 tuples
>> are labaled as "Classified" and hidden from clients (includes unconfined
>> domain), tuple-level access denied log will make a flood of logs.
>> The dontaudit rule enables to restain the problem.
>>
>> I intended sepgsql_client_type means all domains connectable to SE-PostgreSQL.
>> If it dosen't contain unconfined domains, I think its name is a bit confusable
>> and something like "sepgsql_unpriv_type" is better for its name.
> 
> The fact is that we need an interface for unconfined access.  If the
> privileged client access is equivalent to unconfined access, then I feel
> that the unconfined interface is clearer.

OK, it is clear enough for me.


>> Then, the above dontaudit rule should be rewritten as follows:
>>
>>   dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \
>>             { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *;
>>
>> At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off
>> tuple-level access logs, but you suggested it is unnecessary, so I removed it.
> 
> I don't agree because of:
> 
> +allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
> +allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;
> 
> so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do
> anything since the access is allowed.

It is correct in type enforcement.
But MCS/MLS can prevent to access by unconfined domains, and make flood of
access denied logs.


>> In addition, I found an unclear point which came from my original policy. :(
>>
>>   allow sepgsql_unconfined_type postgresql_t:db_blob { import export };
>>
>> A blob import interface enables to read a file on a server host by the server
>> process (postgresql_t), and import to database as several frames of largeobject.
>> A export interface works for inversed direction.
>>
>> In the previous discussion, the meaning of these permission is to indicate
>> server process to start importing or exporting.
>> However, I'm now considering the following rules are more sensefull:
>>
>>   1. SE-PostgreSQL checks whether the client has db_blob:{import} for
>>      the target large object.
>>   2. SE-PostgreSQL checks whether the client has file:{read} for
>>      the target file.
>>   3. SELinux (kernel) checks whether postgresql_t has file:{read} for the
>>      target file, because it uses read(2) system call.
>>
>> Could you tell me your opinion?
> 
> I'll defer to Josh on this one since he knows much more about databases
> than I do.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.