[PATCH] SE-PgSQL/lite rev.2163 - Mailing list pgsql-hackers
From | KaiGai Kohei |
---|---|
Subject | [PATCH] SE-PgSQL/lite rev.2163 |
Date | |
Msg-id | 4A56E705.7050004@ak.jp.nec.com Whole thread Raw |
In response to | Re: [PATCH] SE-PostgreSQL Updates rev.2096 (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Responses |
Re: [PATCH] SE-PgSQL/lite rev.2163
|
List | pgsql-hackers |
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>
pgsql-hackers by date: