Re: Proposal of SE-PostgreSQL patches [try#2]

Hi,

The following patch set is our second proposals of SE-PostgreSQL.

It contains many of fixes and improvements from the previous version.
Please add them a reviwing queue of the next commit fest.

Thanks,

List of Patches
===============

[1/4] Core facilities of PGACE/SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r914.patch

[2/4] "--enable-selinux" option of pg_dump/pg_dumpall
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r914.patch

[3/4] Default security policy for SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r914.patch

[4/4] Documentation updates
http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r914.patch

We can provide a quick overview for SE-PostgreSQL at:
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL
http://sepgsql.googlecode.com/files/PGCON20080523.pdf

Compile and Installation
========================

The following items are requirements of SE-PostgreSQL.
- Fedora 8 or later system
- SELinux is enabled, and working
- kernel-2.6.23 or later
- selinux-policy and selinux-policy-devel v3.0.8 or later
- libselinux, policycoreutils, checkpolicy

The followings are step by step installation.

$ cvs -z3 -d :pserver:anoncvs(at)anoncvs(dot)postgresql(dot)org:/projects/cvsroot \
export -r HEAD -d pgsql
$ cd pgsql
$ patch -p1 < sepostgresql-sepgsql-8.4devel-3-r914.patch
$ patch -p1 < sepostgresql-pg_dump-8.4devel-3-r914.patch
$ patch -p1 < sepostgresql-policy-8.4devel-3-r914.patch
$ patch -p1 < sepostgresql-docs-8.4devel-3-r914.patch
$ ./configure --enable-selinux
$ make
$ make -C ./contrib/sepgsql_policy

$ su
# /usr/sbin/semodule -i ./contrib/sepgsql_policy/sepostgresql.pp ... [1]
# make install
# /sbin/restorecon -R /usr/local/pgsql

$ mkdir -p $PGDATA
$ chcon -t postgresql_db_t -R $PGDATA
$ initdb
$ pg_ctl start

[1] If "selinux-policy-3.4.2" or later is installed on your system,
install "sepostgresql-devel.pp" instead.
In this version, most of SE-PostgreSQL's policy are got mainlined.

Updates from the previous version
=================================

o A new type of "security_label" has gone

In the previous one, "security_context" system column is declared as
security_label type. This type had its input handler, and it translated
a given text representation into an internal Oid value with looking up
pg_security system catalog. If it's not found, the input handler inserts
a new entry automatically.

The following query can show the reason why this design is problematic.

SELECT 'system_u:object_r:sepgsql_db_t'::security_label;

This query seems to us read-only, but it has a possibility to insert
a new tuple into pg_security implicitly.

In this version, "security_context" system column is re-defined as a TEXT
type attribute, and a given text representation is translated into internal
identifier (Oid) just before insert or update a tuple. This design change
enables to make sure pg_security is not modified in read-only queries.

o Query modification has gone.

In the previous one, SE-PostgreSQL modified WHERE/JOIN ON clause to apply
tuple-level access controls, but its implementation is a bit complicated.
In addition, this design had a possibility to conflict with a new MS patent.

Now we put a hook on ExecScan to apply tuple-level access controls.
It enables to reduce code complexity and avoid patent conflicts.

o Scanning with SnapshotSelf has gone.

In the previous one, we had to scan some system catalogs with SnapshotSelf
mode at three points (pg_class, pg_largeobject and pg_security).

* When we defines a relation on heap_create_with_catalog(), a tuple of
pg_class and several tuples of pg_attribute are inserted within same
command id.
A tuple of pg_class has to be refered just before inserting tuples of
pg_attribute, because a new column inherits the security context of its
parent relation in the default. But we cannot find it because these are
inserted within same command id and SnapshotNow scanning mode ignores
these tuples. We cannot invoke CommandIdIncrement() here, because it
finally checks integrity of relation cache, but the relation is not
constructed yet.

We can apply two option here. One is preserving the security context
of parent table and applying it later without looking up pg_class.
The other is to insert a temporary entry into SysCache until it is
invalidated.
The later approach can also be applied on the next situation, so we
now put InsertSysCache() withing heap_create_with_catalog() to refer
the new tuple before next CommandIdIncrement() which is invoked just
after hecp_create_with_catalog().

* When a user gives a security context in text representation, it is
translated into an internal identifier which indicates the oid of
pg_security system catalog. If it was not found, PGACE/SE-PostgreSQL
inserts a new tuple and applies its oid as an internal identifier.
If a same new security context is given within same currentCommandId
twice or more, it tries to insert a new tuple into pg_security twice
or more. However, it violates uniqueness constraint at oid of pg_security.

Thus, we had to look up pg_security with SnapshotSelf scanning mode
as a fallback when SearchSysCache() returns invalid tuple. But we can
apply same approach here. So, InsertSysCache() is invoked to keep
a newly inserted security context until next CommandIdIncrement().

* When a user inserts or deletes a tuple within pg_largeobject directly,
it can also means create a new larageobject, or drop ones.
In SE-PostgreSQL model, it requires 'create' or 'drop' permission,
so we had to check whether the tuple is the first/last one, or not.

In this case, we assumes inserting a tuple into pg_largeobject directly
has a possibility to create new largeobject, and 'create' permission
should be always evaluated, not only 'write'.
This assumption kills to scan pg_largeobject for each insertion/deletion.

If requests come from lowrite() or lo_create(), we can distinguish its
meanings, so proper permissions are applied in the most cases.

I guess the InsertSysCache() will be an arguable interface, but it can resolve
our problem with minimum impact and utilizing existing facilities, so it is
better than any other solutuions.

o A new guc parameter to enable/disable SE-PostgreSQL

It can take four options, as follows:
sepostgresql = [ default | enforcing | permissive | disabled ]
- default: always follows kernel setting (default)
- enforcing: works in enforcing mode (MAC and audit enabled).
- permissive: works in permissive mode (audit log only).
- disabled: disables SE-PostgreSQL feature.

o PGACE hooks are inlined

The contains of src/backend/security/pgaceHooks.c are moved to
src/include/security/pgace.h and inlined.
It enables to reduce cost to invoke empty function when this
feature is disabled.

o Generic writable system column

SystemAttributeIsWritable() can abstract what system attribute is writable.
(Currently, the security system catalog is the only one writable.)
If it returns true on the target of INSERT, UPDATE or SELECT INTO, these
TargetEntries are marked as junk, and we can fetch its value on ExecutorRun()
separated from any other regular attribute.

o early security design

In the previous one, we stores a relationship between security id and
text representation on bootstraping mode, because pg_security system
catalog is not constructed yet in this time.
The current version holds them in-memory cache and writes out on the tail
of the bootstraping process.

o Documentation updates

The doc/src/sgml/security.sgml gives us a short description of SE-PostgreSQL
and PGACE security framework. In addition, we added source code comments for
most of functions, including PGACE hooks.

o Miscellaneous updates
* Two separated patches (pgace and sepgsql) are integrated into one.
* Copyrights are changed to "PostgreSQL Global Development Group".
* Several PGACE hooks are added, redefined and removed.
* Now, we can run regression test without any problem, except for two
tests which can be explained reasonably.
* SELinux state monitoring process is implemented using an existing
facilities provided by postmaster.c.
* Coding styles are fixed.
* A definition of LWlock is moved to storage/lwlock.h
* Definitions of SEvalItemXXXX are moved to nodes/nodes.h
* Compiler warnings come from SE-PostgreSQL are killed.
* Some error codes are added within 'SE' class, and elog()s which can
report user facing messages are replaced by ereport().
* Shell function is removed from genbki.sh.
* Default security context of files consider --prefix setting in
configure script.

Regression Tests
================

Now we remain two test fails, but these can be explained reasonably.

The first fail (create_function_1) means that SE-PostgreSQL detects
a client attempt to load an invalid file before core PostgreSQL doing,
and generates its error message.

The later one (sanity_check) means the regression test can detect
an increation of system catalogs correctly.

(*) Turn on "sepgsql_regression_test_mode" boolean of SELinux before
regression test. It enables you to load shared library modules
installed under user's home directory.

# /usr/sbin/setsebool sepgsql_regression_test_mode on

$ make check
:
(snip)
:
========================
2 of 115 tests failed.
========================

[kaigai(at)saba pgsql]$ less src/test/regress/regression.diffs
*** ./expected/create_function_1.out Fri Jun 20 14:55:12 2008
--- ./results/create_function_1.out Fri Jun 20 14:55:28 2008
***************
*** 72,78 ****
ERROR: only one AS item needed for language "sql"
CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
AS 'nosuchfile';
! ERROR: could not access file "nosuchfile": No such file or directory
CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
AS '/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so', 'nosuchsymbol';
ERROR: could not find function "nosuchsymbol" in file "/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so
"
--- 72,78 ----
ERROR: only one AS item needed for language "sql"
CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
AS 'nosuchfile';
! ERROR: SELinux: could not get context of nosuchfile
CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
AS '/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so', 'nosuchsymbol';
ERROR: could not find function "nosuchsymbol" in file "/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so
"

======================================================================

*** ./expected/sanity_check.out Sun Nov 25 12:49:12 2007
--- ./results/sanity_check.out Fri Jun 20 14:55:31 2008
***************
*** 111,116 ****
--- 111,117 ----
pg_pltemplate | t
pg_proc | t
pg_rewrite | t
+ pg_security | t
pg_shdepend | t
pg_shdescription | t
pg_statistic | t
***************
*** 149,155 ****
timetz_tbl | f
tinterval_tbl | f
varchar_tbl | f
! (138 rows)

--
-- another sanity check: every system catalog that has OIDs should have
--- 150,156 ----
timetz_tbl | f
tinterval_tbl | f
varchar_tbl | f
! (139 rows)

--
-- another sanity check: every system catalog that has OIDs should have

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Hi,

The following patch set (r926) are updated one toward the latest CVS head,
and contains some fixes in security policy and documentation.

I want to push them for the reviewing queue of CommitFest:Jul.

[1/4] Core facilities of PGACE/SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r926.patch

[2/4] "--enable-selinux" option of pg_dump/pg_dumpall
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r926.patch

[3/4] Default security policy for SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r926.patch

[4/4] Documentation updates
http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r926.patch

Thanks,

KaiGai Kohei wrote:
> Hi,
>
> The following patch set is our second proposals of SE-PostgreSQL.
>
> It contains many of fixes and improvements from the previous version.
> Please add them a reviwing queue of the next commit fest.
>
> Thanks,
>
> List of Patches
> ===============
>
> [1/4] Core facilities of PGACE/SE-PostgreSQL
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r914.patch
>
> [2/4] "--enable-selinux" option of pg_dump/pg_dumpall
> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r914.patch
>
> [3/4] Default security policy for SE-PostgreSQL
> http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r914.patch
>
> [4/4] Documentation updates
> http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r914.patch
>
> We can provide a quick overview for SE-PostgreSQL at:
> http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL
> http://sepgsql.googlecode.com/files/PGCON20080523.pdf
>
> Compile and Installation
> ========================
>
> The following items are requirements of SE-PostgreSQL.
> - Fedora 8 or later system
> - SELinux is enabled, and working
> - kernel-2.6.23 or later
> - selinux-policy and selinux-policy-devel v3.0.8 or later
> - libselinux, policycoreutils, checkpolicy
>
> The followings are step by step installation.
>
> $ cvs -z3 -d :pserver:anoncvs(at)anoncvs(dot)postgresql(dot)org:/projects/cvsroot \
> export -r HEAD -d pgsql
> $ cd pgsql
> $ patch -p1 < sepostgresql-sepgsql-8.4devel-3-r914.patch
> $ patch -p1 < sepostgresql-pg_dump-8.4devel-3-r914.patch
> $ patch -p1 < sepostgresql-policy-8.4devel-3-r914.patch
> $ patch -p1 < sepostgresql-docs-8.4devel-3-r914.patch
> $ ./configure --enable-selinux
> $ make
> $ make -C ./contrib/sepgsql_policy
>
> $ su
> # /usr/sbin/semodule -i ./contrib/sepgsql_policy/sepostgresql.pp ... [1]
> # make install
> # /sbin/restorecon -R /usr/local/pgsql
>
> $ mkdir -p $PGDATA
> $ chcon -t postgresql_db_t -R $PGDATA
> $ initdb
> $ pg_ctl start
>
> [1] If "selinux-policy-3.4.2" or later is installed on your system,
> install "sepostgresql-devel.pp" instead.
> In this version, most of SE-PostgreSQL's policy are got mainlined.
>
>
> Updates from the previous version
> =================================
>
> o A new type of "security_label" has gone
>
> In the previous one, "security_context" system column is declared as
> security_label type. This type had its input handler, and it translated
> a given text representation into an internal Oid value with looking up
> pg_security system catalog. If it's not found, the input handler inserts
> a new entry automatically.
>
> The following query can show the reason why this design is problematic.
>
> SELECT 'system_u:object_r:sepgsql_db_t'::security_label;
>
> This query seems to us read-only, but it has a possibility to insert
> a new tuple into pg_security implicitly.
>
> In this version, "security_context" system column is re-defined as a TEXT
> type attribute, and a given text representation is translated into internal
> identifier (Oid) just before insert or update a tuple. This design change
> enables to make sure pg_security is not modified in read-only queries.
>
>
> o Query modification has gone.
>
> In the previous one, SE-PostgreSQL modified WHERE/JOIN ON clause to apply
> tuple-level access controls, but its implementation is a bit complicated.
> In addition, this design had a possibility to conflict with a new MS patent.
>
> Now we put a hook on ExecScan to apply tuple-level access controls.
> It enables to reduce code complexity and avoid patent conflicts.
>
>
> o Scanning with SnapshotSelf has gone.
>
> In the previous one, we had to scan some system catalogs with SnapshotSelf
> mode at three points (pg_class, pg_largeobject and pg_security).
>
> * When we defines a relation on heap_create_with_catalog(), a tuple of
> pg_class and several tuples of pg_attribute are inserted within same
> command id.
> A tuple of pg_class has to be refered just before inserting tuples of
> pg_attribute, because a new column inherits the security context of its
> parent relation in the default. But we cannot find it because these are
> inserted within same command id and SnapshotNow scanning mode ignores
> these tuples. We cannot invoke CommandIdIncrement() here, because it
> finally checks integrity of relation cache, but the relation is not
> constructed yet.
>
> We can apply two option here. One is preserving the security context
> of parent table and applying it later without looking up pg_class.
> The other is to insert a temporary entry into SysCache until it is
> invalidated.
> The later approach can also be applied on the next situation, so we
> now put InsertSysCache() withing heap_create_with_catalog() to refer
> the new tuple before next CommandIdIncrement() which is invoked just
> after hecp_create_with_catalog().
>
> * When a user gives a security context in text representation, it is
> translated into an internal identifier which indicates the oid of
> pg_security system catalog. If it was not found, PGACE/SE-PostgreSQL
> inserts a new tuple and applies its oid as an internal identifier.
> If a same new security context is given within same currentCommandId
> twice or more, it tries to insert a new tuple into pg_security twice
> or more. However, it violates uniqueness constraint at oid of pg_security.
>
> Thus, we had to look up pg_security with SnapshotSelf scanning mode
> as a fallback when SearchSysCache() returns invalid tuple. But we can
> apply same approach here. So, InsertSysCache() is invoked to keep
> a newly inserted security context until next CommandIdIncrement().
>
> * When a user inserts or deletes a tuple within pg_largeobject directly,
> it can also means create a new larageobject, or drop ones.
> In SE-PostgreSQL model, it requires 'create' or 'drop' permission,
> so we had to check whether the tuple is the first/last one, or not.
>
> In this case, we assumes inserting a tuple into pg_largeobject directly
> has a possibility to create new largeobject, and 'create' permission
> should be always evaluated, not only 'write'.
> This assumption kills to scan pg_largeobject for each insertion/deletion.
>
> If requests come from lowrite() or lo_create(), we can distinguish its
> meanings, so proper permissions are applied in the most cases.
>
> I guess the InsertSysCache() will be an arguable interface, but it can resolve
> our problem with minimum impact and utilizing existing facilities, so it is
> better than any other solutuions.
>
>
> o A new guc parameter to enable/disable SE-PostgreSQL
>
> It can take four options, as follows:
> sepostgresql = [ default | enforcing | permissive | disabled ]
> - default: always follows kernel setting (default)
> - enforcing: works in enforcing mode (MAC and audit enabled).
> - permissive: works in permissive mode (audit log only).
> - disabled: disables SE-PostgreSQL feature.
>
>
> o PGACE hooks are inlined
>
> The contains of src/backend/security/pgaceHooks.c are moved to
> src/include/security/pgace.h and inlined.
> It enables to reduce cost to invoke empty function when this
> feature is disabled.
>
>
> o Generic writable system column
>
> SystemAttributeIsWritable() can abstract what system attribute is writable.
> (Currently, the security system catalog is the only one writable.)
> If it returns true on the target of INSERT, UPDATE or SELECT INTO, these
> TargetEntries are marked as junk, and we can fetch its value on ExecutorRun()
> separated from any other regular attribute.
>
>
> o early security design
>
> In the previous one, we stores a relationship between security id and
> text representation on bootstraping mode, because pg_security system
> catalog is not constructed yet in this time.
> The current version holds them in-memory cache and writes out on the tail
> of the bootstraping process.
>
>
> o Documentation updates
>
> The doc/src/sgml/security.sgml gives us a short description of SE-PostgreSQL
> and PGACE security framework. In addition, we added source code comments for
> most of functions, including PGACE hooks.
>
>
> o Miscellaneous updates
> * Two separated patches (pgace and sepgsql) are integrated into one.
> * Copyrights are changed to "PostgreSQL Global Development Group".
> * Several PGACE hooks are added, redefined and removed.
> * Now, we can run regression test without any problem, except for two
> tests which can be explained reasonably.
> * SELinux state monitoring process is implemented using an existing
> facilities provided by postmaster.c.
> * Coding styles are fixed.
> * A definition of LWlock is moved to storage/lwlock.h
> * Definitions of SEvalItemXXXX are moved to nodes/nodes.h
> * Compiler warnings come from SE-PostgreSQL are killed.
> * Some error codes are added within 'SE' class, and elog()s which can
> report user facing messages are replaced by ereport().
> * Shell function is removed from genbki.sh.
> * Default security context of files consider --prefix setting in
> configure script.
>
>
> Regression Tests
> ================
>
> Now we remain two test fails, but these can be explained reasonably.
>
> The first fail (create_function_1) means that SE-PostgreSQL detects
> a client attempt to load an invalid file before core PostgreSQL doing,
> and generates its error message.
>
> The later one (sanity_check) means the regression test can detect
> an increation of system catalogs correctly.
>
> (*) Turn on "sepgsql_regression_test_mode" boolean of SELinux before
> regression test. It enables you to load shared library modules
> installed under user's home directory.
>
> # /usr/sbin/setsebool sepgsql_regression_test_mode on
>
> $ make check
> :
> (snip)
> :
> ========================
> 2 of 115 tests failed.
> ========================
>
>
> [kaigai(at)saba pgsql]$ less src/test/regress/regression.diffs
> *** ./expected/create_function_1.out Fri Jun 20 14:55:12 2008
> --- ./results/create_function_1.out Fri Jun 20 14:55:28 2008
> ***************
> *** 72,78 ****
> ERROR: only one AS item needed for language "sql"
> CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
> AS 'nosuchfile';
> ! ERROR: could not access file "nosuchfile": No such file or directory
> CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
> AS '/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so', 'nosuchsymbol';
> ERROR: could not find function "nosuchsymbol" in file "/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so
> "
> --- 72,78 ----
> ERROR: only one AS item needed for language "sql"
> CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
> AS 'nosuchfile';
> ! ERROR: SELinux: could not get context of nosuchfile
> CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
> AS '/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so', 'nosuchsymbol';
> ERROR: could not find function "nosuchsymbol" in file "/home/kaigai/tmp/e/pgsql/src/test/regress/regress.so
> "
>
> ======================================================================
>
> *** ./expected/sanity_check.out Sun Nov 25 12:49:12 2007
> --- ./results/sanity_check.out Fri Jun 20 14:55:31 2008
> ***************
> *** 111,116 ****
> --- 111,117 ----
> pg_pltemplate | t
> pg_proc | t
> pg_rewrite | t
> + pg_security | t
> pg_shdepend | t
> pg_shdescription | t
> pg_statistic | t
> ***************
> *** 149,155 ****
> timetz_tbl | f
> tinterval_tbl | f
> varchar_tbl | f
> ! (138 rows)
>
> --
> -- another sanity check: every system catalog that has OIDs should have
> --- 150,156 ----
> timetz_tbl | f
> tinterval_tbl | f
> varchar_tbl | f
> ! (139 rows)
>
> --
> -- another sanity check: every system catalog that has OIDs should have
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
> The following patch set (r926) are updated one toward the latest CVS head,
> and contains some fixes in security policy and documentation.

OK, I have quickly read through these patches. They look very nice, so I am
optimistic we can get through this.

First of all, now would be a good time if someone out there really wants to
object to this feature in general. It will probably always be a niche
feature. But all the code is hidden behind ifdefs or other constructs that a
compiler can easily hide away (or we can make it so, at least).

Here is a presentation from PGCon on SE-PostgreSQL:
http://www.pgcon.org/2008/schedule/events/77.en.html

Are there any comments yet from the (Trusted)Solaris people that wanted to
evaluate this approach for compatibility with their approach?

In general, are we OK with the syntax CONTEXT = '...'? I would rather see
something like SECURITY CONTEXT '...'. There are a lot of contexts, after
all.

This will also add a system column called security_context. I think that is
OK.

In the pg_dump patch:

spelling mistake "tuen on/off"

Evil coding style: if (strcmp(SELINUX_SYSATTR_NAME, security_sysattr_name)) --
compare the result with 0 please.

The above code appears to assume that security_sysattr_name never changes, but
then why do we need a GUC parameter to show it?

Might want to change the option name --enable-selinux to something
like --security-context.

In general, we might want to not name things selinux_* but instead
sepostgresql_* or security_* or security_context_*. Or maybe PGACE?

On the default policy:

Should this really be a contrib module? Considering that it would be a core
feature that is not really usable without a policy.

Please change all the sepgsql_* things to sepostgresql_*, considering that you
are using both already, so we shouldn't have both forms of names.

Documentation:

Looks good for a start, but we will probably want to write more later.

Peter,

> Are there any comments yet from the (Trusted)Solaris people that wanted to
> evaluate this approach for compatibility with their approach?

In case they're not paying attention, a month ago the Trusted Solaris
folks said the general approach was fine, but that they would likely
want to extend SEPostgres further (that is, add to it) for 8.5.

--Josh

Thanks for your reviewing.

Peter Eisentraut wrote:
> Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
>> The following patch set (r926) are updated one toward the latest CVS head,
>> and contains some fixes in security policy and documentation.
>
> OK, I have quickly read through these patches. They look very nice, so I am
> optimistic we can get through this.
>
> First of all, now would be a good time if someone out there really wants to
> object to this feature in general. It will probably always be a niche
> feature. But all the code is hidden behind ifdefs or other constructs that a
> compiler can easily hide away (or we can make it so, at least).
>
> Here is a presentation from PGCon on SE-PostgreSQL:
> http://www.pgcon.org/2008/schedule/events/77.en.html
>
> Are there any comments yet from the (Trusted)Solaris people that wanted to
> evaluate this approach for compatibility with their approach?

In this April, I had a face-to-face meeting with Trusted Solaris people
to discuss SE-PostgreSQL and PGACE framework, and concluded that PGACE
framework provides enough facilities for both operating systems.

I modified several hooks from CommitFest:May, however, its fundamental
structures are unchanged.

> In general, are we OK with the syntax CONTEXT = '...'? I would rather see
> something like SECURITY CONTEXT '...'. There are a lot of contexts, after
> all.

If we change it, I prefer SECURITY_CONTEXT = '...' style, because it enables
to represent the left hand with a single token and make PGACE hooks simpler.
I also agree the CONTEXT has widespread meanings and to be changed here.

> This will also add a system column called security_context. I think that is
> OK.

Thanks,

> In the pg_dump patch:
>
> spelling mistake "tuen on/off"

I'll fix it soon.

> Evil coding style: if (strcmp(SELINUX_SYSATTR_NAME, security_sysattr_name)) --
> compare the result with 0 please.

OK, I'll fix it and check my implementations in other place.

> The above code appears to assume that security_sysattr_name never changes, but
> then why do we need a GUC parameter to show it?

The purpose of the GUC parameter is to identify the kind of security feature
if enabled. It can be changed by other security features, and it will show us
different value.

> Might want to change the option name --enable-selinux to something
> like --security-context.
>
> In general, we might want to not name things selinux_* but instead
> sepostgresql_* or security_* or security_context_*. Or maybe PGACE?

The pgace_* scheme is an attractive idea, although the server process
has to provide a bit more hints (like the name of security system column
and the kind of objects exported with security attribute) pg_dump to
support various kind of security features with smallest implementation.

If not so, I prefer the combination of --security-context and sepostgresql_*.

> On the default policy:
>
> Should this really be a contrib module? Considering that it would be a core
> feature that is not really usable without a policy.

It is correct, SE-PostgreSQL feature always need its security policy.
Do you think "src/backend/security/sepgsql/policy" is better?

> Please change all the sepgsql_* things to sepostgresql_*, considering that you
> are using both already, so we shouldn't have both forms of names.

We can convert them from sepostgresql_* to sepgsql_* easily, because the longer
forms are not used as a part of identifier in security context.
But we have a possible matter in changing from sepgsql_* to sepostgresql_*.

Here is a news from SELinux community:
http://marc.info/?l=selinux&m=121501336024075&w=2

It shows most part of the SE-PostgreSQL policy module got merged into
the upstreamed at selinux-policy-3.4.2 or later. It contains identifier
with sepgsql_* stuff, so it has a possible matter when users upgrade
his security policy.

If their database is labeled as sepostgresql_*, it will lose rules
defined in the policy when users upgrade selinux-policy package to
the latest one.

> Documentation:
>
> Looks good for a start, but we will probably want to write more later.

Do you think what kind of information should be added?
I intentionally omitted descriptions about SELinux itself,
because it is a documentation of PostgreSQL, not OS.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

KaiGai Kohei wrote:
>> Might want to change the option name --enable-selinux to something
>> like --security-context.
>>
>> In general, we might want to not name things selinux_* but instead
>> sepostgresql_* or security_* or security_context_*. Or maybe PGACE?
>
> The pgace_* scheme is an attractive idea, although the server process
> has to provide a bit more hints (like the name of security system column
> and the kind of objects exported with security attribute) pg_dump to
> support various kind of security features with smallest implementation.

It might not be necessary to provide all the hints pg_dump to make queries.
The minimum required information is which security feature is running on
the server process, or nothing. And, pg_dump can add a security system
column within its queries to get security attribute, if required.

Now, I'm considering to add pgaceDumpSOMETHING() functions within pg_dump
for better modularity. What do you think?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

All,

> > The pgace_* scheme is an attractive idea, although the server process
> > has to provide a bit more hints (like the name of security system column
> > and the kind of objects exported with security attribute) pg_dump to
> > support various kind of security features with smallest implementation.

If we have a choice, it should be pg_ace_*. We've told developers that they
can expect system stuff to be named pg_* ; let's stick to that whenever we
can.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

Hi,

I updated the series of patches, as follows:

[1/4] Core facilities of PGACE/SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r953.patch

[2/4] "--security-context" option of pg_dump/pg_dumpall
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r953.patch

[3/4] Default security policy for SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r953.patch

[4/4] Documentation updates
http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r953.patch

List of updates:
* "--enable-selinux" option of pg_dump/pg_dumpall are replaced
by "--security-context" option.
* A new GUC parameter of "pgace_security_feature" is added to show
what feature is worked on PGACE security framework.
* pg_ace_dumpXXXX() hooks are added to src/bin/pg_dump/pg_ace_dump.h
to abstract security attribute dumping effort.
* An extended syntax of CONTEXT = '...' is replaced by
SECURITY_CONTEXT = '...'.
* The sources of security policy module are moved from contrib/ to
src/backend/security/sepgsql/policy.
* The prefix of interfaces in the default security policy are changed
to sepgsql_*() from sepostgresql_*()
* Using integer value as a condition is replaced as follows:
if (!strcmp(..)) -> if (strcmp(...) == 0)
* Two potential bug fixes:
1. Unconditional Assert() in sepgsql_avc_reclaim().
2. relkind checks are lacked in sepgsqlSetDefaultContext().

The patch of core facilities is unchanged expect for the new GUC parameters
and above two minor bug fixes.

And I have a question. Is it legal to use a pointer value as a condition,
like `while (!pointer) ...' ?

Thanks for youe reviewing.

KaiGai Kohei wrote:
> Thanks for your reviewing.
>
> Peter Eisentraut wrote:
>> Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
>>> The following patch set (r926) are updated one toward the latest CVS
>>> head,
>>> and contains some fixes in security policy and documentation.
>>
>> OK, I have quickly read through these patches. They look very nice,
>> so I am optimistic we can get through this.
>>
>> First of all, now would be a good time if someone out there really
>> wants to object to this feature in general. It will probably always
>> be a niche feature. But all the code is hidden behind ifdefs or other
>> constructs that a compiler can easily hide away (or we can make it so,
>> at least).
>>
>> Here is a presentation from PGCon on SE-PostgreSQL:
>> http://www.pgcon.org/2008/schedule/events/77.en.html
>>
>> Are there any comments yet from the (Trusted)Solaris people that
>> wanted to evaluate this approach for compatibility with their approach?
>
> In this April, I had a face-to-face meeting with Trusted Solaris people
> to discuss SE-PostgreSQL and PGACE framework, and concluded that PGACE
> framework provides enough facilities for both operating systems.
>
> I modified several hooks from CommitFest:May, however, its fundamental
> structures are unchanged.
>
>> In general, are we OK with the syntax CONTEXT = '...'? I would rather
>> see something like SECURITY CONTEXT '...'. There are a lot of
>> contexts, after all.
>
> If we change it, I prefer SECURITY_CONTEXT = '...' style, because it
> enables
> to represent the left hand with a single token and make PGACE hooks
> simpler.
> I also agree the CONTEXT has widespread meanings and to be changed here.
>
>> This will also add a system column called security_context. I think
>> that is OK.
>
> Thanks,
>
>> In the pg_dump patch:
>>
>> spelling mistake "tuen on/off"
>
> I'll fix it soon.
>
>
>> Evil coding style: if (strcmp(SELINUX_SYSATTR_NAME,
>> security_sysattr_name)) -- compare the result with 0 please.
>
> OK, I'll fix it and check my implementations in other place.
>
>
>> The above code appears to assume that security_sysattr_name never
>> changes, but
>> then why do we need a GUC parameter to show it?
>
> The purpose of the GUC parameter is to identify the kind of security
> feature
> if enabled. It can be changed by other security features, and it will
> show us
> different value.
>
>
>> Might want to change the option name --enable-selinux to something
>> like --security-context.
>>
>> In general, we might want to not name things selinux_* but instead
>> sepostgresql_* or security_* or security_context_*. Or maybe PGACE?
>
> The pgace_* scheme is an attractive idea, although the server process
> has to provide a bit more hints (like the name of security system column
> and the kind of objects exported with security attribute) pg_dump to
> support various kind of security features with smallest implementation.
>
> If not so, I prefer the combination of --security-context and
> sepostgresql_*.
>
>
>> On the default policy:
>>
>> Should this really be a contrib module? Considering that it would be
>> a core
>> feature that is not really usable without a policy.
>
> It is correct, SE-PostgreSQL feature always need its security policy.
> Do you think "src/backend/security/sepgsql/policy" is better?
>
>
> > Please change all the sepgsql_* things to sepostgresql_*, considering
> that you
> > are using both already, so we shouldn't have both forms of names.
>
> We can convert them from sepostgresql_* to sepgsql_* easily, because the
> longer
> forms are not used as a part of identifier in security context.
> But we have a possible matter in changing from sepgsql_* to sepostgresql_*.
>
> Here is a news from SELinux community:
> http://marc.info/?l=selinux&m=121501336024075&w=2
>
> It shows most part of the SE-PostgreSQL policy module got merged into
> the upstreamed at selinux-policy-3.4.2 or later. It contains identifier
> with sepgsql_* stuff, so it has a possible matter when users upgrade
> his security policy.
>
> If their database is labeled as sepostgresql_*, it will lose rules
> defined in the policy when users upgrade selinux-policy package to
> the latest one.
>
>
>> Documentation:
>>
>> Looks good for a start, but we will probably want to write more later.
>
> Do you think what kind of information should be added?
> I intentionally omitted descriptions about SELinux itself,
> because it is a documentation of PostgreSQL, not OS.
>
> Thanks,

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

At 2008-07-11 19:10:16 +0900, kaigai(at)ak(dot)jp(dot)nec(dot)com wrote:
>
> And I have a question. Is it legal to use a pointer value as a
> condition, like `while (!pointer) ...' ?

Yes, it's fine.

-- ams

Hello,

The following patches are updated ones of SE-PostgreSQL toward the HEAD of CVS.

[1/4] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r958.patch
[2/4] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r958.patch
[3/4] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r958.patch
[4/4] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r958.patch

By the way,
http://wiki.postgresql.org/wiki/CommitFest:2008-07

| Peter says: checking with Solaris engineers about compatibility with
| Solaris TX; will continue review throughout August

Jon, do you have anything to comment about PGACE security framework?
(Show the src/include/security/pgace.h)

It has been reworked a bit from this April when we had an offline meeting,
but I think its impact is not significant for its portability.

It can provide its guest subsystem (like SE-PostgreSQL) a series of hooks to
make a decision and facilities to manage text represented security attribute
of database objects.
IIUC, we concluded these foundations are also enough to port SolarisTX feature.

If you find out something lacks/conflicts, please tell me.

Thanks,

KaiGai Kohei wrote:
> Hi,
>
> I updated the series of patches, as follows:
>
> [1/4] Core facilities of PGACE/SE-PostgreSQL
>
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r953.patch
>
>
> [2/4] "--security-context" option of pg_dump/pg_dumpall
>
> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r953.patch
>
>
> [3/4] Default security policy for SE-PostgreSQL
>
> http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r953.patch
>
>
> [4/4] Documentation updates
>
> http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r953.patch
>
> List of updates:
> * "--enable-selinux" option of pg_dump/pg_dumpall are replaced
> by "--security-context" option.
> * A new GUC parameter of "pgace_security_feature" is added to show
> what feature is worked on PGACE security framework.
> * pg_ace_dumpXXXX() hooks are added to src/bin/pg_dump/pg_ace_dump.h
> to abstract security attribute dumping effort.
> * An extended syntax of CONTEXT = '...' is replaced by
> SECURITY_CONTEXT = '...'.
> * The sources of security policy module are moved from contrib/ to
> src/backend/security/sepgsql/policy.
> * The prefix of interfaces in the default security policy are changed
> to sepgsql_*() from sepostgresql_*()
> * Using integer value as a condition is replaced as follows:
> if (!strcmp(..)) -> if (strcmp(...) == 0)
> * Two potential bug fixes:
> 1. Unconditional Assert() in sepgsql_avc_reclaim().
> 2. relkind checks are lacked in sepgsqlSetDefaultContext().
>
> The patch of core facilities is unchanged expect for the new GUC parameters
> and above two minor bug fixes.
>
> And I have a question. Is it legal to use a pointer value as a condition,
> like `while (!pointer) ...' ?
>
> Thanks for youe reviewing.
>
>
> KaiGai Kohei wrote:
>> Thanks for your reviewing.
>>
>> Peter Eisentraut wrote:
>>> Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
>>>> The following patch set (r926) are updated one toward the latest CVS
>>>> head,
>>>> and contains some fixes in security policy and documentation.
>>>
>>> OK, I have quickly read through these patches. They look very nice,
>>> so I am optimistic we can get through this.
>>>
>>> First of all, now would be a good time if someone out there really
>>> wants to object to this feature in general. It will probably always
>>> be a niche feature. But all the code is hidden behind ifdefs or
>>> other constructs that a compiler can easily hide away (or we can make
>>> it so, at least).
>>>
>>> Here is a presentation from PGCon on SE-PostgreSQL:
>>> http://www.pgcon.org/2008/schedule/events/77.en.html
>>>
>>> Are there any comments yet from the (Trusted)Solaris people that
>>> wanted to evaluate this approach for compatibility with their approach?
>>
>> In this April, I had a face-to-face meeting with Trusted Solaris people
>> to discuss SE-PostgreSQL and PGACE framework, and concluded that PGACE
>> framework provides enough facilities for both operating systems.
>>
>> I modified several hooks from CommitFest:May, however, its fundamental
>> structures are unchanged.
>>
>>> In general, are we OK with the syntax CONTEXT = '...'? I would
>>> rather see something like SECURITY CONTEXT '...'. There are a lot of
>>> contexts, after all.
>>
>> If we change it, I prefer SECURITY_CONTEXT = '...' style, because it
>> enables
>> to represent the left hand with a single token and make PGACE hooks
>> simpler.
>> I also agree the CONTEXT has widespread meanings and to be changed here.
>>
>>> This will also add a system column called security_context. I think
>>> that is OK.
>>
>> Thanks,
>>
>>> In the pg_dump patch:
>>>
>>> spelling mistake "tuen on/off"
>>
>> I'll fix it soon.
>>
>>
>>> Evil coding style: if (strcmp(SELINUX_SYSATTR_NAME,
>>> security_sysattr_name)) -- compare the result with 0 please.
>>
>> OK, I'll fix it and check my implementations in other place.
>>
>>
>>> The above code appears to assume that security_sysattr_name never
>>> changes, but
>>> then why do we need a GUC parameter to show it?
>>
>> The purpose of the GUC parameter is to identify the kind of security
>> feature
>> if enabled. It can be changed by other security features, and it will
>> show us
>> different value.
>>
>>
>>> Might want to change the option name --enable-selinux to something
>>> like --security-context.
>>>
>>> In general, we might want to not name things selinux_* but instead
>>> sepostgresql_* or security_* or security_context_*. Or maybe PGACE?
>>
>> The pgace_* scheme is an attractive idea, although the server process
>> has to provide a bit more hints (like the name of security system column
>> and the kind of objects exported with security attribute) pg_dump to
>> support various kind of security features with smallest implementation.
>>
>> If not so, I prefer the combination of --security-context and
>> sepostgresql_*.
>>
>>
>>> On the default policy:
>>>
>>> Should this really be a contrib module? Considering that it would be
>>> a core
>>> feature that is not really usable without a policy.
>>
>> It is correct, SE-PostgreSQL feature always need its security policy.
>> Do you think "src/backend/security/sepgsql/policy" is better?
>>
>>
>> > Please change all the sepgsql_* things to sepostgresql_*,
>> considering that you
>> > are using both already, so we shouldn't have both forms of names.
>>
>> We can convert them from sepostgresql_* to sepgsql_* easily, because
>> the longer
>> forms are not used as a part of identifier in security context.
>> But we have a possible matter in changing from sepgsql_* to
>> sepostgresql_*.
>>
>> Here is a news from SELinux community:
>> http://marc.info/?l=selinux&m=121501336024075&w=2
>>
>> It shows most part of the SE-PostgreSQL policy module got merged into
>> the upstreamed at selinux-policy-3.4.2 or later. It contains identifier
>> with sepgsql_* stuff, so it has a possible matter when users upgrade
>> his security policy.
>>
>> If their database is labeled as sepostgresql_*, it will lose rules
>> defined in the policy when users upgrade selinux-policy package to
>> the latest one.
>>
>>
>>> Documentation:
>>>
>>> Looks good for a start, but we will probably want to write more later.
>>
>> Do you think what kind of information should be added?
>> I intentionally omitted descriptions about SELinux itself,
>> because it is a documentation of PostgreSQL, not OS.
>>
>> Thanks,
>
>

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

On the WiKi of CommitFest:Sep,
http://wiki.postgresql.org/wiki/CommitFest:2008-09

The entry of SE-PostgreSQL points a message when I submitted older version
of our patch set. But the latest ones are listed on another message.

Please add a link to the following message for our convenience:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01365.php

BTW, I can respond to reviewer's comments and update/rework our patches
on this August, although SE-PostgreSQL is moved to the CommitFest:Sep.
We welcome any early comments, if possible.

Thanks,

KaiGai Kohei wrote:
> Hello,
>
> The following patches are updated ones of SE-PostgreSQL toward the HEAD
> of CVS.
>
> [1/4]
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r958.patch
>
> [2/4]
> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r958.patch
>
> [3/4]
> http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r958.patch
>
> [4/4]
> http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r958.patch
>
> By the way,
> http://wiki.postgresql.org/wiki/CommitFest:2008-07
>
> | Peter says: checking with Solaris engineers about compatibility with
> | Solaris TX; will continue review throughout August
>
>
> Jon, do you have anything to comment about PGACE security framework?
> (Show the src/include/security/pgace.h)
>
> It has been reworked a bit from this April when we had an offline meeting,
> but I think its impact is not significant for its portability.
>
> It can provide its guest subsystem (like SE-PostgreSQL) a series of
> hooks to
> make a decision and facilities to manage text represented security
> attribute
> of database objects.
> IIUC, we concluded these foundations are also enough to port SolarisTX
> feature.
>
> If you find out something lacks/conflicts, please tell me.
>
> Thanks,
>
>
> KaiGai Kohei wrote:
>> Hi,
>>
>> I updated the series of patches, as follows:
>>
>> [1/4] Core facilities of PGACE/SE-PostgreSQL
>>
>> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r953.patch
>>
>>
>> [2/4] "--security-context" option of pg_dump/pg_dumpall
>>
>> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r953.patch
>>
>>
>> [3/4] Default security policy for SE-PostgreSQL
>>
>> http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r953.patch
>>
>>
>> [4/4] Documentation updates
>>
>> http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r953.patch
>>
>>
>> List of updates:
>> * "--enable-selinux" option of pg_dump/pg_dumpall are replaced
>> by "--security-context" option.
>> * A new GUC parameter of "pgace_security_feature" is added to show
>> what feature is worked on PGACE security framework.
>> * pg_ace_dumpXXXX() hooks are added to src/bin/pg_dump/pg_ace_dump.h
>> to abstract security attribute dumping effort.
>> * An extended syntax of CONTEXT = '...' is replaced by
>> SECURITY_CONTEXT = '...'.
>> * The sources of security policy module are moved from contrib/ to
>> src/backend/security/sepgsql/policy.
>> * The prefix of interfaces in the default security policy are changed
>> to sepgsql_*() from sepostgresql_*()
>> * Using integer value as a condition is replaced as follows:
>> if (!strcmp(..)) -> if (strcmp(...) == 0)
>> * Two potential bug fixes:
>> 1. Unconditional Assert() in sepgsql_avc_reclaim().
>> 2. relkind checks are lacked in sepgsqlSetDefaultContext().
>>
>> The patch of core facilities is unchanged expect for the new GUC
>> parameters
>> and above two minor bug fixes.
>>
>> And I have a question. Is it legal to use a pointer value as a condition,
>> like `while (!pointer) ...' ?
>>
>> Thanks for youe reviewing.
>>
>>
>> KaiGai Kohei wrote:
>>> Thanks for your reviewing.
>>>
>>> Peter Eisentraut wrote:
>>>> Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
>>>>> The following patch set (r926) are updated one toward the latest
>>>>> CVS head,
>>>>> and contains some fixes in security policy and documentation.
>>>>
>>>> OK, I have quickly read through these patches. They look very nice,
>>>> so I am optimistic we can get through this.
>>>>
>>>> First of all, now would be a good time if someone out there really
>>>> wants to object to this feature in general. It will probably always
>>>> be a niche feature. But all the code is hidden behind ifdefs or
>>>> other constructs that a compiler can easily hide away (or we can
>>>> make it so, at least).
>>>>
>>>> Here is a presentation from PGCon on SE-PostgreSQL:
>>>> http://www.pgcon.org/2008/schedule/events/77.en.html
>>>>
>>>> Are there any comments yet from the (Trusted)Solaris people that
>>>> wanted to evaluate this approach for compatibility with their approach?
>>>
>>> In this April, I had a face-to-face meeting with Trusted Solaris people
>>> to discuss SE-PostgreSQL and PGACE framework, and concluded that PGACE
>>> framework provides enough facilities for both operating systems.
>>>
>>> I modified several hooks from CommitFest:May, however, its fundamental
>>> structures are unchanged.
>>>
>>>> In general, are we OK with the syntax CONTEXT = '...'? I would
>>>> rather see something like SECURITY CONTEXT '...'. There are a lot
>>>> of contexts, after all.
>>>
>>> If we change it, I prefer SECURITY_CONTEXT = '...' style, because it
>>> enables
>>> to represent the left hand with a single token and make PGACE hooks
>>> simpler.
>>> I also agree the CONTEXT has widespread meanings and to be changed here.
>>>
>>>> This will also add a system column called security_context. I think
>>>> that is OK.
>>>
>>> Thanks,
>>>
>>>> In the pg_dump patch:
>>>>
>>>> spelling mistake "tuen on/off"
>>>
>>> I'll fix it soon.
>>>
>>>
>>>> Evil coding style: if (strcmp(SELINUX_SYSATTR_NAME,
>>>> security_sysattr_name)) -- compare the result with 0 please.
>>>
>>> OK, I'll fix it and check my implementations in other place.
>>>
>>>
>>>> The above code appears to assume that security_sysattr_name never
>>>> changes, but
>>>> then why do we need a GUC parameter to show it?
>>>
>>> The purpose of the GUC parameter is to identify the kind of security
>>> feature
>>> if enabled. It can be changed by other security features, and it will
>>> show us
>>> different value.
>>>
>>>
>>>> Might want to change the option name --enable-selinux to something
>>>> like --security-context.
>>>>
>>>> In general, we might want to not name things selinux_* but instead
>>>> sepostgresql_* or security_* or security_context_*. Or maybe PGACE?
>>>
>>> The pgace_* scheme is an attractive idea, although the server process
>>> has to provide a bit more hints (like the name of security system column
>>> and the kind of objects exported with security attribute) pg_dump to
>>> support various kind of security features with smallest implementation.
>>>
>>> If not so, I prefer the combination of --security-context and
>>> sepostgresql_*.
>>>
>>>
>>>> On the default policy:
>>>>
>>>> Should this really be a contrib module? Considering that it would
>>>> be a core
>>>> feature that is not really usable without a policy.
>>>
>>> It is correct, SE-PostgreSQL feature always need its security policy.
>>> Do you think "src/backend/security/sepgsql/policy" is better?
>>>
>>>
>>> > Please change all the sepgsql_* things to sepostgresql_*,
>>> considering that you
>>> > are using both already, so we shouldn't have both forms of names.
>>>
>>> We can convert them from sepostgresql_* to sepgsql_* easily, because
>>> the longer
>>> forms are not used as a part of identifier in security context.
>>> But we have a possible matter in changing from sepgsql_* to
>>> sepostgresql_*.
>>>
>>> Here is a news from SELinux community:
>>> http://marc.info/?l=selinux&m=121501336024075&w=2
>>>
>>> It shows most part of the SE-PostgreSQL policy module got merged into
>>> the upstreamed at selinux-policy-3.4.2 or later. It contains identifier
>>> with sepgsql_* stuff, so it has a possible matter when users upgrade
>>> his security policy.
>>>
>>> If their database is labeled as sepostgresql_*, it will lose rules
>>> defined in the policy when users upgrade selinux-policy package to
>>> the latest one.
>>>
>>>
>>>> Documentation:
>>>>
>>>> Looks good for a start, but we will probably want to write more later.
>>>
>>> Do you think what kind of information should be added?
>>> I intentionally omitted descriptions about SELinux itself,
>>> because it is a documentation of PostgreSQL, not OS.
>>>
>>> Thanks,
>>
>>
>
>

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

KaiGai Kohei wrote:
> On the WiKi of CommitFest:Sep,
> http://wiki.postgresql.org/wiki/CommitFest:2008-09
>
> The entry of SE-PostgreSQL points a message when I submitted older version
> of our patch set. But the latest ones are listed on another message.
>
> Please add a link to the following message for our convenience:
> http://archives.postgresql.org/pgsql-hackers/2008-07/msg01365.php

Hey, given the amount of work still to go on this, don't you think you
should get a wiki account so that you can add comments yourself?

--Josh

Josh Berkus wrote:
> KaiGai Kohei wrote:
>> On the WiKi of CommitFest:Sep,
>> http://wiki.postgresql.org/wiki/CommitFest:2008-09
>>
>> The entry of SE-PostgreSQL points a message when I submitted older
>> version
>> of our patch set. But the latest ones are listed on another message.
>>
>> Please add a link to the following message for our convenience:
>> http://archives.postgresql.org/pgsql-hackers/2008-07/msg01365.php
>
> Hey, given the amount of work still to go on this, don't you think you
> should get a wiki account so that you can add comments yourself?

Thanks for updating the wiki entry.
If possible, I want to apply my wiki account for a rapid status updating.

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

The following SE-PostgreSQL patches are updated.

It contains rebasing to the lastest CVS and fixes at invocation of trusted
procedures via operators. Rest of parts are unchanged.

[1/4] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r980.patch
[2/4] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r980.patch
[3/4] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r980.patch
[4/4] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r980.patch

Please add them to the queue of CommitFest:Sep and update its wiki entry.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Hello,

The latest SE-PostgreSQL patches are updated here:

[1/4] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1005.patch
[2/4] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1005.patch
[3/4] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1005.patch
[4/4] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1005.patch

They contains rebasing to the CVS HEAD, because we cannot apply the previous ones
correctly due to progress in the base version.
Rest of changes are here:
- A new PGACE hook: pgaceIsAllowExecutorRunHook().
It enables to control overriding ExecutorRun_hook, because several important
hooks are invoked from standard_ExecutorRun().
- T_SEvalItem related equalXXXX() functions are added to nodes/equalfuncs.c.
# I've left for implement them.
- Fix typo in src/include/security/pgace.h

BTW, I thought I have to show the overview of the patch to help reviwers.
The main patch ([1/4]) is especially big and contains new concepts.

The following explanation shows several key concept of SE-PostgreSQL.
I'm happy if it can reduce the load of reviwers.

No need to say, please feel free to ask me anything. :-)

