[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 commit fest.

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.
It enables to assign a certain security label on several kinds of database
objects. The security label in text form is stored within the new system
catalog (pg_security), and the catalog/pg_security.c provides a facility
to translate it and the security identifier.

* Core facility to communicate with in-kernel SELinux and to make its
decision on various kind of database objcets. (2nd patch)
The second patch provides the core functionality to perform with SELinux.
It deploys security hooks on the strategic points of PostgreSQL.
The hooks invoke SE-PostgreSQL routines, when it is enabled. The routines
makes its decision based on the system's security policy.
The userspace access vector cache (src/backend/security/sepgsql/avc.c)
minimizes the number of kernel space invocations, and enables to make
a decision (previously asked) without context switching.
The routines of security hooks (hooks.c and checker.c) pulls the security
label of given database objects like a table, and asks the userspace AVC
whether 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 given
based on the security policy. But we can give an explicit security label
for a new object, as far as user is allowed to create it with the given
security label.
This patch provide SECURITY_LABEL = '...' option for several kinds of
CREATE or ALTER statement. It allows 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-level
access controls 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 are newlines 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(at)ak(dot)jp(dot)nec(dot)com>