Re: security label support, part.2

(2010/07/23 20:44), Robert Haas wrote:
> 2010/7/23 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>> Hmm. How about if there's just one provider loaded, you can omit it,
>>> but if you fail to specify it and there's>1 loaded, we just throw an
>>> error saying you didn't specify whose label it is.
>>>
>> Perhaps, we need to return the caller a state whether one provider checked
>> the given label at least, or not.
>
> Return to the caller? This is an SQL command. You either get an
> error, or you don't.
>
Ahh, I was talked about relationship between the core PG code and ESP module.
It means the security hook returns a state which informs the core PG code
whether one provider checked the given label, then the core PG code can
decide whether it raise an actual error to users, or not.

In other words, I'd like to suggest the security hook which returns a tag
of ESP module, as follows:

const char *
check_object_relabel_hook(const ObjectAddress *object,
const char *provider,
const char *seclabel);

The second argument reflects "FOR <provider>" clause. It informs ESP modules
what provider is specified. If omitted, it will be NULL.

Then, ESP module which checked the given security label must return its tag.
Maybe, "selinux", if SE-PostgreSQL. Or, NULL will be returned if nobody
checked it. If NULL or incorrect tag is returned, the core PG code can know
the given seclabel is not checked/validated, then it will raise an error to
users.

Elsewhere, the validated label will be stored with the returned tag.
It enables to recognize what label is validated by SELinux, and what label
is not.

>> If it was omitted, all the providers try to check the given label, but it
>> has mutually different format, so one of providers will raise an error at
>> least.
>
> Yeah, but it won't be a very clear error, and what if you have, say, a
> provider that allows arbitrary strings as labels? Since this is a
> security feature, I think it's a pretty bad idea to allow the user to
> do anything that might be ambiguous.
>
It is provider's job to validate the given security label.
So, if we install such a security module which accept arbitrary strings
as label, the core PG code also need to believe the ESP module.

But the arbitrary label will be tagged with something other than "selinux",
so it does not confuse other module, according to the above idea.

>> It means we have to specify the provider when two or more providers are
>> loaded, but not necessary when just one provider.
>
> But that should be fine. Loading multiple providers should, as you
> say, be fairly rare.
>
>>>>> I think it is 100% clear that row-level security will require
>>>>> completely separate infrastructure, and therefore I'm not even a tiny
>>>>> bit worried about this. :-)
>>>>>
>>>> Hmm. Are you saying we may degrade the feature when we switch to the
>>>> completely separate infrastructure? Is it preferable??
>>>
>>> Uh... no, not really. I'm saying that I don't think we're backing
>>> ourselves into a corner. What makes you think we are?
>>>
>> Sorry, meaning of the last question was unclear for me.... Is it a idiom?
>
> I don't understand why we wouldn't be able to support multiple
> providers for row-level security. Why do you think that's a problem?
>
I don't have any clear reason why we wouldn't be able to support multiple
labels on user tuples, but it is intangible anxiety, because I have not
implemented it as a working example yet.
(So, I never think it is impossible.)

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