Thanks,

Security hooks
--------------
We called it as PostgreSQL Access Control Extention (PGACE).
The "src/include/security/pgace.h" newly added declares these hooks as
inline functions. If HAVE_SELINUX is available at build time, they have
a valid implementation to invoke functions to make access control decision.
When the SE-PostgreSQL feature is disabled at build time or run time,
it does not change any existing behavior.

These hooks have a prefix of "pgace", like pgaceHeapTupleInsert().
This hook is invoked just before inserting a new tuple into a relation,
and the SE-PostgreSQL subsystem can make its decision.

Its argument provides information to make a decision. The pgaceHeapTupleInsert()
has four arguments like the target Relation object and newly inserted HeapTuple.

Specifications of each hooks are described in the "src/include/security/pgace.h".

Security attribute management
-----------------------------
We need a security attribute of tuple to use it as a basic of access control
decision. SELinux calls it as "security context", and most of security aware
operating system has similar idea called as label.
It is represented as a text format like "system_u:object_r:etc_t:s0", and has
its characteristic that many objects tend to share a single security context.

We stores text represented security attribute into "pg_security" system catalog
and put an alternate key (oid of pg_security) on each tuples, because it is
unacceptable approach to put a raw string data on individual tuples.

The alternate key is stored in the tail of HeapTupleHeader, as "oid" doing.
This field is valid when t_infomask has HEAP_HASSECURITY bit.

