Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>>> but the auto-creation of pg_security rows does make this problematic.
>>> regproc works because it only supports pre-created pg_proc rows.
>> Yes, the security label has a different characteristic at the point.
>>
>>> Can we support two data types, one for read-only and another for
>>> possible creation? That is not going to work for a query like
>>>
>>> SELECT * FROM x WHERE col != 'valid_but_new_security_label'::regseclabel;
>>>
>>> because the cast would fail if the pg_security row doesn't exist, but
>>> the query itself perhaps might succeed and return rows.
>> It has a same matter. If user cast a text into the type of possible
>> creation, it can cause an unnecessary insertion.
>
> Right. I was trying to point out that you can't assume that every
> string you cast to ::regseclabel is going to already exist in
> pg_security; in this case, we are doing a not equal so we don't assume
> it is already in the table.

Yes, I didn't describe the case explicitly, because the case when
given string is already on pg_security is not an issue.

>>> Can we require joins to use pg_security directly? I wish I could think
>>> of some magic that indicated the pg_security row should be created.
>> We should not allow users to join them directly, and should not expose
>> what identifier is used internally, because some of ISO/IEC15408 has
>> requirements to export/import user data with meaningful security labels.
>> The numeric security identifier is just an internal usage.
>
> Yes, I was going to ask if there was any API we need to follow, and you
> are confirming that an insert of a text string must be possible for that
> column.

Common Criteria v3.1 : Part 2 Security functional components
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R2.pdf

It describes about export/import of user data with security attributes
on FDP_ETC.2 and FDP_ITC.2 section. These items are considered as basic
facilities to be provided by MAC system, and requires it has a capability
to export/import user data with security attributes.
Since CC is designed for general purpose, it does not specify format
of security attribute, but it is quite natural it is a security label
in text representation on MAC system.
At least, previous certified MAC system (like SELinux) interprets it so.

> We can do an auto-cast of the string to the internal data type
> so the call to the function that inserts into pg_security would be
> invisible, but your point that it might create lots of pg_security rows
> that aren't referenced is a good one.

Yes, it was the older design in SE-PostgreSQL, and it is worse than
the current implementation.
The current one inserts tuples necessity minimum.

>> Here is one another idea.
>> How do you think asymmetric input/output handlers?
>>
>> At first, I have to introduce the current implementation.
>> It can receives user input values as TEXT or ACLITEM[], ant these are
>> fetched at fetchWritableSystemAttribute() on execMain.c.
>> Please note that they have no side-effect on the prior stage.
>> Then, it invokes rowaclSecurityAclToSid() or pgaceSecurityLabelToSid()
>> to translate the values into security identifier. These functions can
>> insert a new tuple into pg_security, if not found.
>> Then, the translated security identifiers are set on the HeapTupleHeader
>> using HeapTupleSetRowAcl() or HeapTupleSetSecLabel().
>>
>> If the input handler is asymmetric, it can handle the given user input
>> as a TEXT or ACLITEM[], and can deliver them fetchWritableSystemAttribute()
>> as is. But asymmetric output handler can translate given security identifier
>> into proper user visible data.
>>
>> However, I don't think it is a fair enough solution. :(
>> The current implementation seems to me better.
>
> Interesting. It is really up to the people who work in the heap fetch
> area of the code to tell us how disruptive the security framework can be
> in that area of the code.

As I noted on the following message, I reconsidered the asymmetric
input/output handler is not a productive idea.

It is still unclear for me why heap_getsysattr() has to return
a value with same format in storage. If we can change the point
of view, it is possible to return a value generated in runtime
based on any other attributes/userdata of tuples.

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