Sam Mason wrote:
> 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!)
In this case, confined users cannot create a function labeled as
'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
controlled by db_procedure:{create} permission.
Confined user can create a function with "user_sepgsql_proc_exec_t"
(which is the default one for confined users), but it is not a trusted procedure,
so the "SELECT * FROM customer" is executed with confined user's privileges as is,
then it will be failed due to the lack of permission on the customer.credit.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