HeapTupleHeader
+-----------------+
| : |
+-----------------+
| t_infomask |
+-----------------+ pg_security system catalog
| t_hoff o-------+ +-------+---------------------------------------------+
+-----------------+ | | oid | seclabel |
| : | | +-------+---------------------------------------------+
| : | | | 16389 | system_u:object_r:sepgsql_table_t:s0 |
+-----------------+ | | 16401 | system_u:object_r:sepgsql_proc_t:s0 |
|*Oid security_id*|---------> | 16402 | system_u:object_r:sepgsql_secret_table_t:s0 |
+-----------------+ | | : | : |
| Oid object_id | |
+-----------------+ <--+
| Data field |
| : |

The alternate key is just a internal representation, so we have to translate
it to/from text format when communicating to in-kernel SELinux, or export/import
them.

Note that the security attribute is also assigned to tuples within system
catalogs. A security attribute of a tuple within pg_attribute means column's
security attribute, and used to column-level access controls, for example.

The src/backend/security/pgaceCommon.c have functions to traslate them:

char *pgaceLookupSecurityLabel(Oid security_id);
Oid pgaceLookupSecurityId(char *security_label);

When a new security_label is given and not found on pg_security,
pgaceLookupSecurityId() tries to insert a new tuple into pg_security and
returns its object id as an alternate key.

Two more similar functions are also declared:
char *pgaceSidToSecurityLabel(Oid security_id)
Oid pgaceSecurityLabelToSid(char *security_label)
It also enables to translate between a cosmetic text format and an internal
security identifier.
An example of cosmetic format is:
unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh
^^^^^^^^^^^^^^^^^^^^
We have a case when `pg_security` system catalog is not available because
initdb does not complete to initialize system catalogs yet. In early phase,
this facility caches the pairs of identifier and text representations, then
it writes out to `pg_security` after initial set up completed.
earlySecurityLabelToSid() and earlySidToSecurityLabel() are used while we
are in bootstraping mode, and pgacePostBootstrapingMode() write out them.

Making access control decision
------------------------------
SE-PostgreSQL makes its decision with three steps in major path.

The first step picks up any database objects accessed with the given queries.
For example, the following UPDATE statement contains accesses to 6 objects.

UPDATE t SET a = 5, b = b * 2 WHERE c > 10;
- table t is updated and refered.
- column a is updated.
- column b is updated and refered.
- column c is refered without leaking its contents.
- function int4mul and int4gt are executed.

The sepgsqlProxyQuery() defined at "src/backend/security/sepgsql/proxy.c"
walks on the given Query trees to pick up database objects accessed, and
makes a list of them. This list is chained to Query->pgaceItem which is
a private field of security subsystem, and delivered to private member
of PlannedStmt structure.
In same time, it marks a kind of accesses on RangeTblEntry->pgaceTuplePerms.
This value is copied to Scan->pgaceTuplePerms, and sepgsqlExecScan() hook
refers to identify what is the purpose of this scan.

The second step is evaluations of permission for picked up database objects.
The sepgsqlVerifyQuery() is invoked at the head of ExecutorStart(), to check
whether the client has enough permission
It walk on the list chained to PlannedStmt->pgaceItem which is created at
the first step, and checks whether the client has enough permissions, or not.
If the security policy does not allow the required accesses, SE-PostgreSQL
makes an error to abort query execution.
Tuple-level access controls are not done in this step.

The last step is evaluations of permission for scanned tuples.
The sepgsqlExecScan() defined at "src/baskend/security/sepgsql/hooks.c" is
invoked from ExecScan(). This hook can return bool value, and modified
logic skips a tuple scanned if it returns 'false'.

Other topics
------------

* Default security context

The security policy also contains rules to decide a security context of
newly inserted tuples. If client does not specify any explicit one, the
default one is applied.
We can specify explicit security context with the following Enhanced SQL
statement or writable system column.

* Enhanced SQL statement

It helps to define a new table, column, function and database with specific
security context. We can use the facility as follows:

CREATE TABLE t (
a integer primary key,
b text,
) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_ro_t:s0';
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above token is represented as DefElem objects in gram.y, and saved on
private member of CreateStmt structure. Then, these are translated to List
of DefElem and delivered to heap_create_with_catalog() with its fifteenth
argument.
pgaceCreateRelationCommon() and pgaceCreateAttributeCommon() are invoked
just before inserting a new tuple into pg_class/pg_attribute. These are
defined at "src/backend/security/pgaceCommon.c", and they invokes PGACE
hooks if the security context of new objects are explicitly specified.

At the next, sepgsqlHeapTupleInsert() is invoked for the new tuple.
It skips to assign default security context, because explicit security
context is already set. Permissions to create table/column is evaluated
for explicitly specified one.

* Writable system column

Security contexts can be exported via "security_context" system column.
In the previous version, system column is read only, so we cannot specify
in an element of INSERT or UPDATE.
SE-PostgreSQL allows to set an explicit value to "security_context" system
column to utilize it as an interface to change security context of tuples.

An example)
UPDATE t SET security_context = security_context || ':c0' WHERE a = 10;

The TargetEntry->resjunk for "security_context" is always turned on for
INSERT, UPDATE and SELECT INTO statement. In the result, its new value
is computed but removed at ExecFilterJunk().
The patched ExecutePlan() fetches the value and stores it on the tail of
HeapTupleHeader with HeapTupleSetSecurity() macro.

This patch changes transformInsertStmt() and updateTargetListEntry()
to turn on TargetEntry->resjunk when attribute number is negative.
Its purpose is to enable writable system column.

Same logic can be applied to writable "oid" system column as a possibility.

* userspace Access vector cache

The "src/backend/security/sepgsql/avc.c" is an implementation of userspace
access vector cache. SE-PostgreSQL ask in-kernel SELinux to check whether
the given access should be allowed, or not.
However, it requires system call invocation which is a bit heavy step.
The userspace AVC caches recently asked access patterns, and enables to
reduce the number of system call invocation.

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Peter, Abhijit,

Could you tell me the current status of reviewing process in the CommitFest:Sep?
I can understand the patches contain several new concept and a bit large,
and it is a tough work to review them comprehensively.

I'm not unconcern anything even if reviwing comments are partial one.
However, I cannot improve anything without any comments. :(

Did the previous message which I posted help you to understand the patches?
If not, please feel free to ask me anything.

Thanks,

KaiGai Kohei wrote:
> Hello,
>
> The latest SE-PostgreSQL patches are updated here:
>
> [1/4] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1005.patch
> [2/4] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1005.patch
> [3/4] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1005.patch
> [4/4] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1005.patch
>
> They contains rebasing to the CVS HEAD, because we cannot apply the
> previous ones
> correctly due to progress in the base version.
> Rest of changes are here:
> - A new PGACE hook: pgaceIsAllowExecutorRunHook().
> It enables to control overriding ExecutorRun_hook, because several
> important
> hooks are invoked from standard_ExecutorRun().
> - T_SEvalItem related equalXXXX() functions are added to
> nodes/equalfuncs.c.
> # I've left for implement them.
> - Fix typo in src/include/security/pgace.h
>
>
> BTW, I thought I have to show the overview of the patch to help reviwers.
> The main patch ([1/4]) is especially big and contains new concepts.
>
> The following explanation shows several key concept of SE-PostgreSQL.
> I'm happy if it can reduce the load of reviwers.
>
> No need to say, please feel free to ask me anything. :-)
>
> Thanks,

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

KaiGai Kohei wrote:
> Could you tell me the current status of reviewing process in the
> CommitFest:Sep?

Well ... I have analyzed this patch several times now. The
implementation appears to be pretty straightforward, and when the time
comes, we can discuss some of the low-level details.

At this time, however, I would like to take a step or two back and
discuss with the rest of the community what we really want to achieve in
terms of enhancing "security" and access control. We need wider input
on this. The patch makes use of generic terms such as "security
enhanced" and "access control extensions" and appropriates them to this
particular implementation, and I am not really sure what direction we
want to take with this. I have also reviewed your PGCon presentation to
infer your goals behind this implementation.

At the core of it, I can see a few things that are being done here:

* System-wide consistency in access controls

The idea is, if we use some system and language to control operating
system permissions, it would be nice to use the same system and language
to control access permissions in the database system and elsewhere.

* Mandatory access control (MAC)

This defines a global security policy on top of the discretionary access
control currently in place. (Depending on how you interpret the terms
and the capabilities of SELinux, it also provides Type Enforcement and
Multilevel Security to some degree. These are related in some ways to MAC.)

* Row-level security

This defines a way to control access to rows, not only to columns.

* Additional privileges

The presented patches add ways to control permissions to alter tables,
modify large objects, and other things as well as column-level
privileges. Some of this is a moral prerequisite for a useful MAC setup.

Now these items are arguably useful and welcome features in their own
right. Unfortunately, this patch has chosen to provide these features
in a way that makes them accessible to the least amount of users. And
moreover, it bunches them all in one feature, while they should really
be available independently.

Let's review:

*) System-wide consistency in access controls could be nice to have in
some cases. But is it really achievable? In the typical three-tier web
application scenario, do you really have system-wide consistency? Can
you configure your application server using SELinux? I'm no expert on
these things, but I wonder, would it even work in a useful way, over the
network, with all the different threads, processes, and sessions going
on? Or how about a desktop, pgAdmin with several database connections,
can those be isolated from each other or whatever the security setup may be?

And is SELinux really the desirable interface for a system-wide access
control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or
port SQL roles back to the operating system, or something else that
captures what more people are actually using in practice.

*) Mandatory access control could be a useful feature for some users.
But must we resort to SELinux as the configuration language and
implementation backend? Why couldn't we implement a MAC system in SQL
using the existing language?

Also, what I read is that role-based access control (RBAC) systems are
equally capable of providing the sort of stronger security that MAC
users are typically looking for. (In some ways, it appears to be the
newer thing.) PostgreSQL already has a pretty good role system, so we
could perhaps look into enhancing that to meet the necessary functional
criteria that may exist.

*) Row-level security, column-level security and so on should in my mind
first exist as a native SQL-level feature. It would be hard to explain
that PostgreSQL does not have column-level GRANT privileges but that you
can achieve the same if you go through SELinux. After all, the
SE-PostgreSQL patch only hooks in to several places to throw "permission
denied errors" when appropriate, so native SQL features should be able
to achieve the same. (Well, there are interesting SELinux-vs-AppArmor
type differences here, that may be worth considering separately.)

Ultimately, I see this patch as an interesting proof of concept -- it
got us on the NSA site anyway -- but I can't see more than three people
actually making use of it, and they are not going to maintain this code
for us in the long run. On the other hand, it provides useful features,
but with what I consider suboptimal interfaces. Considering that
SELinux configurations on Red Hat are now just slowly evolving from
annoying to usable after many years of work, I can't see us mustering
the resources to achieve a usable configuration of this in a reasonable
time, let alone the resources required to verify the whole thing so that
is actually provides some assurances rather than just another way to
fiddle about with the system.

The way I see this, the approach to be taken to achieve some kind of
government-grade security system would be:

1. Implement row-level security, column-level privileges, and all other
necessary permission bits as SQL features.

2. Enhance the role system to meet whatever the evaluation criteria may be.

3a. Add access control extension hooks.

3b. Implement SELinux on top of these hooks.

You have already done 3a and 3b, but I think 1 and 2 should be done first.

On Wed, 17 Sep 2008, Peter Eisentraut wrote:

> System-wide consistency in access controls could be nice to have in some
> cases. But is it really achievable? In the typical three-tier web
> application scenario, do you really have system-wide consistency? Can
> you configure your application server using SELinux?

Each of the tiers end up with mapping layer similar to the one implemented
here to map the SELinux permissions -> PostgreSQL. Java for example has a
whole JVM security manager component that makes it straighforward to do
such a mapping.
http://articles.techrepublic.com.com/5100-10878_11-6178805.html is a good
quick intro that shows how the call structure is similar to what the
SE-PostgreSQL code does.

> And is SELinux really the desirable interface for a system-wide access
> control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or port
> SQL roles back to the operating system, or something else that captures what
> more people are actually using in practice.

The main feature of SELinux that this crowd likes is how it manages
privledge escalation risk. I'm not sure if POSIX ACLs for example are as
effective at limiting the damage an exploitable suid binary can cause.
As for what people are actually using, as someone who lives near the US
capital I can tell you that installs using SELinux are quite plentiful
around here--there really is no other UNIX-based technology for this
purpose that's gotten traction inside this government like SELinux has.

Anyway, even though I think picking SELinux as the primary security
mechanism to integrate with is a sensible choice and I'm confident that
the rest of the software stack isn't a problem, I do share your concern
that implementing row and column-level security would make more sense in a
general way first.

> Ultimately, I see this patch as an interesting proof of concept -- it got us
> on the NSA site anyway -- but I can't see more than three people actually
> making use of it

I take it you've never seen how big the NSA fort^H^H^H^Hfacility is? I'm
not sure exactly how many orders of magnitude your estimate is off by, but
I know it's at least 2 just based on conversations I've been involved in
with companies around here. A lot of the US defense and homeland security
related companies are adopting open-source software stacks because they
can audit every level of the software, and there's a big void in that
stack waiting for a database with the right security model to fill. You
are right that getting code contributions back again is a challenge
though.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Peter, thanks for your comments.

> Let's review:
>
> *) System-wide consistency in access controls could be nice to have in
> some cases. But is it really achievable? In the typical three-tier web
> application scenario, do you really have system-wide consistency? Can
> you configure your application server using SELinux? I'm no expert on
> these things, but I wonder, would it even work in a useful way, over the
> network, with all the different threads, processes, and sessions going
> on? Or how about a desktop, pgAdmin with several database connections,
> can those be isolated from each other or whatever the security setup may
> be?

It's a good question. Yes, it is possible no need to say. :)

We can configure Apache to kick its contents handler with a proper security
context. The contents handler is a sort of Apache module to handle various
kind of web contents like *.html, *.php, *.cgi and so on.
The existing module (mod_selinux) eanbles to invoke CGI program with a proper
security context based on HTTP authentication. In addition, the upcoming
Linux kernel got a feature to assign built-in scripts its security context.

SELinux applied its access controls based on the assigned security context
for various kind of objects like files, sockets, IPCs, tables, columns and
so on.

I can provide a demonstration, pelase wait for a while to set up.

- For overing networks,
The current SELinux provides the Labeled Networking feature. It enables to
deliver a peer's security context to other peer side. We can fetch delivered
one with getpeercon() API. SE-PostgreSQL also uses this API to obtain the
security context of client process.
(*) Note that SE-PostgreSQL does not depend on Database authentication.

- For different threads,
The upcoming Linux kernel got a feature to assign individual security context
for a thread with a constraint to prevent information boundary violation.
http://marc.info/?l=selinux&m=121992782231903

- For sessions,
We can set a proper security context using session variable before invoking
web applications, in same way as I noted above.
However, I've not provide an implementation yet.

> And is SELinux really the desirable interface for a system-wide access
> control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or
> port SQL roles back to the operating system, or something else that
> captures what more people are actually using in practice.

Yes, SELinux is one of the suitable facilities.

It enables to describe its security policy using abstracted attributes
called as "security context", independent from a sort of subsystems.
For example, the POSIX ACL is an accomplished access control stuff, but
it is specific for filesystem. We have no way to apply it on network
access controls.

In addition, it enables to reduce privilege escalation risk as Greg Smith
mentioned.

> *) Mandatory access control could be a useful feature for some users.
> But must we resort to SELinux as the configuration language and
> implementation backend? Why couldn't we implement a MAC system in SQL
> using the existing language?
>
> Also, what I read is that role-based access control (RBAC) systems are
> equally capable of providing the sort of stronger security that MAC
> users are typically looking for. (In some ways, it appears to be the
> newer thing.) PostgreSQL already has a pretty good role system, so we
> could perhaps look into enhancing that to meet the necessary functional
> criteria that may exist.

I want you to understand the proposd design *NEVER* denies mandatory access
controls based on other security engine. The PGACE hooks enables to swap
the access control subsystem by the configure option.

I also agree that PostgreSQL already has a pretty good role and access
control mechanism. However, it is hard to describe mandatory access control
policy in common forms between OS and RDBMS.

I don't think dual-checks are matter. The operating system applies its DAC
policy known as filesystem permission and MAC policy provided by SELinux
(or other facilities).

> *) Row-level security, column-level security and so on should in my mind
> first exist as a native SQL-level feature. It would be hard to explain
> that PostgreSQL does not have column-level GRANT privileges but that you
> can achieve the same if you go through SELinux. After all, the
> SE-PostgreSQL patch only hooks in to several places to throw "permission
> denied errors" when appropriate, so native SQL features should be able
> to achieve the same. (Well, there are interesting SELinux-vs-AppArmor
> type differences here, that may be worth considering separately.)

I cannot understand the reason why these native/newer access control
facilities should have same access control guranualities.
These are provided by different subsystems, so they have different
guranualities and results. What is the matter?

The relationship of them is designed by reference to DAC and MAC on operating
system. As I noted above, it checks user's request twice based on different
security policy.

In addition, SELinux defines 20 kind of permissions for regular files,
being finer than filesystem permissions. It is not a curious behavior.

> The way I see this, the approach to be taken to achieve some kind of
> government-grade security system would be:
>
> 1. Implement row-level security, column-level privileges, and all other
> necessary permission bits as SQL features.
>
> 2. Enhance the role system to meet whatever the evaluation criteria may be.
>
> 3a. Add access control extension hooks.
>
> 3b. Implement SELinux on top of these hooks.
>
> You have already done 3a and 3b, but I think 1 and 2 should be done first.

It seems to me there is no dependencies.
We can make progress them in parallel.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Greg Smith wrote:
> On Wed, 17 Sep 2008, Peter Eisentraut wrote:
>
>> System-wide consistency in access controls could be nice to have in
>> some cases. But is it really achievable? In the typical three-tier
>> web application scenario, do you really have system-wide consistency?
>> Can you configure your application server using SELinux?
>
> Each of the tiers end up with mapping layer similar to the one
> implemented here to map the SELinux permissions -> PostgreSQL. Java for
> example has a whole JVM security manager component that makes it
> straighforward to do such a mapping.
> http://articles.techrepublic.com.com/5100-10878_11-6178805.html is a
> good quick intro that shows how the call structure is similar to what
> the SE-PostgreSQL code does.

I guess these security architectures have same origin.

The reference monitor concept requres all accesses to data objects to be
checked by a tamperproof, always-invoked module based on its policy.
http://en.wikipedia.org/wiki/Reference_monitor

SE-PostgreSQL uses in-kernel SELinux as a reference monitor to check
all accesses to database object via SQL.

>> And is SELinux really the desirable interface for a system-wide access
>> control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or
>> port SQL roles back to the operating system, or something else that
>> captures what more people are actually using in practice.
>
> The main feature of SELinux that this crowd likes is how it manages
> privledge escalation risk. I'm not sure if POSIX ACLs for example are
> as effective at limiting the damage an exploitable suid binary can
> cause. As for what people are actually using, as someone who lives near
> the US capital I can tell you that installs using SELinux are quite
> plentiful around here--there really is no other UNIX-based technology
> for this purpose that's gotten traction inside this government like
> SELinux has.
>
> Anyway, even though I think picking SELinux as the primary security
> mechanism to integrate with is a sensible choice and I'm confident that
> the rest of the software stack isn't a problem, I do share your concern
> that implementing row and column-level security would make more sense in
> a general way first.

Thanks for your explanation.

The PGACE security framework can mount a OS independent fine
grained access control feature, like Oracle Label Security.
However, one concern is we have only one CommitFest remained.

As I mentioned at the previous message, I think it is not
a strange behavior that different security subsystems make
different decisions on individual gulanualities.

>> Ultimately, I see this patch as an interesting proof of concept -- it
>> got us on the NSA site anyway -- but I can't see more than three
>> people actually making use of it
>
> I take it you've never seen how big the NSA fort^H^H^H^Hfacility is?
> I'm not sure exactly how many orders of magnitude your estimate is off
> by, but I know it's at least 2 just based on conversations I've been
> involved in with companies around here. A lot of the US defense and
> homeland security related companies are adopting open-source software
> stacks because they can audit every level of the software, and there's a
> big void in that stack waiting for a database with the right security
> model to fill. You are right that getting code contributions back again
> is a challenge though.

I don't have statistically reliable information. :)
However, I believe there is potentially strong demand for secure database
due to responses from audiences when I had presentations about SE-PostgreSQL
in various opportunities.

IIRC, Josh also said similar things.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

KaiGai Kohei wrote:
> Peter, thanks for your comments.
>
> > Let's review:
> >
> > *) System-wide consistency in access controls could be nice to have in
> > some cases. But is it really achievable? In the typical three-tier web
> > application scenario, do you really have system-wide consistency? Can
> > you configure your application server using SELinux? I'm no expert on
> > these things, but I wonder, would it even work in a useful way, over the
> > network, with all the different threads, processes, and sessions going
> > on? Or how about a desktop, pgAdmin with several database connections,
> > can those be isolated from each other or whatever the security setup may
> > be?
>
> It's a good question. Yes, it is possible no need to say. :)
>
> We can configure Apache to kick its contents handler with a proper security
> context. The contents handler is a sort of Apache module to handle various
> kind of web contents like *.html, *.php, *.cgi and so on.
> The existing module (mod_selinux) eanbles to invoke CGI program with a
> proper
> security context based on HTTP authentication. In addition, the upcoming
> Linux kernel got a feature to assign built-in scripts its security context.
>
> SELinux applied its access controls based on the assigned security context
> for various kind of objects like files, sockets, IPCs, tables, columns and
> so on.
>
> I can provide a demonstration, pelase wait for a while to set up.

