Re: Updates of SE-PostgreSQL 8.4devel patches (r1155) - Mailing list pgsql-hackers
From | KaiGai Kohei |
---|---|
Subject | Re: Updates of SE-PostgreSQL 8.4devel patches (r1155) |
Date | |
Msg-id | 4909214A.6040907@ak.jp.nec.com Whole thread Raw |
In response to | Re: Updates of SE-PostgreSQL 8.4devel patches (r1155) (Simon Riggs <simon@2ndQuadrant.com>) |
List | pgsql-hackers |
Simon Riggs wrote: > On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote: > >> I've updated my patches, these are ready for CommitFest:Nov. >> >> [1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch >> [2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch >> [3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1155.patch >> [4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1155.patch >> [5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1155.patch >> [6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1155.patch >> >> The comprehensive documentation for SE-PostgreSQL is here: >> http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.) >> >> List of updates: >> - Patches are rebased to the latest CVS HEAD. >> - bugfix: TRUNCATE checks assumed SECCLASS_DB_TUPLE object class >> - bugfix: sepgsqlCopyFile assumed SECCLASS_FILE object class, but it has to be >> adjusted by st_mode. >> >> Request for Comments: >> - The 4th patch is actually needed? It can be replaced by wiki page. >> - Do you think anything remained towards the final CommitFest? >> - Do you have any reviewing comment? Most of patches are unchanged from >> the previous vesion. If you can comment anything, I can fix them without >> waiting for the final commit fest. >> > > I'm copying some general comments from my contact here, verbatim. Other > comments have been requested and may be forthcoming: > > By way of background "Common Criteria" (ISO Standard 15408) are in > effect pre-defined security requirements that have been agreed between > multiple friendly governments so that they can share the results from > independent lab work in each country and avoid the costs and duplication > of effort. The published lab work results in two outputs: > - a "Target of Evaluation" (TOE) i.e. tight definition of the software > version, configuration and environment (hardware, external controls) > which was the subject of the evaluation > - an "Evaluation Report" which, in the "happy case" has assigns an > "Evaluation Assurance Level" (EAL) number to the product (which needless > to say is only valid if the product is used in its TOE > > If you're interested in reading more about formal Government security > evaluation schemes, these are some good sites: Thanks for your information. However, I've also followed the Common Criteria for a few years, and some of facilities came from its requirements. The "security_context" system column reflects the requirement of labeled import/export, for example. Don't worry. Let's move our discussion into its implementation in the upcoming CommitFest. It's a good time now. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
pgsql-hackers by date: