[RFC] permissions for conditional UPDATE statement

[RFC] permissions for conditional UPDATE statement

[kaigai]

It is a RFC in security design of SE-PostgreSQL.

In the current version of SE-PostgreSQL, {select update} for table,
column and tuple classes are required when a client execute a SQL
query with conditional UPDATE query, for example.

It means that the following SQL requires '{select update}' permission,
not only 'update', because the query tries to refer 'z' column
of 'tbl_1' table on WHERE clause.

  UPDATE tbl_1 SET x = 10, y = 'aaa' WHERE z = true;

The query indeed refers 'tbl_1', 'z' column and each targeted tuples,
so 'select' permission might be appropriate.
But there is a significant difference from general SELECT statement
from conditional UPDATE. It does not return its content.

We have a matter in this approach. DBA have to allow SELECT permission
to enable conditional UPDATE statement, even if he does not want to
expose its contents.

I have an idea to solve them. add 'reference' (or 'refer') permission
on table, column and tuple object classes.
It means references to those objects without returning their contents
to clients.

Any comments please,
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.

RE: [RFC] permissions for conditional UPDATE statement

[Joshua Brindle]

kaigai@kaigai.gr.jp wrote:
> It is a RFC in security design of SE-PostgreSQL.
> 
> In the current version of SE-PostgreSQL, {select update} for
> table, column and tuple classes are required when a client
> execute a SQL query with conditional UPDATE query, for example.
> 
> It means that the following SQL requires '{select update}'
> permission, not only 'update', because the query tries to
> refer 'z' column of 'tbl_1' table on WHERE clause.
> 
>   UPDATE tbl_1 SET x = 10, y = 'aaa' WHERE z = true;
> 
> The query indeed refers 'tbl_1', 'z' column and each targeted
> tuples, so 'select' permission might be appropriate.
> But there is a significant difference from general SELECT
> statement from conditional UPDATE. It does not return its content.
> 
> We have a matter in this approach. DBA have to allow SELECT
> permission to enable conditional UPDATE statement, even if he
> does not want to expose its contents.
> 
> I have an idea to solve them. add 'reference' (or 'refer')
> permission on table, column and tuple object classes.
> It means references to those objects without returning their contents
> to clients. 
> 

I agree to some extent. The where clause can be used to enumerate what
data might be but doesn't tell you what it is explicitely (the boolean
above is a bad example, something like an unknown string is a lot
harder). I kind of like the 'use' permission more, it can be used
anywhere this sort of thing happens where extra granularity doesn't
help.

As an aside, I'm glad to see you are continuing this work dispite
resistance upstream. Do you have a plan for inclusion? Have you talked
to upstream offline or somewhere not public about what their problems
are?


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

Re: [RFC] permissions for conditional UPDATE statement

[KaiGai Kohei]

Joshua Brindle wrote:
> kaigai@kaigai.gr.jp wrote:
>> It is a RFC in security design of SE-PostgreSQL.
>>
>> In the current version of SE-PostgreSQL, {select update} for
>> table, column and tuple classes are required when a client
>> execute a SQL query with conditional UPDATE query, for example.
>>
>> It means that the following SQL requires '{select update}'
>> permission, not only 'update', because the query tries to
>> refer 'z' column of 'tbl_1' table on WHERE clause.
>>
>>   UPDATE tbl_1 SET x = 10, y = 'aaa' WHERE z = true;
>>
>> The query indeed refers 'tbl_1', 'z' column and each targeted
>> tuples, so 'select' permission might be appropriate.
>> But there is a significant difference from general SELECT
>> statement from conditional UPDATE. It does not return its content.
>>
>> We have a matter in this approach. DBA have to allow SELECT
>> permission to enable conditional UPDATE statement, even if he
>> does not want to expose its contents.
>>
>> I have an idea to solve them. add 'reference' (or 'refer')
>> permission on table, column and tuple object classes.
>> It means references to those objects without returning their contents
>> to clients. 
>>
> 
> I agree to some extent. The where clause can be used to enumerate what
> data might be but doesn't tell you what it is explicitely (the boolean
> above is a bad example, something like an unknown string is a lot
> harder). I kind of like the 'use' permission more, it can be used
> anywhere this sort of thing happens where extra granularity doesn't
> help.

Thanks, I'll add 'use' permission.
Is there any more opinion?

> As an aside, I'm glad to see you are continuing this work dispite
> resistance upstream. Do you have a plan for inclusion? Have you talked
> to upstream offline or somewhere not public about what their problems
> are?

I don't think PostgreSQL people oppose to SE-PostgreSQL approach.
But the timing I posted RFC was not good, because it was just after
features freezed for PostgreSQL 8.3 beta. :(
Now, the discussions are suspended by PostgreSQL 8.3 beta is released.

By the way, I attended to PostgreSQL conference 2007/Tokyo yesterday,
to have my presentation and to talk a man of PostgreSQL global development
team. (He is a guy who introduced SE-PostgreSQL on the pgsql-hackers list)
In the short discussion, he recommended me to put SE-PostgreSQL on 8.4
merge line (planned to release at Oct 2008).
Maybe, there are several opinions in the PostgreSQL core developers.

Thanks,
-- 
Open Source Software Promotion Center, 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.