Re: Updates of SE-PostgreSQL 8.4devel patches

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> I updated the series of patches for SE-PostgreSQL 8.4devel.
>>
>> [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
>> [2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
>> [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1043.patch
>> [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1043.patch
>> [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1043.patch
>
> I looked over the patches listed above. They have line counts listed
> below:
>
> 10759 sepostgresql-sepgsql-8.4devel-3-r1043.patch
> 616 sepostgresql-pg_dump-8.4devel-3-r1043.patch
> 826 sepostgresql-policy-8.4devel-3-r1043.patch
> 1237 sepostgresql-docs-8.4devel-3-r1043.patch
> 836 sepostgresql-tests-8.4devel-3-r1043.patch
> 14274 total
>
> Particularly interesting was the doc patch,
> sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
> checks the permission level of the client process (getpeercon) and uses
> that to determine what the user should see.

Yes, this is a significant point which tends to be misunderstood.
When two processes with individual security context on operating system
connect to SE-PostgreSQL, they will get individual result, even if they
logged in as a same database role.

> Also interesting is how a
> new row-level system permission column references a new table
> 'pg_security', which holds security credentials for the row.
>
> The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
> which modifies the backend. About 30% of it or 3k lines modify our
> backend, and the rest are indepdendent support routines in their own C
> files.

The 3k lines (which is named as PGACE security framework) part was provided
as separated patches, but I was pointed out it requires reviewers to see
two files in same time. So, these were integrated into one.

> So, I am now reevaluating how we should proceed with this patch.
>
> I think we know we want column-level permissions and that is being
> worked on, so it should reduce the size of the 3k part of that patch
> slightly.
>
> As far as backend changes the largest part is the row-level permissions.
> Do we want row-level permissions to be accessible at the SQL level,
> perhaps optionally, by having a role be associated with a row, and only
> role members can see it. If we do, and implement it, the 3k part is
> reduced significantly.
>
> FYI, SE-PostgreSQL sets _row_ permissions by assigning to the new
> permissions system column:
>
> INSERT INTO drink (security_context, id, name, price)
> VALUES('system_u:object_r:sepgsql_table_t:SystemHigh', 7, 'tea', 130);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That string is what is placed in 'pg_security' and a reference to is
> placed on the row.

Yes, it looks like every tuple has text formatted security attribute,
but they hold an Oid value of pg_security system catalog.
Because this feature is provided by common foundation, any other
security features can also use the system column for its purpose
(like storing row-level database acl now in development).

> The other conclusion I came to is that the other 11k of patch is really
> independent SE-Linux interface code and not likely to change in size no
> matter what we implement at the SQL level.

Yes, the primary purpose of this archtecture is to minimize the impact
for the core PostgreSQL implementation, when user choose an enhanced
security mechanism.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>