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

[Eamon Walsh <ewalsh@tycho.nsa.gov>]

KaiGai Kohei wrote:
> Joshua Brindle wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> Christopher J. PeBenito wrote:
>>>       
>> <snip>
>>
>>     
>>> 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.
>>>       
>
> db_blob:{write} is also checked here...
>
>   
>>>   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?
>>>       
>> Chris asked me to look at this for him. The access checks above seem completely
>> reasonable to me, much better than the previous check.
>>
>> I wonder though, how you'll do an export check between the client and file type,
>> since a compute_create between the client and the target directory may be different
>> than between postgresql_t and the directory? Which context would you attempt to use?
>>     
>
> In export case, the target file is labeled as a newly created one between
> postgresql_t and its parent directly, as SELinux attaches in default.
>
> We can understand the behavior as PostgreSQL owns this file and delivers
> its file descriptor to the client. Thus, the client should be checked
> the file:{write} permission for the result of compute_create between
> postgresql_t and the parent directly.
>   

Doesn't the kernel handle this automatically? Which is to say, if you
give a file descriptor to another process (I'm assuming it gets passed
through the local socket), the kernel still checks read and write on
every access.



> It does not give us any mismatching between DAC and MAC.
> So, I think it is more suitable than using setfscreatecon() to force the
> result between the client and the parent directly.
>
> In the conclusion, the following permissions will be checked for blob export.
>
> 1. SELinux (kernel) checks file:{write} between postgresql_t and the newly
>    created file which is labeled as the result between postgresql_t and
>    the parent directory.
>    This file is owned by PostgreSQL in DAC world.
> 2. SE-PostgreSQL checks db_blob:{export read} between the client and the target
>    large object.
> 3. SE-PostgreSQL checks file:{write} between the client and the target file.
>
> Thanks,
>   


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


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