Thread: 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.23or 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@anoncvs.postgresql.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 thisversion, 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 areinserted 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 findit because these are inserted within same command id and SnapshotNow scanning mode ignores these tuples. We cannotinvoke 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 lookingup pg_class. The other is to insert a temporary entry into SysCache until it is invalidated. The later approachcan also be applied on the next situation, so we now put InsertSysCache() withing heap_create_with_catalog() torefer 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 indicatesthe oid of pg_security system catalog. If it was not found, PGACE/SE-PostgreSQL inserts a new tuple and appliesits oid as an internal identifier. If a same new security context is given within same currentCommandId twiceor more, it tries to insert a new tuple into pg_security twice or more. However, it violates uniqueness constraintat oid of pg_security. Thus, we had to look up pg_security with SnapshotSelf scanning mode as a fallback when SearchSysCache() returns invalidtuple. But we can apply same approach here. So, InsertSysCache() is invoked to keep a newly inserted securitycontext 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 whetherthe 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_largeobjectfor each insertion/deletion. If requests come from lowrite() or lo_create(), we can distinguish its meanings, so proper permissions are applied inthe 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: alwaysfollows kernel setting (default) - enforcing: works in enforcing mode (MAC and audit enabled). - permissive: worksin 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 reducecost 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 theonly one writable.) If it returns true on the target of INSERT, UPDATE or SELECT INTO, these TargetEntries are markedas 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, becausepg_security system catalog is not constructed yet in this time. The current version holds them in-memory cache andwrites 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 regressiontest without any problem, except for two tests which can be explained reasonably. * SELinux state monitoringprocess is implemented using an existing facilities provided by postmaster.c. * Coding styles are fixed. * Adefinition of LWlock is moved to storage/lwlock.h * Definitions of SEvalItemXXXX are moved to nodes/nodes.h * Compiler warningscome from SE-PostgreSQL are killed. * Some error codes are added within 'SE' class, and elog()s which can reportuser facing messages are replaced by ereport(). * Shell function is removed from genbki.sh. * Default security contextof 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 librarymodules installed under user's home directory. # /usr/sbin/setsebool sepgsql_regression_test_mode on $ make check : (snip) : ======================== 2 of 115 tests failed. ======================== [kaigai@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 LANGUAGEC 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" infile "/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@ak.jp.nec.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@anoncvs.postgresql.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@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@kaigai.gr.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'thave 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@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.com>
At 2008-07-11 19:10:16 +0900, kaigai@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.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@kaigai.gr.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 isupdated 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@ak.jp.nec.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@ak.jp.nec.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@gregsmith.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 configureyour application server using SELinux? I'm no expert on> these things, but I wonder, would it even work in a usefulway, 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 setupmay> 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 securitycontext to other peer side. We can fetch delivered one with getpeercon() API. SE-PostgreSQL also uses this API toobtain 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 witha 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 wayas 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 POSIXACLs to PostgreSQL, or> port SQL roles back to the operating system, or something else that> captures what more peopleare 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 configurationlanguage 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 sortof 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. Itwould be hard to explain> that PostgreSQL does not have column-level GRANT privileges but that you> can achieve the sameif 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 areinteresting 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. Implementrow-level security, column-level privileges, and all other> necessary permission bits as SQL features.>> 2. Enhancethe role system to meet whatever the evaluation criteria may be.>> 3a. Add access control extension hooks.>> 3b. ImplementSELinux 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@ak.jp.nec.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@ak.jp.nec.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@kaigai.gr.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. Itwould be hard to explain> that PostgreSQL does not have column-level GRANT privileges but that you> can achieve the sameif 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 itsscope 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@ak.jp.nec.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@kaigai.gr.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
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 accesscontrol - 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@kaigai.gr.jp>
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
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@kaigai.gr.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@kaigai.gr.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@momjian.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@momjian.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@momjian.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@momjian.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@ak.jp.nec.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@agliodbs.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@momjian.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@agliodbs.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@ak.jp.nec.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@gmail.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@ak.jp.nec.com>
"Robert Haas" <robertmhaas@gmail.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@gmail.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 itsvisibility. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
* Robert Haas <robertmhaas@gmail.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 topeople *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@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Aidan Van Dyk wrote: > * Robert Haas <robertmhaas@gmail.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@kaigai.gr.jp>
KaiGai Kohei wrote: > Aidan Van Dyk wrote: >> * Robert Haas <robertmhaas@gmail.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@kaigai.gr.jp>
KaiGai Kohei wrote: > Tom Lane wrote: > > Josh Berkus <josh@agliodbs.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@momjian.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@gmail.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@gmail.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 ownright. Unfortunately, this patch has chosen to providethese features ina way that makes them accessible to the least amount of users. Andmoreover, it bunches them all inone feature, while they should reallybe available independently. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Peter Eisentraut <peter_e@gmx.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@sss.pgh.pa.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@sss.pgh.pa.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@momjian.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@agliodbs.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Josh Berkus <josh@agliodbs.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@momjian.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@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.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