| From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SE-PostgreSQL Specifications |
| Date: | 2009-07-24 23:45:47 |
| Message-ID: | 20090724234547.GF5407@samason.me.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
> Thanks, but I found an incorrect change at the trusted procedure section.
>
> Old)
> CREATE TABLE customer (
> cid integer primary key,
> cname varchar(32),
> credit varchar(32)
> - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
> - );
>
> New)
> CREATE TABLE customer (
> cid integer primary key,
> cname varchar(32),
> credit varchar(32)
> + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';
>
> This example intends to assign "secret" label on the credit column,
> not whole of the table. Note that the default security context shall
> be assigned on the table and rest of columns in this case.
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have a row
in the customer table with cid=1 whose security label would normally
prevent. We can perform:
SELECT show_credit(1);
and, as far as I can tell, this call would succeed.
--
Sam http://samason.me.uk/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-07-25 00:08:13 | Re: COPY WITH CSV FORCE QUOTE * -- REVIEW |
| Previous Message | Tom Lane | 2009-07-24 23:39:11 | Re: Non-blocking communication between a frontend and a backend (pqcomm) |