The following URL can show the demonstration:
http://kaigai.myhome.cx/index.php

It requires HTTP authentication, and you can choose one of "foo", "var" or "baz".
They can be authenticated by same password: "sepgsql".

The web server assigns per-user security context for its contents handler
including the PHP script. It shows the result set of SQL query depends on
the security context of its client.

(note) This script always connects to SE-PostgreSQL server with "apache" role
that has a privileged user rights.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

At the CommitFest:Sep, I got several comments about SE-PostgreSQL from Peter.
(Thanks for your comments.)
He asked me several questions about its concept, then I replied for them.
However, it seems to me there is a difference in our opinions.

In my opinion, it is quite natural that different security mechanisms can
have differences in its decision making, its gulanuality and its scope.
But he concerned that SE-PostgreSQL provides fine-grained access control
feature, though the native PostgreSQL does not provide it yet.

> *) Row-level security, column-level security and so on should in my mind
> first exist as a native SQL-level feature. It would be hard to explain
> that PostgreSQL does not have column-level GRANT privileges but that you
> can achieve the same if you go through SELinux.

I don't know his current opinion.
But I think it is not worthful to stop making a progress due to
differences in opinions. So, I think there are the following three
options to solve the issue.

[1] Make a consensus that different security mechanisms have differences
in its decision making, its gulanuality and its scope

I think it is the most straightforward answer.
As operating system doing, DAC and MAC based access controls should be
independently applied on accesses from users, and this model is widely
accepted.
These facilities can also have different results, gulanualities and scopes.

[2] Make a new implementation of OS-independent fine grained access control

If it is really really necessary, I may try to implement a new separated
fine-grained access control mechanism due to the CommitFest:Nov.
However, we don't have enough days to develop one more new feature from
the scratch by the deadline.

[3] Restrict functionalities of SE-PostgreSQL

It is the most laughable idea.
If SE-PostgreSQL lose its fine-grained access control feature, both of
access control features have same gulanualities at least.
But it makes unmotivate me so much. I believe no one agree this option.

I want any comments on this topic.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

> [2] Make a new implementation of OS-independent fine grained access control
>
> If it is really really necessary, I may try to implement a new separated
> fine-grained access control mechanism due to the CommitFest:Nov.
> However, we don't have enough days to develop one more new feature from
> the scratch by the deadline.

+1.

...Robert

Robert Haas wrote:
>> [2] Make a new implementation of OS-independent fine grained access control
>>
>> If it is really really necessary, I may try to implement a new separated
>> fine-grained access control mechanism due to the CommitFest:Nov.
>> However, we don't have enough days to develop one more new feature from
>> the scratch by the deadline.
>
> +1.
>
> ...Robert

It's too early to vote. :-)

The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
have to have same granuality in access controls.

As I mentioned before, it is quite natural that different security
mechanism provides its access controls in different granuality,
as widely accepted in Linux.

The reason is now unclear for me.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

> It's too early to vote. :-)
>
> The second and third option have prerequisite.
> The purpose of them is to match granularity of access controls
> provided by SE-PostgreSQL and native PostgreSQL. However, I have
> not seen a clear reason why these different security mechanisms
> have to have same granuality in access controls.

Have you seen a clear reason why they should NOT have the same granularity?

I realize that SELinux has become quite popular and that a lot of
people use it - but certainly not everyone. There might be some parts
of the functionality that are not really severable, and if that is the
case, fine. But I think there should be some consideration of which
parts can be usefully exposed via SQL and which can't. If the parts
that can be are independently useful, then I think they should be
available, but ultimately that's a judgment call and people may come
to different conclusions.

...Robert

On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:

>> It's too early to vote. :-)
>>
>> The second and third option have prerequisite.
>> The purpose of them is to match granularity of access controls
>> provided by SE-PostgreSQL and native PostgreSQL. However, I have
>> not seen a clear reason why these different security mechanisms
>> have to have same granuality in access controls.
>
> Have you seen a clear reason why they should NOT have the same
> granularity?
>
> I realize that SELinux has become quite popular and that a lot of
> people use it - but certainly not everyone. There might be some parts
> of the functionality that are not really severable, and if that is the
> case, fine. But I think there should be some consideration of which
> parts can be usefully exposed via SQL and which can't. If the parts
> that can be are independently useful, then I think they should be
> available, but ultimately that's a judgment call and people may come
> to different conclusions.

If the SE-PostgreSQL effort simply implemented SQL interfaces to
increase security granularity, it wouldn't be SE-PostgreSQL at all. SE-
PostgreSQL integrates with a set of optional system-wide access
controls and is only marginally related to SQL-level database
features. Since it relies on an optional component, it doesn't really
make sense that anyone is surprised that the patch doesn't improve
security granularity of vanilla PostgreSQL.

Cheers,
M

Robert Haas wrote:
>> It's too early to vote. :-)
>>
>> The second and third option have prerequisite.
>> The purpose of them is to match granularity of access controls
>> provided by SE-PostgreSQL and native PostgreSQL. However, I have
>> not seen a clear reason why these different security mechanisms
>> have to have same granuality in access controls.
>
> Have you seen a clear reason why they should NOT have the same granularity?

I don't deny two different security mechanisms have same granuality.
It is a choice by its architect, and it can have same or different
guranuality.

> I realize that SELinux has become quite popular and that a lot of
> people use it - but certainly not everyone. There might be some parts
> of the functionality that are not really severable, and if that is the
> case, fine. But I think there should be some consideration of which
> parts can be usefully exposed via SQL and which can't. If the parts
> that can be are independently useful, then I think they should be
> available, but ultimately that's a judgment call and people may come
> to different conclusions.

Yes, I also agree your opinion.

SE-PostgreSQL is designed to achieve several targets in same time:
- Collaboration with operating system
- Mandatoty access control
- Fine-grained access control

If someone want the last feature only, SE-PostgreSQL provides too much
for him. However, it is designed to replace security mechanism easily.

Have you heared the PGACE security framework?
It is designed by reference to LSM, and provides several hooks to invoke
security mechanism. It checks whether the given query is legal, or not.

In my second option, I will try to implement similar functionality which
provides "fine-grained-only" on PGACE security framework.
However, every security mechanism has horizontal relationship, not a hierarchy,
not a dependency. So, we can make progress in parallel.
(And, they can have individual guranuality and so on.)
Therefore, I think that nonexistence of "fine-grained-only" mechanism should
not block other mechanism to join development cycle.

If it is really really necessary, I try to pay effort to implement the 2nd
option due to the CommitFest:Nov.
But, in my ideal, I want to concentrate to merge SE-PostgreSQL during v8.4
development cycle.

And, I understood there are folks who want only "fine-grained-only" one.
If possible, I want to design and implement it for v8.5 development cycle
with enough days.
Unfortunatelly, remained days are a bit short...

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

A.M. wrote:
>
> On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
>
>>> It's too early to vote. :-)
>>>
>>> The second and third option have prerequisite.
>>> The purpose of them is to match granularity of access controls
>>> provided by SE-PostgreSQL and native PostgreSQL. However, I have
>>> not seen a clear reason why these different security mechanisms
>>> have to have same granuality in access controls.
>>
>> Have you seen a clear reason why they should NOT have the same
>> granularity?
>>
>> I realize that SELinux has become quite popular and that a lot of
>> people use it - but certainly not everyone. There might be some parts
>> of the functionality that are not really severable, and if that is the
>> case, fine. But I think there should be some consideration of which
>> parts can be usefully exposed via SQL and which can't. If the parts
>> that can be are independently useful, then I think they should be
>> available, but ultimately that's a judgment call and people may come
>> to different conclusions.
>
> If the SE-PostgreSQL effort simply implemented SQL interfaces to
> increase security granularity, it wouldn't be SE-PostgreSQL at all.
> SE-PostgreSQL integrates with a set of optional system-wide access
> controls and is only marginally related to SQL-level database features.
> Since it relies on an optional component, it doesn't really make sense
> that anyone is surprised that the patch doesn't improve security
> granularity of vanilla PostgreSQL.

I understand what you say is the part of decision making should be
pluggable and like a "fine-grained-only" mode should be selectable.
(I'm sorry, if my understanding is incorrect.)

I thought this approach prevents to support various kind of "enhanced"
security mechanism on PGACE security framework.
Do you know SE-PostgreSQL is designed to use common set of security hooks
named as PGACE? It provides bare hooks and minimum facilities to handle
security attribute. The reason why it does not define internal structure
of security mechanism is to avoid to assume specific mechanism.

My preference is to switch whole of security mechanism by configuration
option as SE-PostgreSQL or LSM doing.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

> [1] Make a consensus that different security mechanisms have differences
> in its decision making, its gulanuality and its scope
>
> I think it is the most straightforward answer.
> As operating system doing, DAC and MAC based access controls should be
> independently applied on accesses from users, and this model is widely
> accepted.
> These facilities can also have different results, gulanualities and scopes.
>
>
> [2] Make a new implementation of OS-independent fine grained access control
>
> If it is really really necessary, I may try to implement a new separated
> fine-grained access control mechanism due to the CommitFest:Nov.
> However, we don't have enough days to develop one more new feature from
> the scratch by the deadline.

I reconsidered the above two options have no differences fundamentally.

In other word, making a new enhanced security implementation based on
requirements also means making a consensus various security mechanism
can have its individual rules including guranuality of access controls.

So, I'll decide to try to implement "fine-grained-only" security
mechanism also, because someone have such a requirememt.
However, its schedule is extremely severe, if is has to be submitted
due to the deadline of CommitFest:Nov.

It is my hope to concentrate development of SE-PostgreSQL in v8.4
development cycle, and I think the above "fine-grained-only" one
should be pushed to v8.5 cycle.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Robert Haas wrote:
> > It's too early to vote. :-)
> >
> > The second and third option have prerequisite.
> > The purpose of them is to match granularity of access controls
> > provided by SE-PostgreSQL and native PostgreSQL. However, I have
> > not seen a clear reason why these different security mechanisms
> > have to have same granuality in access controls.
>
> Have you seen a clear reason why they should NOT have the same granularity?

Agreed. If we implement SE-PostgreSQL row-level security first, we
might find that we have to replace the code once we implement SQL-level
row-level security. If we do SQL-level security first, we can then
adjust it to match what SE-PostgreSQL needs.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

KaiGai Kohei wrote:
> > [1] Make a consensus that different security mechanisms have differences
> > in its decision making, its gulanuality and its scope
> >
> > I think it is the most straightforward answer.
> > As operating system doing, DAC and MAC based access controls should be
> > independently applied on accesses from users, and this model is widely
> > accepted.
> > These facilities can also have different results, gulanualities and scopes.
> >
> >
> > [2] Make a new implementation of OS-independent fine grained access control
> >
> > If it is really really necessary, I may try to implement a new separated
> > fine-grained access control mechanism due to the CommitFest:Nov.
> > However, we don't have enough days to develop one more new feature from
> > the scratch by the deadline.
>
> I reconsidered the above two options have no differences fundamentally.
>
> In other word, making a new enhanced security implementation based on
> requirements also means making a consensus various security mechanism
> can have its individual rules including guranuality of access controls.
>
> So, I'll decide to try to implement "fine-grained-only" security
> mechanism also, because someone have such a requirememt.
> However, its schedule is extremely severe, if is has to be submitted
> due to the deadline of CommitFest:Nov.
>
> It is my hope to concentrate development of SE-PostgreSQL in v8.4
> development cycle, and I think the above "fine-grained-only" one
> should be pushed to v8.5 cycle.

Well, those might be your priorities, but I don't think they are the
community's priorities.

I think the community's priorities are to add security at the SQL
level, and then we can see clearly what SE-PostgreSQL requires. This
has been discussed before so it should not come as a surprise.

What you can do is to do things in this order:

1) Add SE-PostgreSQL capabilities that layer over existing Postgres
SQL-level permissions
2) Implement "fine-grained" permissions at the SQL level
3) Add SE-PostgreSQL capabilities for "fine-grained" permissions

Perhaps you can only get #1 done for 8.4; I don't know, but I knew
months ago that #2 had to be done before #3, and I think that was
communicated.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce,

> I think the community's priorities are to add security at the SQL
> level, and then we can see clearly what SE-PostgreSQL requires. This
> has been discussed before so it should not come as a surprise.

Well, I'm not that clear on exactly the SE implementation, but I spent a
fair amount of time with Trusted Solaris and I can tell you that a
multilevel security implementation would work in a different way from SQL
row-level permissions.

Multilevel frameworks have concepts of data hiding and data substitution
based on labels. That is, if a user doesn't have permissions on data,
he's not merely supposed to be denied access to it, he's not even supposed
to know that the data exists. In extreme cases (think military / CIA use)
data at a lower security level should be substitited for the higher
security level data which the user isn't allowed. Silently.

So it's quite possible that the SE and/or multilevel framework could remain
parallel-but-different from SQL-level permissions, which would not include
data hiding or data substitution.

--
--Josh

Josh Berkus
PostgreSQL
San Francisco

Josh Berkus wrote:
> Bruce,
>
> > I think the community's priorities are to add security at the SQL
> > level, and then we can see clearly what SE-PostgreSQL requires. This
> > has been discussed before so it should not come as a surprise.
>
> Well, I'm not that clear on exactly the SE implementation, but I spent a
> fair amount of time with Trusted Solaris and I can tell you that a
> multilevel security implementation would work in a different way from SQL
> row-level permissions.
>
> Multilevel frameworks have concepts of data hiding and data substitution
> based on labels. That is, if a user doesn't have permissions on data,
> he's not merely supposed to be denied access to it, he's not even supposed
> to know that the data exists. In extreme cases (think military / CIA use)
> data at a lower security level should be substitited for the higher
> security level data which the user isn't allowed. Silently.
>
> So it's quite possible that the SE and/or multilevel framework could remain
> parallel-but-different from SQL-level permissions, which would not include
> data hiding or data substitution.

True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

> True, but think we would like to have all the SQL-level stuff done
> first, or at least decide we don't want it at the SQL level, before
> moving forward with adding fine-grained controls.

This makes no sense. We've been sitting for years on the per-row
privilege stuff, and there haven't been many takers. It doesn't look
like somebody is going to write it for 8.4, which means delaying the
inclusion of SE-Pgsql stuff just because that other thing is not done
does not favor anyone.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > True, but think we would like to have all the SQL-level stuff done
> > first, or at least decide we don't want it at the SQL level, before
> > moving forward with adding fine-grained controls.
>
> This makes no sense. We've been sitting for years on the per-row
> privilege stuff, and there haven't been many takers. It doesn't look
> like somebody is going to write it for 8.4, which means delaying the
> inclusion of SE-Pgsql stuff just because that other thing is not done
> does not favor anyone.

