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

Re: SE-PostgreSQL Specifications

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 (view raw or flat)
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/

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-07-25 00:08:13
Subject: Re: COPY WITH CSV FORCE QUOTE * -- REVIEW
Previous:From: Tom LaneDate: 2009-07-24 23:39:11
Subject: Re: Non-blocking communication between a frontend and a backend (pqcomm)

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