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-25 00:30:07
Message-ID: 20090725003007.GH5407@samason.me.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
> Sam Mason wrote:
> >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.

This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:

CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
LANGUAGE 'sql'
SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
AS 'SELECT * FROM customer';

(I hope I've modified the example correctly!)

--
Sam http://samason.me.uk/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-07-25 00:47:56 Re: Non-blocking communication between a frontend and a backend (pqcomm)
Previous Message Mark Kirkwood 2009-07-25 00:29:01 Re: Lock Wait Statistics (next commitfest)