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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
