Re: [RFC] SELinux and PostgreSQL (draft v2)

[KaiGai Kohei <kaigai@kaigai.gr.jp>]

>>> Firstly, I didn't notice any getattr permission...
>> I also agreed your opinion.
>> But we have to pay attention on what select and getattr are 
>> always used together on regular tables, because PostgreSQL 
>> packed metadata of each column into result set.
>> (It's a purely implementation matter.)
>>
> 
> Which includes all data and schema labels..

Of course, updating system catalog should be protected by
relabelfrom/relabelto and setattr permission, not only update.

>>>> - delete a row
>>>> Becaues the delete opetation involves the whole of one row, 
>>>> column:delete is not evaluated when we try to delete a row.
>>>> (Thus, it's not defined.)
>>>> This behavior may be a bit controvertible.
>>> Maybe the column object class could have an entry deletefrom which 
>>> allows deleting a row that has an entry in that column.
>> It will solve the matter from TE viewpoint, but how dose it 
>> handle the MLS/MCS constraint?
>> If the client must dominate any columns when a row is 
>> deleted, it seems to me that the client must have the highest 
>> or upper clearance originally.
>>
> 
> Only if the policy says that. Delete would be a write which means anyone
> below it can do so. A worse problem is when someone is a high clearance
> and can't delete a row because one of the fields is below him. I think
> this makes the deletefrom permission unnecessarilly restrictive. It
> might be sufficient to need delete on the table and row.

Indeed, it seems to me a bit strange behavior.
I also think row deletion should be controlled by table and row's permission.

Thanks.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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