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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