Well, does it make sense to add column-level privileges just for
SE-Linux? I don't think that is wise. My logic is to build the lower
levels first (SQL), then the higher levels. If that was done when the
issue was originally suggested months ago it would be done but now. I
don't see the rush to do things backwards just to get SE-Linux
capability in 8.4, but of course that is just my opinion.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>>
>>> True, but think we would like to have all the SQL-level stuff done
>>> first, or at least decide we don't want it at the SQL level, before
>>> moving forward with adding fine-grained controls.
>> This makes no sense. We've been sitting for years on the per-row
>> privilege stuff, and there haven't been many takers. It doesn't look
>> like somebody is going to write it for 8.4, which means delaying the
>> inclusion of SE-Pgsql stuff just because that other thing is not done
>> does not favor anyone.
>
> Well, does it make sense to add column-level privileges just for
> SE-Linux? I don't think that is wise. My logic is to build the lower
> levels first (SQL), then the higher levels. If that was done when the
> issue was originally suggested months ago it would be done but now. I
> don't see the rush to do things backwards just to get SE-Linux
> capability in 8.4, but of course that is just my opinion.

As I mentioned before, it is quite natural that different security
mechanism *can* have different granualities, different decisions and
so on.
(No need to say, it *never* prevent they have same ones.)

However, I can follow the direction of the community.
If it is necessary to get merged SE-PostgreSQL feature in v8.4 cycle,
I'll begin to design and implement the fine-grained-only feature sooon.

In my hope, could you make progress reviewing SE-PostgreSQL feature
during last half of the September and the October? It is necessary
for load balancing of folks.

Anyway, we have just only 35 days. If possible, I wanted to get
such a funfamental suggestion more ealier. :(

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > True, but think we would like to have all the SQL-level stuff done
> > > first, or at least decide we don't want it at the SQL level, before
> > > moving forward with adding fine-grained controls.
> >
> > This makes no sense. We've been sitting for years on the per-row
> > privilege stuff, and there haven't been many takers. It doesn't look
> > like somebody is going to write it for 8.4, which means delaying the
> > inclusion of SE-Pgsql stuff just because that other thing is not done
> > does not favor anyone.
>
> Well, does it make sense to add column-level privileges just for
> SE-Linux?

That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?

I think the answer is yes, because (as others have said) if we ever want
to have SQL-level per-row permissions, then we can implement them with
no change to the patch currently in discussion.

(Note that it has been said that this abstraction layer could easily be
"ported" to work on TrustedSolaris, and probably other OS-level security
mechs)

> I don't think that is wise. My logic is to build the lower levels
> first (SQL), then the higher levels.

Why are you saying that SQL is the lower level? I don't think there's a
"lower" and "upper" layer here. Neither can be built on top of the
other one, because they are orthogonal.

> If that was done when the issue was originally suggested months ago it
> would be done but now. I don't see the rush to do things backwards
> just to get SE-Linux capability in 8.4, but of course that is just my
> opinion.

:-) My opinion here is that doing it is not backwards.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Multilevel frameworks have concepts of data hiding and data substitution
> based on labels. That is, if a user doesn't have permissions on data,
> he's not merely supposed to be denied access to it, he's not even supposed
> to know that the data exists. In extreme cases (think military / CIA use)
> data at a lower security level should be substitited for the higher
> security level data which the user isn't allowed. Silently.

Yeah, that's what I keep hearing that the spooks think they want.
I can't imagine how it would play nice with SQL-standard integrity
constraints. Data that apparently violates a foreign-key constraint,
for example, would give someone a pretty good clue that there's
something there he's not being allowed to see.

regards, tom lane

>> Well, does it make sense to add column-level privileges just for
>> SE-Linux?
>
> That's the wrong question. The question here is: does it make sense to
> have per-row permissions implemented on top of an abstraction layer
> whose sole current implementation is SE-Linux?

Er, Bruce was asking about per-column, not per-row.

There's a patch listed on CommitFest:2008-09 to introduce per-column
permissions, but it's apparently still WIP. How much does that
overlap/conflict with these patches?

> I think the answer is yes, because (as others have said) if we ever want
> to have SQL-level per-row permissions, then we can implement them with
> no change to the patch currently in discussion.

If that's true, it weighs somewhat in favor of accepting this patch,
but how sure are we that it's really the case? If you only have one
implementation sitting on top of your abstraction layer, it's hard to
know whether you've implemented a general framework for doing X or
merely an interface that happens to suit the particular flavor of X
that you want to do today.

...Robert

Robert Haas wrote:
> > I think the answer is yes, because (as others have said) if we ever want
> > to have SQL-level per-row permissions, then we can implement them with
> > no change to the patch currently in discussion.
>
> If that's true, it weighs somewhat in favor of accepting this patch,
> but how sure are we that it's really the case? If you only have one
> implementation sitting on top of your abstraction layer, it's hard to
> know whether you've implemented a general framework for doing X or
> merely an interface that happens to suit the particular flavor of X
> that you want to do today.

Yes, that is my point, and SE-Linux is just Linux, meaning it is
OS-specific, making it even less generally useful.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Multilevel frameworks have concepts of data hiding and data substitution
>> based on labels. That is, if a user doesn't have permissions on data,
>> he's not merely supposed to be denied access to it, he's not even supposed
>> to know that the data exists. In extreme cases (think military / CIA use)
>> data at a lower security level should be substitited for the higher
>> security level data which the user isn't allowed. Silently.
>
> Yeah, that's what I keep hearing that the spooks think they want.
> I can't imagine how it would play nice with SQL-standard integrity
> constraints. Data that apparently violates a foreign-key constraint,
> for example, would give someone a pretty good clue that there's
> something there he's not being allowed to see.

Please note that SE-PostgreSQL does not adopt following technology
because of its complexity. When user tries to update a PK refered by
invisible FK, it generate an error. Thus, it is theoretically possible
to estimate the invisible PKs by attacks with repeating.

In extream case, a technology called as "polyinstantiation" is used.
http://en.wikipedia.org/wiki/Polyinstantiation

It allows several tuples with different security level to have same
primary key. When a higher-level user updates a tuple with lower
security level, DBMS makes a new tuple with higher-level and the original
one is kept unchanged. It does not prevent to leak a infomation belonging
with higher security level.

IIRC, FK has to refer a PK with same or lower security level to keep
consistency of its visibility in polyinstantiated tables. If a lower
level user modifies a PK with in same level, DBMS makes a copy of PK
with higher-level. This operating does not affect higher FKs, but
FK integrities are kept.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

> Yeah, that's what I keep hearing that the spooks think they want.
> I can't imagine how it would play nice with SQL-standard integrity
> constraints. Data that apparently violates a foreign-key constraint,
> for example, would give someone a pretty good clue that there's
> something there he's not being allowed to see.

Right, so you don't let that happen. If you're giving Mr. X access to
the "cities" table, and decide to restrict him only to cities in
Europe, then if you give him access to the "informants" table, you'll
probably restrict that to only informants located in cities that are
in Europe, so, no problem. It's easy to come up with cases where
there is a problem but just because there can be problems doesn't mean
the technology isn't basically useful.

I don't think there's much point in second-guessing the NSA: they are
smart and have thought about this more than we have. But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux. Column-level
permissions are the best example of this: it's very easy to imagine
people wanting that feature, but NOT being willing to run SELinux to
get it. It's more arguable whether data hiding falls into the same
category or not, because if you're doing data hiding then arguably
you're a security nut and more likely to be running (or willing to
run) SELinux. Against that, my boss made me do data hiding but we
have no interest in SELinux, so that's one data point the other way,
though not one I'd take all that seriously.

So far there has been no detailed discussion of any of the new
security features that are in this patch (column-level security,
row-level security, large object security, etc). For each of those
features, we need to answer the following questions:

1. Do we want this feature as a part of PostgreSQL at all?
2. If #1 is yes, do we eventually want to expose this feature via a
SQL interface, or some other interface substantially unlike
SE-PostgreSQL?
3. If #2 is yes, will accepting this patch get us closer to that goal
or further away from it?

I suspect that for most of the features the answer for #1 will be yes,
but the other two questions need some more careful examination.

...Robert

"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>> That's the wrong question. The question here is: does it make sense to
>> have per-row permissions implemented on top of an abstraction layer
>> whose sole current implementation is SE-Linux?

> Er, Bruce was asking about per-column, not per-row.

> There's a patch listed on CommitFest:2008-09 to introduce per-column
> permissions, but it's apparently still WIP. How much does that
> overlap/conflict with these patches?

Yeah, Stephen Frost is working on that and still has a ways to go.
I think he might get it done in time for 8.4 (ie, in time for the
November commitfest) but it's far from certain.

Per-column permissions are part of the SQL standard, and so I think
we have to implement that without depending on any OS-specific
infrastructure. So on that end I agree with Bruce's position that
we should do the SQL version first and then think about extensions
for SELinux.

Per-row is not in the spec and so we can design that as we please.
But as I mentioned a moment ago, I don't see how it can possibly
play nice with foreign keys ...

regards, tom lane

Bruce Momjian wrote:
> Robert Haas wrote:
>>> I think the answer is yes, because (as others have said) if we ever want
>>> to have SQL-level per-row permissions, then we can implement them with
>>> no change to the patch currently in discussion.
>> If that's true, it weighs somewhat in favor of accepting this patch,
>> but how sure are we that it's really the case? If you only have one
>> implementation sitting on top of your abstraction layer, it's hard to
>> know whether you've implemented a general framework for doing X or
>> merely an interface that happens to suit the particular flavor of X
>> that you want to do today.
>
> Yes, that is my point, and SE-Linux is just Linux, meaning it is
> OS-specific, making it even less generally useful.

I believe the upcomig "fine-grained security" patch enables to make
clear the security framework is NOT specific for SELinux only.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> I don't think there's much point in second-guessing the NSA: they are
> smart and have thought about this more than we have.

No doubt, but have they told us what we'd need to know to make a
non-broken implementation? I haven't seen anything about how a SQL
database ought to work to play nice with SELinux or similar controls.
I don't doubt that somebody inside Fort Meade has a good design for
this, but I have no confidence that we do.

regards, tom lane

Tom Lane wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>>> That's the wrong question. The question here is: does it make sense to
>>> have per-row permissions implemented on top of an abstraction layer
>>> whose sole current implementation is SE-Linux?
>
>> Er, Bruce was asking about per-column, not per-row.
>
>> There's a patch listed on CommitFest:2008-09 to introduce per-column
>> permissions, but it's apparently still WIP. How much does that
>> overlap/conflict with these patches?
>
> Yeah, Stephen Frost is working on that and still has a ways to go.
> I think he might get it done in time for 8.4 (ie, in time for the
> November commitfest) but it's far from certain.
>
> Per-column permissions are part of the SQL standard, and so I think
> we have to implement that without depending on any OS-specific
> infrastructure.

Yes, I agree this position. The OS-specific infrastructure works
orthogonally with native SQL standard access controls, as DAC/MAC
works orthogonally on operating system.

> So on that end I agree with Bruce's position that
> we should do the SQL version first and then think about extensions
> for SELinux.

A proposal of fine-grained security without OS is here:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01528.php

I'll pay my effort to submit a series of patches due to end of the Oct.

> Per-row is not in the spec and so we can design that as we please.
> But as I mentioned a moment ago, I don't see how it can possibly
> play nice with foreign keys ...

As I noted in above message, it handles PK/FK constraints as follows:
- When a user tries to insert/update a tuple with duplicate PK,
it is failed independent from its visibility.
- When a user tries to insert/update a tuple with FK, the refered PK
have to be visible.
- When a user tries to update/delete a tuple with PK which is refered
by invisible FK, it is failed independent from its visibility.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

* Robert Haas <robertmhaas(at)gmail(dot)com> [080924 00:15]:

> But I do think
> it's worthwhile to ask whether it makes sense to introduce a bunch of
> features that are only usable to people running SELinux.

Actually, I'ld go one stroke farther, and ask:
Does it make sense to introduce a bunch of features that are only
usable to people *able to write proper SELinux policy sets* (or whatever
they are called).

> it's very easy to imagine
> people wanting that feature, but NOT being willing to run SELinux to
> get it.

Or, being more generous even, able to *run* SELinux, but not able to
create a proper coherent set of SELinux policies... SELinux is
"standard" now on most RHEL installs (and FC, and now debian, etc), but
how many admins have actually "made" (or even just altered) a SELinux
policy, and how many have just disabled it because it prevented what
they thought should be a valid operation?

I'm sure NSA can do both of these, but I would hazard that the number of
other people able to do this well can probably be counted on my
fingers...

a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk wrote:
> * Robert Haas <robertmhaas(at)gmail(dot)com> [080924 00:15]:
>
>> But I do think
>> it's worthwhile to ask whether it makes sense to introduce a bunch of
>> features that are only usable to people running SELinux.
>
> Actually, I'ld go one stroke farther, and ask:
> Does it make sense to introduce a bunch of features that are only
> usable to people *able to write proper SELinux policy sets* (or whatever
> they are called).

It is incorrect.

In the recent years, SELinux comunity aspires to becoming that end users
can setup it without editing security policy. The default security policy
contains many pre-defined object types and booleans, end user can select
them, if needed.

For example, the default security policy of SE-PostgreSQL provides several
pre-defined object types, like sepgsql_table_t, sepgsql_secret_table_t,
sepgsql_ro_table_t and sepgsql_fixed_table_t for table/column/tuple.

>> it's very easy to imagine
>> people wanting that feature, but NOT being willing to run SELinux to
>> get it.
>
> Or, being more generous even, able to *run* SELinux, but not able to
> create a proper coherent set of SELinux policies... SELinux is
> "standard" now on most RHEL installs (and FC, and now debian, etc), but
> how many admins have actually "made" (or even just altered) a SELinux
> policy, and how many have just disabled it because it prevented what
> they thought should be a valid operation?

Can you think the security policy is something like a pattern file of
anti-virus software running on windows desktop? I allows end-users to
custamize some of options, but I have never seen a man who tries to
make its pattern file by myself.

