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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
