Re: SE-PostgreSQL Specifications

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
>> Sam Mason wrote:
>>> 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';
>> 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.
>
> Yes, that seems reasonable. The fact that you're still talking about
> "confined users" is slightly worrying and would seem to imply that
> there is still a superuser/normal user divide--it's probably just a
> terminology thing though.
>
> One thing I know I don't understand is what the security labels actually
> mean; I've had a couple of searches through your pages now and can't see
> anything described nor pointers to external documentation.

I assume the wikipage (SEPostgreSQL_Draft) is a draft for the PostgreSQL
official documentation. However, the list of security labels originates
from the default security policy in SELinux.
So, I think an external link will be preferable for the references.

TODO: I'll make the list of security labels we can assign on.

>> 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.
>
> So an "unconfined user" (whatever that means??) is basically working
> with DACs then?

Sorry for using the undefined terminology.

The default security policy provides several security contexts that we
can assign on user's shell process, such as user_t, staff_t and unconfined_t.
(Please note that the security context of processes means its privileges.)

SELinux checks privileges of processes without any exceptions.
However, the default security policy allows anything on unconfined_t label.
It means "unconfined" users are allowed anything according to the policy.
(BTW, we can unplug the "unconfined" label using modular policy stuff.)

On the other hand, rest of security context (user_t, staff_t or httpd_t for
web servers) are "confined", because the security policy does not allow
such widespread permissions.

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