Skip site navigation (1) Skip section navigation (2)

Re: SE-PostgreSQL Specifications

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SE-PostgreSQL Specifications
Date: 2009-07-25 00:16:47
Message-ID: 4A6A4EEF.5010503@kaigai.gr.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Sam Mason wrote:
> 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.

This example shows that confined client cannot read credit card number
without using trusted procedure, but trusted procedure returns masked one.
It does not intend to hide existence of entries within customer table.

See the third box in the section.

  postgres=# SELECT cid, cname FROM customer;
   cid | cname
  -----+-------
    10 | jack
    13 | adam
    14 | liza
  (3 rows)

This query does not read from customer.credit, so it should be succeeded.

Thanks,
-- 
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

pgsql-hackers by date

Next:From: Mark KirkwoodDate: 2009-07-25 00:22:50
Subject: Re: Lock Wait Statistics (next commitfest)
Previous:From: Andrew DunstanDate: 2009-07-25 00:08:13
Subject: Re: COPY WITH CSV FORCE QUOTE * -- REVIEW

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group