Re: Label switcher function

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Label switcher function
Date: 2010-11-14 04:16:30
Message-ID: 4CDF629E.6070801@kaigai.gr.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2010/11/14 11:19), Robert Haas wrote:
> 2010/11/12 KaiGai Kohei<kaigai(at)kaigai(dot)gr(dot)jp>:
>> The attached patch allows the security label provider to switch
>> security label of the client during execution of certain functions.
>> I named it as "label switcher function"; also called as "trusted-
>> procedure" in SELinux community.
>>
>> This feature is quite similar idea toward security definer function,
>> or set-uid program on operating system. It allows label providers
>> to switch its internal state that holds security label of the
>> client, then restore it.
>> If and when a label provider said the function being invoked is
>> a label-switcher, fmgr_security_definer() traps this invocation
>> and set some states just before actual invocations.
>>
>> We added three new hooks for security label provider.
>> The get_client_label and set_client_label allows the PG core to
>> save and restore security label of the client; which is mostly
>> just an internal state of plugin module.
>> And, the get_switched_label shall return NULL or a valid label
>> if the supplied function is a label switcher. It also informs
>> the PG core whether the function is switcher or not.
>
> I don't see why the plugin needs to expose the label stack to core PG.
> If the plugin needs a label stack, it can do that all on its own. I
> see that we need the hooks to allow the plugin to selectively disable
> inlining and to gain control when function execution starts and ends
> (or aborts) but I don't think the exact manipulations that the plugin
> chooses to do at that point need to be visible to core PG.
>
Hmm. I designed this patch according to the implementation of existing
security definer function, but it is not a only design.

Does the "label stack" means that this patch touches xact.c, doesn't it?
Yes, if we have above three hooks around function calls, the core PG
does not need to manage a label stack.

However, I want fmgr_security_definer_cache to have a field to save
private opaque data, because it is not a very-light step to ask SE-Linux
whether the function is trusted-procedure and to allocate a string to
be applied during execution, although switching is a very-light step.
So, I want to compute it at first time of the function calls, like as
security definer function checks syscache at once.

Of course, it is a private opaque data, it will be open for other usage.

> For SE-Linux, how do you intend to determine whether or not the
> function is a trusted procedure? Will that be a function of the
> security label applied to it?
>
When the function being invoked has a special security label with
a "type_transition" rule on the current client's label in the
security policy, SE-Linux decides the function is trusted procedure.

In other words, we can know whether or not the function is a trusted
procedure by asking to the security policy. It is a task of the plugin.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2010-11-14 10:30:59 Re: [COMMITTERS] pgsql: Improved parallel make support
Previous Message Darren Duncan 2010-11-14 03:54:21 Re: Refactoring the Type System