Re: Label switcher function

I revised my patch as I attached.

The hook function is modified and consolidated as follows:

typedef enum FunctionCallEventType
{
FCET_BE_HOOKED,
FCET_PREPARE,
FCET_START,
FCET_END,
FCET_ABORT,
} FunctionCallEventType;

typedef Datum (*function_call_event_type)(Oid functionId,
FunctionCallEventType event,
Datum event_arg);
extern PGDLLIMPORT function_call_event_type function_call_event_hook;

Unlike the subject of this e-mail, now it does not focus on only switching
security labels during execution of a certain functions.
For example, we may use this hook to track certain functions for security
auditing, performance tuning, and others.

In the case of SE-PgSQL, it shall return BoolGetDatum(true), if the target
function is configured as a trusted procedure, then, this invocation will
be hooked by fmgr_security_definer. In the first call, it shall compute
the security context to be assigned during execution on FCET_PREPARE event.
Then, it switches to the computed label on the FCET_START event, and
restore it on the FCET_END or ECET_ABORT event.

I also fixed up regression test, dummy_seclabel module and its
documentation as Robert pointed out in another topic.

Thanks,

(2010/11/14 13:16), KaiGai Kohei wrote:
> (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)ak(dot)jp(dot)nec(dot)com>