Anyway, I don't think we can get a fruitful discussion like "how many
users enables SELinux" here. Here is pgsql-hackers list.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei wrote:
> Aidan Van Dyk wrote:
>> * Robert Haas <robertmhaas(at)gmail(dot)com> [080924 00:15]:
>>
>>> But I do think
>>> it's worthwhile to ask whether it makes sense to introduce a bunch of
>>> features that are only usable to people running SELinux.
>> Actually, I'ld go one stroke farther, and ask:
>> Does it make sense to introduce a bunch of features that are only
>> usable to people *able to write proper SELinux policy sets* (or whatever
>> they are called).
>
> It is incorrect.
>
> In the recent years, SELinux comunity aspires to becoming that end users
> can setup it without editing security policy. The default security policy
> contains many pre-defined object types and booleans, end user can select
> them, if needed.
>
> For example, the default security policy of SE-PostgreSQL provides several
> pre-defined object types, like sepgsql_table_t, sepgsql_secret_table_t,
> sepgsql_ro_table_t and sepgsql_fixed_table_t for table/column/tuple.
>
>>> it's very easy to imagine
>>> people wanting that feature, but NOT being willing to run SELinux to
>>> get it.
>> Or, being more generous even, able to *run* SELinux, but not able to
>> create a proper coherent set of SELinux policies... SELinux is
>> "standard" now on most RHEL installs (and FC, and now debian, etc), but
>> how many admins have actually "made" (or even just altered) a SELinux
>> policy, and how many have just disabled it because it prevented what
>> they thought should be a valid operation?
>
> Can you think the security policy is something like a pattern file of
> anti-virus software running on windows desktop? I allows end-users to

Sorry, s/I allows/It allows/g

> custamize some of options, but I have never seen a man who tries to
> make its pattern file by myself.
>
> Anyway, I don't think we can get a fruitful discussion like "how many
> users enables SELinux" here. Here is pgsql-hackers list.
>
> Thanks,

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei wrote:
> Tom Lane wrote:
> > Josh Berkus <josh(at)agliodbs(dot)com> writes:
> >> Multilevel frameworks have concepts of data hiding and data substitution
> >> based on labels. That is, if a user doesn't have permissions on data,
> >> he's not merely supposed to be denied access to it, he's not even supposed
> >> to know that the data exists. In extreme cases (think military / CIA use)
> >> data at a lower security level should be substitited for the higher
> >> security level data which the user isn't allowed. Silently.
> >
> > Yeah, that's what I keep hearing that the spooks think they want.
> > I can't imagine how it would play nice with SQL-standard integrity
> > constraints. Data that apparently violates a foreign-key constraint,
> > for example, would give someone a pretty good clue that there's
> > something there he's not being allowed to see.
>
> Please note that SE-PostgreSQL does not adopt following technology
> because of its complexity. When user tries to update a PK refered by
> invisible FK, it generate an error. Thus, it is theoretically possible
> to estimate the invisible PKs by attacks with repeating.

I assume if you use only non-natural keys (use sequence numbers, not
codes like PHL or USA), there is no problem in finding the missing keys
by repeated testing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Aidan Van Dyk wrote:
> * Robert Haas <robertmhaas(at)gmail(dot)com> [080924 00:15]:
>
>> But I do think
>> it's worthwhile to ask whether it makes sense to introduce a bunch of
>> features that are only usable to people running SELinux.
>
> Actually, I'ld go one stroke farther, and ask:
> Does it make sense to introduce a bunch of features that are only
> usable to people *able to write proper SELinux policy sets* (or whatever
> they are called).

I consider this a valid concern, but given that some people want MAC and
no one has shown a better way to implement MAC than SELinux, you can
hardly use that as an objection against this particular patch.

Peter Eisentraut wrote:
> Aidan Van Dyk wrote:
> > * Robert Haas <robertmhaas(at)gmail(dot)com> [080924 00:15]:
> >
> >> But I do think
> >> it's worthwhile to ask whether it makes sense to introduce a bunch of
> >> features that are only usable to people running SELinux.
> >
> > Actually, I'ld go one stroke farther, and ask:
> > Does it make sense to introduce a bunch of features that are only
> > usable to people *able to write proper SELinux policy sets* (or whatever
> > they are called).
>
> I consider this a valid concern, but given that some people want MAC and
> no one has shown a better way to implement MAC than SELinux, you can
> hardly use that as an objection against this particular patch.

Peter, I am confused how the above statement relates to a posting you
made a week ago:

http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php

Now these items are arguably useful and welcome features in their own
right. Unfortunately, this patch has chosen to provide these features in
a way that makes them accessible to the least amount of users. And
moreover, it bunches them all in one feature, while they should really
be available independently.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Aidan Van Dyk wrote:
>> Actually, I'ld go one stroke farther, and ask:
>> Does it make sense to introduce a bunch of features that are only
>> usable to people *able to write proper SELinux policy sets* (or whatever
>> they are called).

> I consider this a valid concern, but given that some people want MAC and
> no one has shown a better way to implement MAC than SELinux, you can
> hardly use that as an objection against this particular patch.

The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to discuss
just how large that set might be while we debate whether to accept the
patch.

regards, tom lane

On Wed, 24 Sep 2008 11:58:58 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> The objection comes down to this: it's an extremely large, invasive,
> and probably performance-losing patch, which apparently will be of use
> to only a rather small set of people. It's not unreasonable to
> discuss just how large that set might be while we debate whether to
> accept the patch.

I know of no one that really uses SELinux because it is a nightmare. On
the other hand, this type of security is required to get into certain
scary tin foil hat producing institutions.

Do we want want to target those respective types of installs. If so,
then we have no choice but to try and make this patch (or similar)
work. If not, then I believe it is entirely too large of a change to
even bother with.

Now and this I think would be a first for PostgreSQL and something that
may cause more trouble than it is worth but we could do:

./configure --enable-selinux # Experimental

And if we find it doesn't work out, we rip it out. Yes, it is a lot of
work. A great many of our community will not participate on this list
and thus will not speak up to the (perceived) considerable demand for
this type of feature. The fact that the gentlemen who wrote the patch
kept it up to date and improved it over two release cycles suggests
that there is significant interest in this somewhere.

Joshua Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/

Joshua Drake wrote:
> On Wed, 24 Sep 2008 11:58:58 -0400
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > The objection comes down to this: it's an extremely large, invasive,
> > and probably performance-losing patch, which apparently will be of use
> > to only a rather small set of people. It's not unreasonable to
> > discuss just how large that set might be while we debate whether to
> > accept the patch.
>
> I know of no one that really uses SELinux because it is a nightmare. On
> the other hand, this type of security is required to get into certain
> scary tin foil hat producing institutions.
>
> Do we want want to target those respective types of installs. If so,
> then we have no choice but to try and make this patch (or similar)
> work. If not, then I believe it is entirely too large of a change to
> even bother with.

I think if we get the SQL-level stuff we want implemented we can see
much better how much code SE-Linux support requires. For example, as
the patch stands we have SE-Linux-specific tuple header fields, which
seems like major overkill, but if the fields were already there for SQL
feature capability the SE-Linux patch would be much less invasive.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Peter, I am confused how the above statement relates to a posting you
> made a week ago:
>
> http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php
>
> Now these items are arguably useful and welcome features in their own
> right. Unfortunately, this patch has chosen to provide these features in
> a way that makes them accessible to the least amount of users. And
> moreover, it bunches them all in one feature, while they should really
> be available independently.

I just want to distinguish the causalities in the various arguments that
are being made. There are many ways to approach this, two of which
could be:

We want MAC => SELinux is the only proven way to implement MAC => let's
take the patch

or

SELinux is way too complex => We don't take the patch => Figure out the
MAC issue some other way

Joshua Drake wrote:
> I know of no one that really uses SELinux because it is a nightmare. On
> the other hand, this type of security is required to get into certain
> scary tin foil hat producing institutions.

Yeah, but do we even have the slightest bit of information about what
exactly would be required to achieve the required levels? And whether
this patch does it? And whether there would be alternative, more
desirable ways to achieve a similar level?

I am not arguing for or against this patch now, but I would like to know
whether someone has an agenda for it. Without an agenda, future
maintenance will be difficult. Reference to standards or other public
documents would work best to define that agenda.

Peter,

> Yeah, but do we even have the slightest bit of information about what
> exactly would be required to achieve the required levels? And whether
> this patch does it? And whether there would be alternative, more
> desirable ways to achieve a similar level?

Actually, I have some direct communication that SEPostgres will lead to
PostgreSQL being widely adopted in at least one US government agency.
Can't say more, of course. ;-)

--Josh

On Wed, 24 Sep 2008 11:38:36 -0700
Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> Peter,
>
> > Yeah, but do we even have the slightest bit of information about
> > what exactly would be required to achieve the required levels? And
> > whether this patch does it? And whether there would be
> > alternative, more desirable ways to achieve a similar level?
>
> Actually, I have some direct communication that SEPostgres will lead
> to PostgreSQL being widely adopted in at least one US government
> agency. Can't say more, of course. ;-)

/me notes his tin foil hat argument.

Joshua D. Drake

>
> --Josh
>

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/

On Sep 24, 2008, at 2:38 PM, Josh Berkus wrote:

> Peter,
>
>> Yeah, but do we even have the slightest bit of information about
>> what exactly would be required to achieve the required levels? And
>> whether this patch does it? And whether there would be
>> alternative, more desirable ways to achieve a similar level?
>
> Actually, I have some direct communication that SEPostgres will lead
> to PostgreSQL being widely adopted in at least one US government
> agency. Can't say more, of course. ;-)

And the consideration is predicated on the PostgreSQL community
accepting the patch? This sounds like an opportunity for one of the
numerous "enterprise" spin-offs.

Cheers,
M

Josh Berkus wrote:
> Peter,
>
> > Yeah, but do we even have the slightest bit of information about what
> > exactly would be required to achieve the required levels? And whether
> > this patch does it? And whether there would be alternative, more
> > desirable ways to achieve a similar level?
>
> Actually, I have some direct communication that SEPostgres will lead to
> PostgreSQL being widely adopted in at least one US government agency.
> Can't say more, of course. ;-)

We can't make decisions based on just one adoption agency, of course.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Peter,
>> Yeah, but do we even have the slightest bit of information about what
>> exactly would be required to achieve the required levels? And whether
>> this patch does it? And whether there would be alternative, more
>> desirable ways to achieve a similar level?

> Actually, I have some direct communication that SEPostgres will lead to
> PostgreSQL being widely adopted in at least one US government agency.

Does that mean that they have looked at this specific patch and
concluded that it meets their requirements? Or just that SELinux
is a checkbox item for them?

regards, tom lane

> The objection comes down to this: it's an extremely large, invasive,
> and probably performance-losing patch, which apparently will be of use
> to only a rather small set of people. It's not unreasonable to discuss
> just how large that set might be while we debate whether to accept the
> patch.

Significant loss of performance for people who are not using the
feature seems like it ought to be considered a non-starter. "Not
using MAC" needs to be a fast-path.

...Robert

Robert Haas wrote:
> > The objection comes down to this: it's an extremely large, invasive,
> > and probably performance-losing patch, which apparently will be of use
> > to only a rather small set of people. It's not unreasonable to discuss
> > just how large that set might be while we debate whether to accept the
> > patch.
>
> Significant loss of performance for people who are not using the
> feature seems like it ought to be considered a non-starter. "Not
> using MAC" needs to be a fast-path.

Right now all of SE-PostgreSQL is a compile-time option so I assume the
slowdown is only for compile-enabled builds.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom,

> Does that mean that they have looked at this specific patch and
> concluded that it meets their requirements? Or just that SELinux
> is a checkbox item for them?

That it was a checkbox item for them, and it led to them evaluating
PostgreSQL when they otherwise wouldn't have. I don't know the current
status of that evaluation.

--
--Josh

Josh Berkus
PostgreSQL
San Francisco

Peter Eisentraut wrote:
> I am not arguing for or against this patch now, but I would like to know
> whether someone has an agenda for it. Without an agenda, future
> maintenance will be difficult. Reference to standards or other public
> documents would work best to define that agenda.

It is a bit old, but describes whole of the SE-PostgreSQL.
http://sepgsql.googlecode.com/files/sepgsql_security_guide.20080214.en.pdf

I think it has to be updated to reflect for the recent updates like
implementation changes in row-level access controls.
In addition, I also think maintenance of the feature is primarily
my work, no need to say.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Bruce Momjian wrote:
> Robert Haas wrote:
>>> The objection comes down to this: it's an extremely large, invasive,
>>> and probably performance-losing patch, which apparently will be of use
>>> to only a rather small set of people. It's not unreasonable to discuss
>>> just how large that set might be while we debate whether to accept the
>>> patch.
>> Significant loss of performance for people who are not using the
>> feature seems like it ought to be considered a non-starter. "Not
>> using MAC" needs to be a fast-path.
>
> Right now all of SE-PostgreSQL is a compile-time option so I assume the
> slowdown is only for compile-enabled builds.

Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.

In addition, these are invoked via security hooks which are declared
as inline functions. So, I think it does not give us additional loss of
performances when you don't add the compile time option explicitly.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

> Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
>
> In addition, these are invoked via security hooks which are declared
> as inline functions. So, I think it does not give us additional loss of
> performances when you don't add the compile time option explicitly.

That is good as far as it goes but I assume that if this patch is
accepted many vendors will build with this feature enabled, and many
end-users will turn off SELinux but keep the same binaries. It's
important that those people don't get hosed either.

It's also probably worth asking what the performance penalty is when
you ARE using all the bells and whistles.

...Robert

Robert Haas wrote:
>> Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
>>
>> In addition, these are invoked via security hooks which are declared
>> as inline functions. So, I think it does not give us additional loss of
>> performances when you don't add the compile time option explicitly.
>
> That is good as far as it goes but I assume that if this patch is
> accepted many vendors will build with this feature enabled, and many
> end-users will turn off SELinux but keep the same binaries. It's
> important that those people don't get hosed either.

When we run a binary with this feature on non-SELinux'ed environment,
security hooks simply returns with reference to the flag variable
which shows whether SELinux is available on the host.

> It's also probably worth asking what the performance penalty is when
> you ARE using all the bells and whistles.

Are you saying the performance penalty when full functionalities are enabled?
(The meaning of "bells and whistles" is unclear for me.)

We can show it on the page.22 of my presentation in PGcon2008.
http://www.pgcon.org/2008/schedule/attachments/38_pgcon2008-sepostgresql.pdf

It shows about 10% of penalty in maximum in pgbench, and larger database
tend to have relatively less performance penalty.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

> Are you saying the performance penalty when full functionalities are
> enabled?
> (The meaning of "bells and whistles" is unclear for me.)

Yes, that's what I meant. (Sorry.)

> We can show it on the page.22 of my presentation in PGcon2008.
> http://www.pgcon.org/2008/schedule/attachments/38_pgcon2008-sepostgresql.pdf
>
> It shows about 10% of penalty in maximum in pgbench, and larger database
> tend to have relatively less performance penalty.

That doesn't really sound too bad if you are operating in an
environment where security is paramount. Of course, if your vendor
enables SELinux and SEPostgresql by default (even though you don't
really care) then it might not be so good.

...Robert