[PATCH] SE-PgSQL/lite rev.2163

The SE-PostgreSQL patches are updated as follows:

[1/5] http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-02-core-8.5devel-r2163.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-03-gram-8.5devel-r2163.patch
[4/5] http://sepgsql.googlecode.com/files/sepgsql-04-tests-8.5devel-r2163.patch
[5/5] http://sepgsql.googlecode.com/files/sepgsql-05-docs-8.5devel-r2163.patch

List of updates:
* Patch set was organized to a few ones which provides only core features.
* Code base was upgraded to the latest CVS HEAD.
* Some of features in the fullset edition were separated, to focus on the core feature of SE-PostgreSQL at the first
commitfest.
 

The full functional SE-PostgreSQL consists of ten patches sequentially
numbered. The patch with smaller number provide more fundamental features.
Robert Haas suggested we should focus on a part of patches on the first
commit fest, because all the patch set of SE-PostgreSQL is a bit large
to review within a single commit fest. I agreed and reorganized my patches.
Some of advanced features (such as row-level controls) are separated
from the features to be focused on the 1st commit fest.
I decided to call the small functional SE-PostgreSQL as SE-PgSQL/lite
to make clear what we discuss on.

The SE-PgSQL/lite contains the following features.
* Management of the security labels (1st patch)SELinux's security model requires all the subjects and objects are
labeled.Itenables to assign a certain security label on several kinds of databaseobjects. The security label in text
formis stored within the new systemcatalog (pg_security), and the catalog/pg_security.c provides a facilityto translate
itand the security identifier.
 

* Core facility to communicate with in-kernel SELinux and to make its decision on various kind of database objcets.
(2ndpatch)The second patch provides the core functionality to perform with SELinux.It deploys security hooks on the
strategicpoints of PostgreSQL.The hooks invoke SE-PostgreSQL routines, when it is enabled. The routinesmakes its
decisionbased on the system's security policy.The userspace access vector cache
(src/backend/security/sepgsql/avc.c)minimizesthe number of kernel space invocations, and enables to makea decision
(previouslyasked) without context switching.The routines of security hooks (hooks.c and checker.c) pulls the
securitylabelof given database objects like a table, and asks the userspace AVCwhether the required accesses to be
allowed,or not.If denied, it returns an error status or raises error using ereport().
 

* SQL Extentions (3rd patch)When we create a database object, a default security label shall be givenbased on the
securitypolicy. But we can give an explicit security labelfor a new object, as far as user is allowed to create it with
thegivensecurity label.This patch provide SECURITY_LABEL = '...' option for several kinds ofCREATE or ALTER statement.
Itallows users to create database, schemas,tables, columns and procedures with a specified security label.
 

* Documentation patch (current 4th patch)It patches src/doc/sgml/*. Any descriptions corresponding to the
row-levelaccesscontrols and other upcoming features were separated.
 

* Test cases patch (current 5th patch)It provides test cases for SE-PgSQL/lite.

The SE-PgSQL/lite does NOT contain the following features, currently.

The row-level access controls provided by the 5th patch was separated from
the SE-PgSQL/lite. In addition, the writable system column support needed
by row-level controls provided by the 4th patch was also separated.
Some persons complained deployment of security hooks seem like row level
controls, such as sepgsqlHeapTupleInsert() from simple_heap_insert().
It was also separated from the SE-PgSQL/lite, and it checks permissions
outside of the simple_heap_insert(). For example, SE-PgSQL/lite put its
hook (sepgsqlCheckTableCreate()) on the DefineRelation() next to the DAC
permission checks. We can also keep completeness of the access controls
as far as security hooks checks all the routes users to create/alter/drop
tables and so on. However, it needed to apply a hardwired policy to prevent
users to modify system catalog by hand, instead of the design changes.

The advanced permission checks (in the 6th patch) were also separated
from the SE-PgSQL/lite. It includes file permission checks on COPY TO/FROM
statements, largeobjects accesses, installation of binary modules.

The functionality to reclaim orphan security labels (in the 7th patch)
was also separated.

Thanks,

-------------------------
FYI, scale of the patches

- sepgsql-01-sysatt-8.5devel-r2163.patch 34 files changed, 723 insertions(+), 69 modifications(!)
- sepgsql-02-core-8.5devel-r2163.patch 54 files changed, 4074 insertions(+), 128 modifications(!) (*) 88% of changesets
arenewlines at backend/security/sepgsql/*     or its header.
 
- sepgsql-03-gram-8.5devel-r2163.patch 25 files changed, 709 insertions(+), 87 modifications(!)
- sepgsql-04-tests-8.5devel-r2163.patch 12 files changed, 1039 insertions(+), 2 modifications(!)
- sepgsql-05-docs-8.5devel-r2163.patch 17 files changed, 1126 insertions(+), 4 modifications(!)

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>