Обсуждение: SE-PgSQL patch review
I'm reviewing SE-PgSQL patch and have some comments. https://commitfest.postgresql.org/action/patch_view?id=212 Forgive me, but I'm a novice of SELinux. Some of the comments and question might be nonsense. ==== Patch overview ==== The patch itself is large (>13K), but more than half of it are well-written regression test, comments and README. It adds object-level and column-level security checks after normal permission checks. Row-level checks are not included in the patch. ==== Syntax and identifier names ==== * Can we use "security context" only for securty checking but also for general "context" handling? If so, we can call itjust "context". It might be useful if the context is designed for more general purpose. For example, we could develop context-basedlogging or contex-aware setting parameters. I think "Application Name" patch is one of the implementations ofcontext-based logging. https://commitfest.postgresql.org/action/patch_view?id=195 * CREATE TABLE tbl (...) SECURITY_CONTEXT = '...' IMHO, '_' and '=' don't suit for SQL. If there are no conflicts in gram.y,how about removing them? CREATE TABLE tbl (...) SECURITY CONTEXT '...' * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') Is the syntax "<AS> SECURITY_CONTEXT" natural in English? * Since SE-PgSQL will be integrated into the core, we can use pg_* names for the feature. For example, we can rename sepgsql_getcon()to pg_get_security_context(). Also, we should not use 'con' as an abbreviated form of 'context' becausewe often use it for 'connection'. The same can be said for GUC parameter names. (ex: "sepostgresql" to be "security_policy") ==== Error messages and error codes ==== * It uses dedicated 'SExxx' error codes, but I think they should belong to the same family of ERRCODE_INSUFFICIENT_PRIVILEGE(42501). /* Class SE - SE-PostgreSQL Error (SE-PgSQL-specific error class) */ #define ERRCODE_SELINUX_INTERNAL_ERROR MAKE_SQLSTATE('S','E', '0','0','1') #define ERRCODE_INVALID_SECURITY_CONTEXT MAKE_SQLSTATE('S','E','0','0','2') #define ERRCODE_SELINUX_AUDIT_LOG MAKE_SQLSTATE('S','E', '0','0','3') * Can we use error messages that looks like existing privilege errors? ERRCODE_INSUFFICIENT_PRIVILEGE: => permissiondenied to rename database Error messages from SE-PgSQL => SE-PgSQL prevents to modify "pg_class" by hand looksvery different. I'd suggest something like => security context denied to rename database I'll suggest we avoid using the term "SE-PgSQL" in the user visible message and documentation because because the featurewill be integrated into the core deeply. Of course, we can use "SE-PgSQL" in *promotion*. ==== Internal structures ==== * Are the security labels enough stable? What will we need when SELinux configuration is modified? We store security labelsas text for each object and column. * Each security checks are called after pg_*_aclcheck(). Is it possible to merge SE-PgSQL checks into ACL functions in aclchk.c? * What is difference between sepgsql_database_getcon(oid) and pg_database.datsecon? Why do we need those getcon functions? That's all comments for now. I'll test the patch in actual machines next. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Itagaki Takahiro wrote: > I'm reviewing SE-PgSQL patch and have some comments. > https://commitfest.postgresql.org/action/patch_view?id=212 > > Forgive me, but I'm a novice of SELinux. Some of the comments > and question might be nonsense. Itagaki-san, thanks for your volunteering so much! > ==== Patch overview ==== > The patch itself is large (>13K), but more than half of it are > well-written regression test, comments and README. > > It adds object-level and column-level security checks after normal > permission checks. Row-level checks are not included in the patch. Yes, I separated most of features to reduce code size. The developer documentation and source code comments were added instead. > ==== Syntax and identifier names ==== > * Can we use "security context" only for securty checking but also > for general "context" handling? If so, we can call it just "context". > It might be useful if the context is designed for more general purpose. > For example, we could develop context-based logging or contex-aware > setting parameters. I think "Application Name" patch is one of the > implementations of context-based logging. > https://commitfest.postgresql.org/action/patch_view?id=195 The "security context" is a proper-noun in SELinux. I don't think it is a good idea to call it just a "context". If we have a set of properties of the client called as a context, security context is one of the property in a context, such as user identifier, application name and so on. If Log_line_prefix supports the security context of the client, it seems me a good idea. (However, we can implement it in the future.) BTW, SELinux also provides indications about what should be logged on access violation events. It is also an duty of userspace object manager. See the sepgsql_audit_log() in selinux.c. > * CREATE TABLE tbl (...) SECURITY_CONTEXT = '...' > IMHO, '_' and '=' don't suit for SQL. > If there are no conflicts in gram.y, how about removing them? > CREATE TABLE tbl (...) SECURITY CONTEXT '...' I tried it, and it seems to me fine. > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') > Is the syntax "<AS> SECURITY_CONTEXT" natural in English? We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT to avoid syntax conflicts to "DEFAULT b_expr" option. > * Since SE-PgSQL will be integrated into the core, we can use pg_* > names for the feature. For example, we can rename sepgsql_getcon() to > pg_get_security_context(). Also, we should not use 'con' as an > abbreviated form of 'context' because we often use it for 'connection'. > The same can be said for GUC parameter names. What is your opinion for '*_secon()', instead of '*_security_context'? If OK, these functions will be renamed as follows: - sepgsql_template1_getcon -> pg_get_template1_secon - sepgsql_default_getcon -> pg_get_default_secon - sepgsql_getcon -> pg_get_client_secon - sepgsql_database_getcon -> pg_get_database_secon - sepgsql_schema_getcon -> pg_get_schema_secon - sepgsql_relation_getcon -> pg_get_relation_secon - sepgsql_attribute_getcon -> pg_get_attribute_secon > (ex: "sepostgresql" to be "security_policy") I prefer "selinux_support" more than "security_policy", because it is a noun to mean a set of access control rules in the kernel. > ==== Error messages and error codes ==== > * It uses dedicated 'SExxx' error codes, but I think they should belong to > the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501). > /* Class SE - SE-PostgreSQL Error (SE-PgSQL-specific error class) */ > #define ERRCODE_SELINUX_INTERNAL_ERROR MAKE_SQLSTATE('S','E', '0','0','1') > #define ERRCODE_INVALID_SECURITY_CONTEXT MAKE_SQLSTATE('S','E', '0','0','2') > #define ERRCODE_SELINUX_AUDIT_LOG MAKE_SQLSTATE('S','E', '0','0','3') I already uses predefined error code, if exist. For example, sepgsql_compute_perms() is the routine to make access control decision in SELinux. It uses ERRCODE_INSUFFICIENT_PRIVILEGE, when it needs to raise an error. extern bool sepgsql_compute_perms(char *scontext, char *tcontext, uint16 tclass, uint32 required, const char *audit_name, bool abort) { : /* * It asks SELinux whetherthe given access should be allowed, * or not. It set the given avd structure correctly, then returns. */ compute_perms_internal(scontext, tcontext, tclass, &avd); : /* * If here is no policy violations,or SE-PgSQL performs in permissive * mode, or the client process peforms in permissive domain, it returns * normally with 'true'. */ if (!denied || !sepgsql_get_enforce() || (avd.flags & SELINUX_AVD_FLAGS_PERMISSIVE)!= 0) return true; : /* * Otherwise, it raises an error or returns'false', depending on the * caller's indication by 'abort'. */ if (abort) ereport(ERROR, (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE), errmsg("SELinux: security policy violation"))); return false; } These error codes has its own meanings. * ERRCODE_SELINUX_INTERNAL_ERROR It is an error due to the communication between PostgreSQL and SELinux. It seems similarto ERRCODE_INTERNAL_ERROR, but it is not "can't-happen" conditions, so I defined it individually. * ERRCODE_INVALID_SECURITY_CONTEXT It is used when client gives an invalid security context on CREATE or ALTER statement.I could not find any similar predefined error code. * ERRCODE_SELINUX_AUDIT_LOG It is used when SE-PgSQL generates access violation logs, not an error. I also could not findany similar predefined error code. > * Can we use error messages that looks like existing privilege errors? > ERRCODE_INSUFFICIENT_PRIVILEGE: > => permission denied to rename database Here is a point that we should provide users a hint which enables to make clear the reason of access violations. So, I think we should contains a mark to show it come from SE-PgSQL. Currently, it raises an error on access violation in sepgsql_compute_perms(). It always prints out "SELinux: security policy violation". > Error messages from SE-PgSQL > => SE-PgSQL prevents to modify "pg_class" by hand > looks very different. I'd suggest something like > => security context denied to rename database If we follow the existing manner, it may be: "SELinux: permission denied: \"%s\" is a system catalog" > I'll suggest we avoid using the term "SE-PgSQL" in the user visible > message and documentation because because the feature will be integrated > into the core deeply. Of course, we can use "SE-PgSQL" in *promotion*. If we use another name for the feature, "SELinux support" may be preferable? > ==== Internal structures ==== > * Are the security labels enough stable? > What will we need when SELinux configuration is modified? > We store security labels as text for each object and column. If the security labels get invalid due to the modification of SELinux configuration or other reasons, it considers the database objects are unlabeled. Whenever we fetch a text representation of security label from system catalog, it invokes security_check_context_raw() to check whether the security label is valid on the current configuration, or not. If invalid, it obtains an "unlabeled" security context from the system. For example, bool sepgsql_database_common(Oid datOid, uint32 required, bool abort) { : /* * (1) It fetches a securitycontext from pg_database.datsecon * as a text data. */ tuple = SearchSysCache(DATABASEOID, ObjectIdGetDatum(datOid), 0, 0, 0); if (!HeapTupleIsValid(tuple)) elog(ERROR, "cache lookup failed for database %u", datOid); datsecon = SysCacheGetAttr(DATABASEOID, tuple, Anum_pg_database_datsecon, &isnull); if (!isnull) context = TextDatumGetCString(datsecon); /* * (2) If the fetched security context is nota valid one, * we obtain system's "unlabeled" security context as a fallback. * - security_check_context_raw()applies validation checks * - sepgsql_get_unlabeled_context() returns "unlabeled" context. * Typically, it is "system_u:object_r:unlabeled_t:s0" */ if (!context || security_check_context_raw(context)< 0) context = sepgsql_get_unlabeled_context(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /* * (3) We call permission check routine on a couple of security * contexts (client and the target database). * It may be a valid security context, or "unlabeld" security * context.In either case, we can provide a valid security context. */ audit_name = NameStr(((Form_pg_database) GETSTRUCT(tuple))->datname); rc = sepgsql_compute_perms(sepgsql_get_client_context(), context, SEPG_CLASS_DB_DATABASE, required, audit_name, abort); ReleaseSysCache(tuple); return rc; } > * Each security checks are called after pg_*_aclcheck(). Is it possible to > merge SE-PgSQL checks into ACL functions in aclchk.c ? It is impossible due to some reasons. For example, some of entrypoints are enclosed by "if (superuser())". It implicitly allows any clients with superuser attribute to bypass MAC checks, but it is quite violates SE-PgSQL's design, if we put the hooks in the PG default model routines. For example, SE-PgSQL model distinguish "setattr" permission from "drop". But pg_class_ownercheck() is used for both ALTER and DROP statement. So, we cannot know which permission should be applied inside from the pg_class_ownercheck(). For example, ... We already tried to provide a common set of entrypoints for both of DAC and MAC at the last commit fest ("Reworks for Access Controls" patch). This abstraction layer had to provide enough information to make access control decisions for both of models, and be deployed on the strategic points for both models. But it needed massive amount of reworks in the core routines, so we decided this approach is not a right direction. > * What is difference between sepgsql_database_getcon(oid) and > pg_database.datsecon? Why do we need those getcon functions? SELinux allows to translate the last field of security context between a human readable form and a raw form. For example, if a table is labeled as follows: system_u:object_r:sepgsql_table_t:s0:c1 ^^^^^ We call this field as "range" or "mcs label". In the raw-format, it is a complex of symbols, but we can assign human meaningfull alias on them. If "s0:c1" has its alias ("1st_sales_division"), above security context shall be printed as: system_u:object_r:sepgsql_table_t:1st_sales_division ^^^^^^^^^^^^^^^^^^ This feature is called "mcstrans". It is necessary to port a definition of security context to other hosts which may not have same mapping between a human-readable and raw format. Thus, I used sepgsql_xxxx_getcon() function in the pg_dump to follows the manner in SELinux when we export/import security context of objects from/to the object manager (PostgreSQL). I'll revise the following things at first: - Replace SE-PgSQL from user visible error messages and documentations. - SECURITY_CONTEXT [=] '<label>' to be SECURITY CONTEXT '<label>' Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
>> * Can we use error messages that looks like existing privilege errors? >> ERRCODE_INSUFFICIENT_PRIVILEGE: >> => permission denied to rename database > > Here is a point that we should provide users a hint which enables > to make clear the reason of access violations. So, I think we should > contains a mark to show it come from SE-PgSQL. > > Currently, it raises an error on access violation in sepgsql_compute_perms(). > It always prints out "SELinux: security policy violation". It is just for your information. SELinux allows end-users to confirm what accesses are violated using audit logs. In operating system, it is written on the /var/log/audit/audit.log. See the result of: % grep ^type=AVC /var/log/audit/audit.log : type=AVC msg=audit(1258412043.107:81): avc: denied { search } for pid=1750 comm="httpd" name="root" dev=sda5 ino=1062881 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:admin_home_t:s0tclass=dir : In SE-PgSQL, it writes out detailed information about access violations on log files. Then, it can be used to revise security policy. For example: postgres=# UPDATE t1 SET a = 1; ERROR: SELinux: security policy violation It shall be logged as follows: LOG: SELinux: denied { update } scontext=unconfined_u:unconfined_r:sepgsql_test_t:Unclassifiedtcontext=system_u:object_r:sepgsql_ro_table_t:Classified tclass=db_tablename=t1 STATEMENT: UPDATE t1 SET a = 1; ERROR: SELinux: security policy violation STATEMENT: UPDATE t1SET a = 1; We can also provide these logs to analyzer programs to pop-up a hint for trouble-shooting (setroubleshoot), to generate policy module automatically from access violation logs (audit2allow), and so on. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote: > Itagaki Takahiro wrote: > > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') > > Is the syntax "<AS> SECURITY_CONTEXT" natural in English? > > We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT > to avoid syntax conflicts to "DEFAULT b_expr" option. Does "WITH" work? Seems to read better to me: CREATE TABLE tbl (col integer WITH SECURITY CONTEXT [...]) -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Systems Engineer & Admin, Research Scientist phone: 713-348-6166 The Connexions Project http://cnx.org fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
Ross J. Reedstrom wrote: > On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote: >> Itagaki Takahiro wrote: >>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') >>> Is the syntax "<AS> SECURITY_CONTEXT" natural in English? >> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT >> to avoid syntax conflicts to "DEFAULT b_expr" option. > > Does "WITH" work? Seems to read better to me: > > CREATE TABLE tbl (col integer WITH SECURITY CONTEXT [...]) > It was conflicted. :( -- KaiGai Kohei <kaigai@kaigai.gr.jp>
KaiGai Kohei wrote: > Ross J. Reedstrom wrote: >> On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote: >>> Itagaki Takahiro wrote: >>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') >>>> Is the syntax "<AS> SECURITY_CONTEXT" natural in English? >>> We need to put a reserved token, such as "AS", prior to the >>> SECURITY_CONTEXT >>> to avoid syntax conflicts to "DEFAULT b_expr" option. >> >> Does "WITH" work? Seems to read better to me: >> >> CREATE TABLE tbl (col integer WITH SECURITY CONTEXT [...]) >> > It was conflicted. :( BTW, we have two options, if we don't use AS token here. 1. It moves "SECURITY" to reserved keyword.We can represent SECURITY CONTEXT option for each columns quitenatural, but italso has a pain. It disallow to use "security"as a column name. 2. Another syntax to support SECURITY CONTEXTFor example: CREATE TABLE tbl_name ( col_X_name int primary key, col_Y_name text default 'aaa' ) SECURITY CONTEXT ( 'label of the table', col_Y_name IS'label of the column Y', ... ); I don't have any preference between the current syntax and the new one. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: > > CREATE TABLE tbl (...) SECURITY CONTEXT '...' > > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') > > We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT > to avoid syntax conflicts to "DEFAULT b_expr" option. There might be another idea to put security context in WITH options:1. CREATE TABLE tbl (...) WITH (security_context = '...')2.CREATE TABLE tbl (col integer WITH (security_context = '...') PRIMARY KEY) If we use the syntax, '_' and '=' is reasonable. BTW, I like to reverse the order of constraints and WITH options in column definitions (2), but I could not solve shift/reduce errors -- it might conflict with "PRIMARY KEY WITH (index-parameters)". > - sepgsql_template1_getcon -> pg_get_template1_secon > - sepgsql_database_getcon -> pg_get_database_secon Why do we need two version of functions for template1 and database? The template1 database is the default template for CREATE DATABASE, but we can also choose another one. Do we need to distinguish them? > > * It uses dedicated 'SExxx' error codes, but I think they should belong to > > the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501). > I already uses predefined error code, if exist. What I meant was: there are no problem to add new error codes for SE-PgSQL, but I think the values of the codes should be '42xxx' because those errors are still "Class 42 - Access Rule Violation" from the view of users. > > ==== Internal structures ==== > > * Are the security labels enough stable? > > We store security labels as text for each object and column. > > If the security labels get invalid due to the modification of SELinux > configuration or other reasons, it considers the database objects are > unlabeled. I believe you have a plan to add row-level security checking in the future version. Do you have some documentation about how to implement security context for each row? I'm worrying about the on-disk representation. Security labels stored in text format takes 20-40 bytes per row. It is not negligibly-small, and might be hard to be treated because of variable-length. We store OIDs for each row at the end of tuple header. If we also store securty labels in the same way, will we need some kinds of "securty label to OID" converter in the future? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Itagaki Takahiro wrote: > KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: > >>> CREATE TABLE tbl (...) SECURITY CONTEXT '...' >>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...') >> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT >> to avoid syntax conflicts to "DEFAULT b_expr" option. > > There might be another idea to put security context in WITH options: > 1. CREATE TABLE tbl (...) WITH (security_context = '...') > 2. CREATE TABLE tbl (col integer WITH (security_context = '...') PRIMARY KEY) > If we use the syntax, '_' and '=' is reasonable. > > BTW, I like to reverse the order of constraints and WITH options in > column definitions (2), but I could not solve shift/reduce errors > -- it might conflict with "PRIMARY KEY WITH (index-parameters)". If we put "SECURITY CONTEXT" clause prior to the column constraints, there are no syntax conflicts. However, it seems to me not intuitive. like, CREATE TABLE tbl (col int SECURITY CONTEXT '...' NOT NULL); In addition, if we inject "security_context" in the relation options, the way to fetch it is far different from other database objects. Instead, what is your opinion for the syntax? CREATE TABLE tbl (...) SECURITY CONTEXT ('label', col='label', ...); When "col=" is omitted, it means an explicit security context of thenew table. Otherwise, it means an explicit one of thegiven column. And, for consistency, CREATE DATABASE dbname SECURITY CONTEXT ('label');CREATE SCHEMA scname SECURITY CONTEXT ('label'); >> - sepgsql_template1_getcon -> pg_get_template1_secon >> - sepgsql_database_getcon -> pg_get_database_secon > > Why do we need two version of functions for template1 and database? > The template1 database is the default template for CREATE DATABASE, > but we can also choose another one. Do we need to distinguish them? They have different purposes. The sepgsql_database_getcon() prints out a security context of the database for the given OID in human-readable form. The sepgsql_template1_getcon() returns a security context to be assigned on the initial database from SELinux configuration. Typically, it is configured at /etc/selinux/targeted/contexts/sepgsql_contexts. If not exist, it asks SELinux a default security context as an initial database. Then, initdb uses the result to assign initial security context of the managed database objects. >>> * It uses dedicated 'SExxx' error codes, but I think they should belong to >>> the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501). >> I already uses predefined error code, if exist. > > What I meant was: there are no problem to add new error codes for SE-PgSQL, > but I think the values of the codes should be '42xxx' because those errors > are still "Class 42 - Access Rule Violation" from the view of users. Ahh, OK. I'll fix it. >>> ==== Internal structures ==== >>> * Are the security labels enough stable? >>> We store security labels as text for each object and column. >> If the security labels get invalid due to the modification of SELinux >> configuration or other reasons, it considers the database objects are >> unlabeled. > > I believe you have a plan to add row-level security checking in the future > version. Do you have some documentation about how to implement security > context for each row? I'm worrying about the on-disk representation. > Security labels stored in text format takes 20-40 bytes per row. It is not > negligibly-small, and might be hard to be treated because of variable-length. > > We store OIDs for each row at the end of tuple header. If we also > store securty labels in the same way, will we need some kinds of > "securty label to OID" converter in the future? Yes, it was contained in the earlier proposition with full-set functionalities. http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog In SELinux model, massive number of objects shares a limited number of security context (e.g more than 100 tables may have a same one), this design (it stores "security label OID" within the tuple header) is well suitable for database objects. BTW, I plan the following steps for the row-level security. | * A facility to put "security label OID" within the tuple header. | * System column support to print out the security context. | (This system column shall be writable to relabel) | * Pure-SQL row-level security checks, something like Oracle Private | Database which allows user defined access control decision function. | * SELinux aware row-level checks on the virtual private database stuff. V It can be implemented as one of the decision making functions. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
>>>> * It uses dedicated 'SExxx' error codes, but I think they should belong to >>>> the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501). >>> I already uses predefined error code, if exist. >> What I meant was: there are no problem to add new error codes for SE-PgSQL, >> but I think the values of the codes should be '42xxx' because those errors >> are still "Class 42 - Access Rule Violation" from the view of users. > > Ahh, OK. I'll fix it. I also think ERRCODE_INVALID_SECURITY_CONTEXT is suitable for the Access Rule Violation class ('44xxx'). However, it seems to me ERRCODE_SELINUX_INTERNAL_ERROR should be moved to the System Error class ('58xxx'), because it will be raised due to the problem on communicating with SELinux, not access violations. And, we may be able to remove ERRCODE_SELINUX_AUDIT_LOG, because audit logs are generated on access violation events (in most case, if security policy is right), so ERRCODE_INSUFFICIENT_PRIVILEGE might be suitable to call ereport(LOG, ...) with an audit log message. Isn't it strange in manner? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: > >>> ==== Internal structures ==== > http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog > > In SELinux model, massive number of objects shares a limited number of > security context (e.g more than 100 tables may have a same one), this > design (it stores "security label OID" within the tuple header) is well > suitable for database objects. What plan do you have for system columns added by the patch (datsecon, nspsecon, relsecon, etc) after we have securty_id system column? Will we have duplicated features then? Even if system tables don't use security_id columns, should the data type of *secon be oid instead of text? I think pg_security described in the wiki page is useful even if we only have object-level security. How about adding pg_security and changing the type of *secon to oid? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Itagaki Takahiro wrote: > KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: > >>>>> ==== Internal structures ==== >> http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog >> >> In SELinux model, massive number of objects shares a limited number of >> security context (e.g more than 100 tables may have a same one), this >> design (it stores "security label OID" within the tuple header) is well >> suitable for database objects. > > What plan do you have for system columns added by the patch > (datsecon, nspsecon, relsecon, etc) after we have securty_id > system column? Will we have duplicated features then? In my plan, these fields will be removed when we add security system column support. > Even if system tables don't use security_id columns, should the data type > of *secon be oid instead of text? I think pg_security described in the wiki > page is useful even if we only have object-level security. > How about adding pg_security and changing the type of *secon to oid? The reason why the current version stores security context in plain text is to minimize the scale of changeset as I have been pointed out many times for a long time. :( The pg_security catalog support requires about additional 1KL to the current patch. It seems to me it goes against to the previous suggestions. -- keep it smaller, and step-by-step enhancement BTW, If you don't have any complaints about new syntax in CREATE TABLE statement, I'll revise the patch soon. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
2009/11/24 KaiGai Kohei <kaigai@ak.jp.nec.com>: > BTW, I plan the following steps for the row-level security. > | * A facility to put "security label OID" within the tuple header. > | * System column support to print out the security context. > | (This system column shall be writable to relabel) > | * Pure-SQL row-level security checks, something like Oracle Private > | Database which allows user defined access control decision function. > | * SELinux aware row-level checks on the virtual private database stuff. > V It can be implemented as one of the decision making functions. I think we're getting ahead of ourselves talking about row-level security at this point, but FWIW I have a lot of concerns about how the previous version of this feature was designed. In particular, I think we should set up row-level security in a way that (1) allows it to be used for purposes other than SE-Linux and (2) allows row-filtering to take advantage of indices. If I have a table with a million rows, but only rights to see 100 of them, the system administrator should be able to define an index that will allow the 100 I can see to be fetched via a bitmap-index scan rather than a seq-scan with a probe for every row. ...Robert
KaiGai Kohei <kaigai@kaigai.gr.jp> wrote: > -- keep it smaller, and step-by-step enhancement I'd prefer "smaller concept" rather than "smaller patch". I think the philosophy of SE-PgSQL itself is ok, but there are some issues in the design and implementation: ==== No interaction with existing features ==== * SE-PgSQL injects security-context-based access control, but there are no interaction between it and the existing role-basedaccess control. * SE-PgSQL introduces concept of "security context", but there are no interaction between it and the existing context-relatedfeatures. (ex. pg_hba.conf and Application name patch) This is just an idea, but how about implementing context-based access control based on role-based ACL? We will not use security context directly for access control, but it forbid to use ROLEs in some conditions. An example of implementation image is: =# ALTER ROLE role VALID ON SECURITY CONTEXT '...' For example, this could allow us to modify rows only with a particular application, only from particular machine, and only in particular hour. Since we've already supported object- and column-level ACL, I think we can the same capability of the patch using security-context-to-role mapper. Or, is it not ideal in the policy of SELinux? ==== Postgres is not prepared to receive SE-PgSQL ==== We depend on superuser too heavily. As KaiGai-san mentioned, we use "if (superuser())" instead of ACL in some places. It is a bad manner. We should centralize access control in one module (maybe aclcheck.c), and SE-PgSQL should be implemented only in the module. If possible, it might be good for SE-PgSQL to replace all of the role-based access control layer in postgres because it is hard for users to maintain both Postgres ROLEs and SELinux settings consistently. Do we need pluggable ACL layer before accepting SE-PgSQL? ==== Need to reconsider row-level security control ==== Row-level security control is excluded from the patch, but we'd better also considering it at first. You mentioned as: > In SELinux model, massive number of objects shares a limited number of > security context (e.g more than 100 tables may have a same one) but I'm not sure what application do you suppose. For example, if we protect web application from SQL injection attacks, the password column for each row can be read only from the end user represented by the row. The number of security labels will be same as the number of end users (= rows). ==== Actual benefits of SE-PgSQL ==== SE-PgSQL will be committed step-by-step -- but could you explain which step can solve which problem in the real world? Imagine that SQL injections, measure for SOX Act, divulgation of personal information, .... They are security holes in terms of a whole application, but not a hole in terms of database, because database cannot always distinguish between legal and illegal data access (ex. correction of wrong data vs. rigging of benefits). Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Itagaki Takahiro wrote: > KaiGai Kohei <kaigai@kaigai.gr.jp> wrote: >> -- keep it smaller, and step-by-step enhancement > > I'd prefer "smaller concept" rather than "smaller patch". Its difference is unclear for me. In this CF, I separated most of separatable concepts to reduce size of the patch, as follows:- No access controls except for databases, schemas, tables and columns- No row-level accesscontrol granurality- No security OID and text translation- No access control decision cache Needless to say, these feature can be added later, step-by-step. But the core of SE-PgSQL is access control based on the SELinux policy. It is an atomic feature, so unseparatable. > ==== No interaction with existing features ==== > * SE-PgSQL injects security-context-based access control, but there are > no interaction between it and the existing role-based access control. If the interaction means restriction of available pairs between a certain database role and a certain security context of the client, it may be available as I followed on the next section. However, SELinux accept only security context as an identifiers of processes, files, tables and so on. If you mention to consider database role identifier in access control decision, it is not possible. > * SE-PgSQL introduces concept of "security context", but there are > no interaction between it and the existing context-related features. > (ex. pg_hba.conf and Application name patch) > > This is just an idea, but how about implementing context-based access > control based on role-based ACL? We will not use security context directly > for access control, but it forbid to use ROLEs in some conditions. > An example of implementation image is: > > =# ALTER ROLE role VALID ON SECURITY CONTEXT '...' > > For example, this could allow us to modify rows only with a particular > application, only from particular machine, and only in particular hour. > Since we've already supported object- and column-level ACL, I think > we can the same capability of the patch using security-context-to-role > mapper. Or, is it not ideal in the policy of SELinux? Basically, it is not bad idea to restrict available database roles by the security context of the client. However, we need to revise the concept a bit. Please remind its principle. SE-PgSQL applies all the its access controls according to the security policy of SELinux. SELinux defines all the access control rules as a relationship between a couple of security contexts. So, this idea can be rewritten as follows: 1. add a security context to pg_authid system column2. add db_role object class in the security policy (It needs discussionin the SELinux community)3. It checks db_role:{loginas} permission between the client and the security contextof the db_authid entry. For example, if the security policy allows "system_u:system_r:httpd_t:s0" (a typical web server) domain to login as a database role labeled as "system_u:object_r:web_role_t:s0", we can assign this context on a certain database role to be performs as web users. ALTER ROLE role SECURITY CONTEXT ( 'system_u:object_r:web_role_t:s0' ); Please note that I basically agree to implement this relationshipt, but it can be implemented as an incremental patch, as long as the core feature is merged first. > ==== Postgres is not prepared to receive SE-PgSQL ==== > We depend on superuser too heavily. As KaiGai-san mentioned, we use > "if (superuser())" instead of ACL in some places. It is a bad manner. > We should centralize access control in one module (maybe aclcheck.c), > and SE-PgSQL should be implemented only in the module. > > If possible, it might be good for SE-PgSQL to replace all of the > role-based access control layer in postgres because it is hard for > users to maintain both Postgres ROLEs and SELinux settings consistently. > Do we need pluggable ACL layer before accepting SE-PgSQL? I already tried this approach in the commit fest#2. But it was a big failure. :( I don't think it is a right direction. In addition, former cases (SELinux, X-window, ...) does not integrate its default access control stuff and the optional access controls. > ==== Need to reconsider row-level security control ==== > Row-level security control is excluded from the patch, but we'd better > also considering it at first. You mentioned as: > >> In SELinux model, massive number of objects shares a limited number of >> security context (e.g more than 100 tables may have a same one) > > but I'm not sure what application do you suppose. For example, > if we protect web application from SQL injection attacks, the > password column for each row can be read only from the end user > represented by the row. The number of security labels will be same > as the number of end users (= rows). I need to admit the current proposal is a "lite" version, so some of functionality may be lack. For example, see the page.24 of this slids: http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf It assigns a certain security context on web-applications for each virtual host. In this example, a web-application once labeled as "blue" can never access both of filesystem objects and database objects (such as tables) labeled as other colors. SELinux performs as a logical wall to separate individual domains. Nowadays, we can often see such a multi-tenant system. I'd like you to understand that I separated most of separatable features as a result of the previous discussions, such as row-level granurality, access control decision cache, translater between security OID and text and so on. > ==== Actual benefits of SE-PgSQL ==== > SE-PgSQL will be committed step-by-step -- but could you explain which step > can solve which problem in the real world? Imagine that SQL injections, > measure for SOX Act, divulgation of personal information, .... They are > security holes in terms of a whole application, but not a hole in terms of > database, because database cannot always distinguish between legal and > illegal data access (ex. correction of wrong data vs. rigging of benefits). Good question. The hardness to fix all the security holes in application is the original motivation of reference monitor model (it is a conceptual design in 80's security reserch. SELinux and other MAC system is on the genealogy). Please imagine the reason why SELinux applies its access control policy on the accesses to system resources via system-calls. If we have to fix all the application bugs, it looks like a endless-war. The number of strategic points to be checked are infinite in fact. However, all the application has to use system-calls to access system resources such as files, networks, etc. It means we can aquire any accesses without exceptions with hooks in operating system, even if violated accesses are not bugs in operating system. The operating system also cannot distinguish whether the given access is actually a licit one, or not. But it prevent violated access in the outline. For example, when a user tries to write a file, SELinux cannot know whether the contents is right or not. But if a "unclassified" user tries to write something on a "classified" file, SELinux will prevent this request independent from the correctness of the contents. Please note that SELinux/SE-PgSQL never deny existing access control model. They have their own purpose and whorth, we never deny it. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
On Thu, Nov 26, 2009 at 11:15:46AM +0900, Itagaki Takahiro wrote: > ==== No interaction with existing features ==== > * SE-PgSQL injects security-context-based access control, but there are > no interaction between it and the existing role-based access control. And there shouldn't be, I think. SE-PgSQL is MAC which means that what someone can access is configured elsewhere. This example is non-sensical: > =# ALTER ROLE role VALID ON SECURITY CONTEXT '...' When someone logs in they have a security context and what they can access is then decided. You can't reconfigure what someone has access to with anything within the DB (other than label changes), the SE-PgSQL rules are elsewhere. That's what "Mandatory" refers to. > but I'm not sure what application do you suppose. For example, > if we protect web application from SQL injection attacks, the > password column for each row can be read only from the end user > represented by the row. The number of security labels will be same > as the number of end users (= rows). This example is also strange: the program that needs to read the password need to be able to see all rows because by definition the user cannot be logged in yet. After you login there is no need to be able to read your own password. So column-access control is fine here. And even if there are lots of contexts, so what? Security is not free, but given SE-PgSQL is in use in the real world, clearly people think the tradeoffs are worth it. Finally, this is not about protection against SQL injection, it's protection against people in Sales reading data belonging to Finance. > ==== Actual benefits of SE-PgSQL ==== > SE-PgSQL will be committed step-by-step -- but could you explain which step > can solve which problem in the real world? Imagine that SQL injections, > measure for SOX Act, divulgation of personal information, .... They are > security holes in terms of a whole application, but not a hole in terms of > database, because database cannot always distinguish between legal and > illegal data access (ex. correction of wrong data vs. rigging of benefits). As far as I can tell, just about all the interesting cases are for row-level security. While MAC on tables and columns will be interesting, my guess the real uptake will be when row-level control is in. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
Itagaki Takahiro wrote: > KaiGai Kohei <kaigai@kaigai.gr.jp> wrote: >> -- keep it smaller, and step-by-step enhancement > > I'd prefer "smaller concept" rather than "smaller patch". For the last a few days, I've talked with Itagaki-san off list to make clear where is the point of his suggestion. In summary, it was similar approach with what I already proposed in the CF#2, but rejected. During the first commit-fest of v8.5 development cycle, Stephen Frost suggested to rework the default PG's access controls to host other optional security features, not only the default one. Then, I submitted a large patch titled as "Reworks for Access Controls", but it contained 3.5KL of changeset on the core routines, and 4KL of new codes into "src/backend/security/*" except for documentations and testcases. Then, this approach was rejected (not "returned with feedback") due to the scale and complexity. After the fest, we discussed the direction to implement SE-PgSQL. Basically, it needs to keep the changeset small, and the rest of features (such as row-level granurality, access control decision cache, ...) shoule be added step-by-step consistently, according to the suggestion in the v8.4 development cycle. Heikki Linnakangas also suggested we need developer documentation which introduces SE-PgSQL compliant permission checks and specification of security hooks, after the reworks are rejected. So, I boldly removed most of the features from SE-PgSQL except for its core functionalities, and added developer documentation (README) and widespread source code comments to introduce the implementations instead. In the result, the current proposal is near to naked one.- No access controls except for database, schema, table and column.-No row-level granularity in access controls.- No access control decision chache.- No security OID within HeapTupleHeader. I believe the current patch is designed according to the past suggestions. However, his suggestion seems to me backing to the rejected approach again. I've been torn between the past suggestions and his suggestion. So, I asked him to get off reviewing the patch, because of the deadlock in the development process. At the current moment, I'd like to respect suggestions in the past discussions more. Thanks for paying your efforts in spite of differences in opinions. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
KaiGai Kohei wrote: > In summary, it was similar approach with what I already proposed in the CF#2, > but rejected. > > During the first commit-fest of v8.5 development cycle, Stephen Frost suggested > to rework the default PG's access controls to host other optional security > features, not only the default one. > Then, I submitted a large patch titled as "Reworks for Access Controls", > but it contained 3.5KL of changeset on the core routines, and 4KL of new codes > into "src/backend/security/*" except for documentations and testcases. > Then, this approach was rejected (not "returned with feedback") due to the scale > and complexity. > > After the fest, we discussed the direction to implement SE-PgSQL. > Basically, it needs to keep the changeset small, and the rest of features (such > as row-level granurality, access control decision cache, ...) shoule be added > step-by-step consistently, according to the suggestion in the v8.4 development > cycle. Heikki Linnakangas also suggested we need developer documentation which > introduces SE-PgSQL compliant permission checks and specification of security > hooks, after the reworks are rejected. > > So, I boldly removed most of the features from SE-PgSQL except for its core > functionalities, and added developer documentation (README) and widespread > source code comments to introduce the implementations instead. > In the result, the current proposal is near to naked one. > - No access controls except for database, schema, table and column. > - No row-level granularity in access controls. > - No access control decision chache. > - No security OID within HeapTupleHeader. > > I believe the current patch is designed according to the past suggestions. Agreed. The patch is exactly what I was hoping to see: o only covers existing Postgres ACLso has both user and developer documentationo includes regression testso main codeimpact is minimal Now, if this is applied, we might then move forward with implementing SE-Linux specific features like mandatory access control (MAC) and row-level security. In terms of review, the patch is 13k lines, but most of that is documentation, se-linux-specific files, system catalog adjustments, and regression tests. Also, I attended KaiGai's talk in Tokyo where he explained that managing permission at the operating system level, the web server level (via .htaccess and htpasswd), and at the database level is confusing, and having a single permission system has benefits. The number of revisions and adjustments KaiGai has done since the original SE-PostgreSQL patch is amazing and certainly gives me confidence that he will be around to help in case there are any problems in the future. So, one big problem is that no one has agreed to review it, partly or probably because few developers understand the SE-Linux API, and many people who have used SE-Linux have been confused by it. I think I could review this if I could team up with someone to help me, ideally someone on instant message (IM) and perhaps using SE-Linux. I think the big question is whether this feature (mappming SE-Linux permissions to existing Postgres permissions) has an acceptable code impact. Of course we might be adding things later, but at this stage is this something we can apply? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote: > KaiGai Kohei wrote: > > In summary, it was similar approach with what I already proposed > > in the CF#2, but rejected. > > > > During the first commit-fest of v8.5 development cycle, Stephen > > Frost suggested to rework the default PG's access controls to host > > other optional security features, not only the default one. Then, > > I submitted a large patch titled as "Reworks for Access Controls", > > but it contained 3.5KL of changeset on the core routines, and 4KL > > of new codes into "src/backend/security/*" except for > > documentations and testcases. Then, this approach was rejected > > (not "returned with feedback") due to the scale and complexity. > > > > After the fest, we discussed the direction to implement SE-PgSQL. > > Basically, it needs to keep the changeset small, and the rest of > > features (such as row-level granurality, access control decision > > cache, ...) shoule be added step-by-step consistently, according > > to the suggestion in the v8.4 development cycle. Heikki > > Linnakangas also suggested we need developer documentation which > > introduces SE-PgSQL compliant permission checks and specification > > of security hooks, after the reworks are rejected. > > > > So, I boldly removed most of the features from SE-PgSQL except for its core > > functionalities, and added developer documentation (README) and widespread > > source code comments to introduce the implementations instead. > > In the result, the current proposal is near to naked one. > > - No access controls except for database, schema, table and column. > > - No row-level granularity in access controls. > > - No access control decision chache. > > - No security OID within HeapTupleHeader. > > > > I believe the current patch is designed according to the past suggestions. > > Agreed. The patch is exactly what I was hoping to see: > > o only covers existing Postgres ACLs > o has both user and developer documentation > o includes regression tests > o main code impact is minimal This patch addresses points 1-3 of Andrew Sullivan's post here: http://archives.postgresql.org/pgsql-hackers/2008-10/msg00388.php Left out is point 4, namely whether it's possible to map metadata access controls can do this completely, and if so, whether this patch implements such a mapping. This is totally separate from the really important question of whether SE-Linux has a future, and another about whether, if SE-Linux has a future, PostgreSQL needs to go there. All that aside, there is an excellent economic reason why a proprietary product might need to follow a dead-end technology, namely increasing shareholder value due to one or more large, long-term deals. PostgreSQL doesn't have this motive, although some of the proprietary forks may well. Can we see about Andrew Sullivan's point 4? Or is it more important to address the "do we want to" question first? Whatever order we take them in, we do need to address both. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Bruce Momjian wrote: > KaiGai Kohei wrote: >> In summary, it was similar approach with what I already proposed in the CF#2, >> but rejected. >> >> During the first commit-fest of v8.5 development cycle, Stephen Frost suggested >> to rework the default PG's access controls to host other optional security >> features, not only the default one. >> Then, I submitted a large patch titled as "Reworks for Access Controls", >> but it contained 3.5KL of changeset on the core routines, and 4KL of new codes >> into "src/backend/security/*" except for documentations and testcases. >> Then, this approach was rejected (not "returned with feedback") due to the scale >> and complexity. >> >> After the fest, we discussed the direction to implement SE-PgSQL. >> Basically, it needs to keep the changeset small, and the rest of features (such >> as row-level granurality, access control decision cache, ...) shoule be added >> step-by-step consistently, according to the suggestion in the v8.4 development >> cycle. Heikki Linnakangas also suggested we need developer documentation which >> introduces SE-PgSQL compliant permission checks and specification of security >> hooks, after the reworks are rejected. >> >> So, I boldly removed most of the features from SE-PgSQL except for its core >> functionalities, and added developer documentation (README) and widespread >> source code comments to introduce the implementations instead. >> In the result, the current proposal is near to naked one. >> - No access controls except for database, schema, table and column. >> - No row-level granularity in access controls. >> - No access control decision chache. >> - No security OID within HeapTupleHeader. >> >> I believe the current patch is designed according to the past suggestions. > > Agreed. The patch is exactly what I was hoping to see: > > o only covers existing Postgres ACLs > o has both user and developer documentation > o includes regression tests > o main code impact is minimal > > Now, if this is applied, we might then move forward with implementing > SE-Linux specific features like mandatory access control (MAC) and > row-level security. > > In terms of review, the patch is 13k lines, but most of that is > documentation, se-linux-specific files, system catalog adjustments, and > regression tests. > > Also, I attended KaiGai's talk in Tokyo where he explained that managing > permission at the operating system level, the web server level (via > .htaccess and htpasswd), and at the database level is confusing, and > having a single permission system has benefits. > > The number of revisions and adjustments KaiGai has done since the > original SE-PostgreSQL patch is amazing and certainly gives me > confidence that he will be around to help in case there are any problems > in the future. > > So, one big problem is that no one has agreed to review it, partly or > probably because few developers understand the SE-Linux API, and many > people who have used SE-Linux have been confused by it. > > I think I could review this if I could team up with someone to help me, > ideally someone on instant message (IM) and perhaps using SE-Linux. I think some of SELinux developers (including me) can help you to review the code. They are maintaining both of the kernel and libraries (APIs). I'll call for them to help reviewing. BTW, I can use skype messanger in my home, and IRC may be available in office. > I think the big question is whether this feature (mappming SE-Linux > permissions to existing Postgres permissions) has an acceptable code > impact. Of course we might be adding things later, but at this stage is > this something we can apply? It needs to deploy a set of hooks on the strategic points of the core PostgreSQL codes, and rest of steps (such as computing a default security context and making an access control decision) are done in the SE-PgSQL specific files. These hooks are designed not to prevent anything when SE-PgSQL is disabled. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
David Fetter wrote: > On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote: >> KaiGai Kohei wrote: >>> In summary, it was similar approach with what I already proposed >>> in the CF#2, but rejected. >>> >>> During the first commit-fest of v8.5 development cycle, Stephen >>> Frost suggested to rework the default PG's access controls to host >>> other optional security features, not only the default one. Then, >>> I submitted a large patch titled as "Reworks for Access Controls", >>> but it contained 3.5KL of changeset on the core routines, and 4KL >>> of new codes into "src/backend/security/*" except for >>> documentations and testcases. Then, this approach was rejected >>> (not "returned with feedback") due to the scale and complexity. >>> >>> After the fest, we discussed the direction to implement SE-PgSQL. >>> Basically, it needs to keep the changeset small, and the rest of >>> features (such as row-level granurality, access control decision >>> cache, ...) shoule be added step-by-step consistently, according >>> to the suggestion in the v8.4 development cycle. Heikki >>> Linnakangas also suggested we need developer documentation which >>> introduces SE-PgSQL compliant permission checks and specification >>> of security hooks, after the reworks are rejected. >>> >>> So, I boldly removed most of the features from SE-PgSQL except for its core >>> functionalities, and added developer documentation (README) and widespread >>> source code comments to introduce the implementations instead. >>> In the result, the current proposal is near to naked one. >>> - No access controls except for database, schema, table and column. >>> - No row-level granularity in access controls. >>> - No access control decision chache. >>> - No security OID within HeapTupleHeader. >>> >>> I believe the current patch is designed according to the past suggestions. >> Agreed. The patch is exactly what I was hoping to see: >> >> o only covers existing Postgres ACLs >> o has both user and developer documentation >> o includes regression tests >> o main code impact is minimal > > This patch addresses points 1-3 of Andrew Sullivan's post here: > http://archives.postgresql.org/pgsql-hackers/2008-10/msg00388.php > > Left out is point 4, namely whether it's possible to map metadata > access controls can do this completely, and if so, whether this patch > implements such a mapping. I'm not clear what means the metadata level access controls here. If you talk about permissions when we create/alter/drop a certain database obejct, the existing PG model also checks its permission. These operations are equivalent to modify metadata of database objects. And, SE-PgSQL also checks its permissions on modification of metadata. We can refer the metadata of the database object using SELECT on the system catalogs typically. In this case, we need row-level granularity because individual tuples mean metadata of the database object. So, we don't implement permission checks of references to metadata in this version. I introduced it on the README file as follows: | o getattr (not implemented yet) | | It is checked when a client read properties of database object. | | Typically, it is required on scanning database objects within system catalogs, | such as "SELECT * FROM pg_class". Because this check requires row-level access | control facilities, it is not implemented yet in this version. | | Note that no need to check this permission, unless fetched properties are | consumed internally without returning to clients. For example, catcache stuff | provides system internal stuff an easy way to refer system catalog. It is used | to implement backend routines, and fetched properties are not returned to the | client in normal way, so we don't check this permission here. > This is totally separate from the really important question of whether > SE-Linux has a future, and another about whether, if SE-Linux has a > future, PostgreSQL needs to go there. > > All that aside, there is an excellent economic reason why a > proprietary product might need to follow a dead-end technology, namely > increasing shareholder value due to one or more large, long-term > deals. > > PostgreSQL doesn't have this motive, although some of the proprietary > forks may well. > > Can we see about Andrew Sullivan's point 4? Or is it more important > to address the "do we want to" question first? > > Whatever order we take them in, we do need to address both. As Bruce mentioned, our big motivation is improvement of web-system's security. However, most of security burden tend to concentrate to the quality of web applications, because it tends to share privileges on OS/DB for all the user's requests. In other word, correctness of the system depends on whether every applications are bug-free, or not. But we know it is difficult to keep them bug-free. :( Nowadays, we can often see a web server which host multiple tenants in a single daemon. For example, one is assigned to the division-X, and the other is assigned to the division-Y, ... In this case, it is worthful to prevent a (buggy) web-application to access resources labeled as an other division independent from the way to store information assets (either filesystem or database). Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
> This is totally separate from the really important question of whether > SE-Linux has a future, and another about whether, if SE-Linux has a > future, PostgreSQL needs to go there. If the hooks are generic enough that the could potentially be adapted to other security frameworks, yes. The need to have cohesive centralized systems permissions management hasn't gone away, whatever anyone thinks of the SE-linux implementation. That's why I was hoping to have the TrustedSolaris folks working on this, but we've pretty much lost access to them. --Josh Berkus
On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: > This is totally separate from the really important question of whether > SE-Linux has a future, and another about whether, if SE-Linux has a > future, PostgreSQL needs to go there. Why would we think that it doesn't? Maybe I haven't been following as much as I should but as I understand it, SE-Linux is pretty much the defacto policy framework for Linux. Has that changed? Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander
"Joshua D. Drake" <jd@commandprompt.com> writes: > On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: >> This is totally separate from the really important question of whether >> SE-Linux has a future, and another about whether, if SE-Linux has a >> future, PostgreSQL needs to go there. > Why would we think that it doesn't? Have you noticed anyone except Red Hat taking it seriously? I work for Red Hat and have drunk a reasonable amount of the SELinux koolaid, but I can't help observing that it's had very limited uptake outside Red Hat. It's not clear that there are many people who find it a cost-effective solution to their problems. As for the number of people prepared to write custom policy for it --- which would be required to use it effectively for almost any PG application --- I could probably hold a house party for all of them and not break a sweat serving drinks. regards, tom lane
On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: > >> This is totally separate from the really important question of whether > >> SE-Linux has a future, and another about whether, if SE-Linux has a > >> future, PostgreSQL needs to go there. > > > Why would we think that it doesn't? > > Have you noticed anyone except Red Hat taking it seriously? I just did a little research and it appears the other two big names in this world (Novel and Ubuntu) are using something called App Armor. > > I work for Red Hat and have drunk a reasonable amount of the SELinux > koolaid, but I can't help observing that it's had very limited uptake > outside Red Hat. It's not clear that there are many people who find > it a cost-effective solution to their problems. As for the number of > people prepared to write custom policy for it --- which would be > required to use it effectively for almost any PG application --- > I could probably hold a house party for all of them and not break a > sweat serving drinks. Your argument certainly holds weight. The only thing I would suggest outside of that is... it may only be Red Hat but that is a darn big hat in Linux enterprise space. Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander
Josh Berkus wrote: >> This is totally separate from the really important question of whether >> SE-Linux has a future, and another about whether, if SE-Linux has a >> future, PostgreSQL needs to go there. > > If the hooks are generic enough that the could potentially be adapted to > other security frameworks, yes. The need to have cohesive centralized > systems permissions management hasn't gone away, whatever anyone thinks > of the SE-linux implementation. In history, most of MAC feature have a common origin that was a research in US military, so they have similar comcepts (such as security label, a centralized security policy, ...) commonly. It was the reason why I proposed PGACE framework for generic MAC features at the earlier suggestion in v8.4 development cycle. (Note that it had gone to separate unnecessary complexity now.) As long as user can select his option, basically, I think it is preferable to support multiple security models, not only SELinux. As Linux (and also X-window) allows to host multiple MAC feature on a set of common hooks, it is not an incorrect approach. (Note that DAC has different origin from MAC, so we shall need a great efforts to integrate them. My trial in CF#2 shows this failure.) > That's why I was hoping to have the TrustedSolaris folks working on > this, but we've pretty much lost access to them. We can understand the current circumstance at Sun... Thank, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: >>> This is totally separate from the really important question of whether >>> SE-Linux has a future, and another about whether, if SE-Linux has a >>> future, PostgreSQL needs to go there. > >> Why would we think that it doesn't? > > Have you noticed anyone except Red Hat taking it seriously? > > I work for Red Hat and have drunk a reasonable amount of the SELinux > koolaid, but I can't help observing that it's had very limited uptake > outside Red Hat. It's not clear that there are many people who find > it a cost-effective solution to their problems. As for the number of > people prepared to write custom policy for it --- which would be > required to use it effectively for almost any PG application --- > I could probably hold a house party for all of them and not break a > sweat serving drinks. If you concerned about SELinux support may not drive explosive growth in the number of PostgreSQL users, it is correct. It focuses on the people who concerned about system security including RDBMS. It is indeed a niche. All the people does not store their classified information within databases. But, it is also a fact there are certain demands, not limited to existing SELinux and PostgreSQL users. ("Synergetic effect" is a correct English expression?) Now PostgreSQL has various kind of optional features. I think these are not always valuable for all the people, but it is valuable for users who enabled the features. SELinux support is not a special case. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Joshua D. Drake wrote: > On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: >> "Joshua D. Drake" <jd@commandprompt.com> writes: >>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: >>>> This is totally separate from the really important question of whether >>>> SE-Linux has a future, and another about whether, if SE-Linux has a >>>> future, PostgreSQL needs to go there. >>> Why would we think that it doesn't? >> Have you noticed anyone except Red Hat taking it seriously? > > I just did a little research and it appears the other two big names in > this world (Novel and Ubuntu) are using something called App Armor. As far as I can see, SUSE, Ubuntu and Debian provide SELinux option. But they are more conservative than RedHat/Fedora, because it is not enabled in the default installation. I don't think it is unpreferable decision. Users can choose the option by themself according to requirements in the system. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: > This is totally separate from the really important question of whether > SE-Linux has a future, and another about whether, if SE-Linux has a > future, PostgreSQL needs to go there. Why would we think that it doesn't? Maybe I haven't been following as much as I should but as I understand it, SE-Linux is pretty much the defacto policy framework for Linux. Has that changed? Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander
KaiGai Kohei wrote: === Joshua D. Drake wrote: > On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: >> "Joshua D. Drake" <jd@commandprompt.com> writes: >>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: >>>> This is totally separate from the really important question of whether >>>> SE-Linux has a future, and another about whether, if SE-Linux has a >>>> future, PostgreSQL needs to go there. >>> Why would we think that it doesn't? >> Have you noticed anyone except Red Hat taking it seriously? > > I just did a little research and it appears the other two big names in > this world (Novel and Ubuntu) are using something called App Armor. As far as I can see, SUSE, Ubuntu and Debian provide SELinux option. But they are more conservative than RedHat/Fedora, because it is not enabled in the default installation. I don't think it is unpreferable decision. Users can choose the option by themself according to requirements in the system. === How much of the work currently at hand might be applicable to other security models ? Would this be useful groundwork foranyone who wanted to implement other frameworks in terms of hooks, cleanup of existing code, etc. ? Greg W. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Greg Williamson wrote: > As far as I can see, SUSE, Ubuntu and Debian provide SELinux > option. But they are more conservative than RedHat/Fedora, > because it is not enabled in the default installation. > > I don't think it is unpreferable decision. Users can choose the > option by themself according to requirements in the system. > > === > > How much of the work currently at hand might be applicable to > other security models ? Would this be useful groundwork for > anyone who wanted to implement other frameworks in terms of > hooks, cleanup of existing code, etc. ? Yes, it would offer clear groundwork for that, and could be easily extended. We didn't implement such a system at this stage because it would have added additional code, but once there is demand the system could be easily extended. -- 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 <kaigai@ak.jp.nec.com> writes: > Joshua D. Drake wrote: >> I just did a little research and it appears the other two big names in >> this world (Novel and Ubuntu) are using something called App Armor. > As far as I can see, SUSE, Ubuntu and Debian provide SELinux option. > But they are more conservative than RedHat/Fedora, because it is not > enabled in the default installation. > I don't think it is unpreferable decision. Users can choose the option > by themself according to requirements in the system. Based on Red Hat's experience, it is a safe bet that not enabling SELinux by default guarantees the feature will remain useless to the average user. As was pointed out upthread (and I can confirm from personal experience), it's taken *years* for Red Hat to develop the security policy to a point where it's even marginally usable by anyone who isn't willing to put up with a great deal of annoyance because they have an extreme need. And that's despite having a well-defined, not too ambitious goal for what it is they are trying to secure: for the most part, RH's default policy doesn't try to lock down anything except network-accessible services. SUSE and the rest of them may "have the feature", but they don't have it in a usable form, and won't ever have it without a much larger effort than they're making. Even if we were to accept the SEPostgres patches lock stock and barrel tomorrow, I don't foresee that it will ever get to the point of being useful except to an extremely small group of users who are driven by extreme need. Nobody else is going to have the motivation needed to develop custom security policies, and there simply isn't any chance of anyone developing any generally useful default policy. Red Hat's policy has been trying to cope with cases like "which directories should Apache be allowed to read, *given that it's running a Red-Hat-standard configuration*?" That's far more circumscribed than any useful database policy would be, because database applications aren't nearly that standardized. If SEPostgres were a small patch that wouldn't need much ongoing effort, I might think it's reasonable to adopt it for the benefit of only a small group of users. However, it's not small, it's not simple, and it will not be low-maintenance. I'm afraid the cost-benefit ratio from the project's perspective is just not reasonable. regards, tom lane
On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: > >> This is totally separate from the really important question of whether > >> SE-Linux has a future, and another about whether, if SE-Linux has a > >> future, PostgreSQL needs to go there. > > > Why would we think that it doesn't? > > Have you noticed anyone except Red Hat taking it seriously? I just did a little research and it appears the other two big names in this world (Novel and Ubuntu) are using something called App Armor. > > I work for Red Hat and have drunk a reasonable amount of the SELinux > koolaid, but I can't help observing that it's had very limited uptake > outside Red Hat. It's not clear that there are many people who find > it a cost-effective solution to their problems. As for the number of > people prepared to write custom policy for it --- which would be > required to use it effectively for almost any PG application --- > I could probably hold a house party for all of them and not break a > sweat serving drinks. Your argument certainly holds weight. The only thing I would suggest outside of that is... it may only be Red Hat but that is a darn big hat in Linux enterprise space. Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander
Tom Lane wrote: > Even if we were to accept the SEPostgres patches lock stock and barrel > tomorrow, I don't foresee that it will ever get to the point of being > useful except to an extremely small group of users who are driven by > extreme need. Nobody else is going to have the motivation needed to > develop custom security policies, and there simply isn't any chance > of anyone developing any generally useful default policy. Red Hat's > policy has been trying to cope with cases like "which directories should > Apache be allowed to read, *given that it's running a Red-Hat-standard > configuration*?" That's far more circumscribed than any useful database > policy would be, because database applications aren't nearly that > standardized. Basically, it is the last option to write custom policy modules for users, and it is not a recommendable for average users. The default security policy contains various kind of pre-defined security contexts, and it allows administrators to assign them dirs/files according to their purpose. In most cases, user can complete SELinux setups with customizations nowadays, not writing their custom policy modules. For example, the default security policy intend to web contents are stored in "/var/www/html" labeled as "httpd_sys_content_t" which allows web-servers read-only access to the files. If we want to store web contents in "/opt/html", all we have to do is: $ chcon -R system_u:object_r:httpd_sys_content_t:s0 /opt/html It changes the security context of the /opt/html and files under the directory. It performs as web-contents from perspective of SELinux. We can apply similar configuration on database objects. For example, we want to have a read-only table from confined processes, all we have to do is: CREATE TABLE read_only_tbl ( x int, y text ) SECURITY CONTEXT ('system_u:object_r:sepgsql_ro_table_t:s0'); The "sepgsql_ro_table_t" is a type which allows confined processes only SELECT contents from the table, and it is provided by the default security policy. We don't need to write any custom security policy in typical use cases. SELinux has been integrated into RedHat/Fedora since FC2. It had a lot of matters in the early phase. For example, the default security policy was troubled, user needed to modify the security policy and rebuild whole of the policy, here were no custmization parameters, ... However, these matters have been resolved for the recent years. It seems to me your complaints based on the legacy SELinux. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
[ Updated subject ] We have been discussing support for SE-Linux for over a year and now have a minimal patch submitted that maps SE-Linux permissions to existing Postgres permissions: patch: http://momjian.us/tmp/sepgsql-01-lite-8.5devel-r2451.patchemail: http://archives.postgresql.org/message-id/4B13856F.1090803@ak.jp.nec.com That patch is the minimum required to support SE-Linux in some form. The majority of the patch is documentation, regression tests, small catalog additions, and SE-Linux-specific C files. It does add hooks into the existing access permission functions. There is no support for row-level permissions or mandatory access control (MAC). These were removed to minimize code impact and might be added later. Tom's email below highlights the lack of mainstream usage of SE-Linux features, though it is supported by most Linux distributions. Tom's opinion is adding support for a minimal set of SE-Linux security isn't worth the code impact. David Fetter felt SE-Linux was mostly a marketing/sales feature, rather than something of general usefulness. Others feel SE-Linux is valid for limited use cases. I understand SE-Linux to be like Kerberos --- Kerberos provides single-signon site authentication, while SE-Linux provides single-signon site security credentials. While Kerberos is not useful for everyone, SE-Linux similarly has limited adoption. Kerberos has proven to be a key technology for sites that need it, and SE-Linux might prove to be similar. If we decide not to support SE-Linux, it is unlikely we will be adding support for any other external security systems because SE-Linux has the widest adoption. I think the big question is whether we are ready to extend Postgres to support additional security infrastructures. --------------------------------------------------------------------------- Tom Lane wrote: > KaiGai Kohei <kaigai@ak.jp.nec.com> writes: > > Joshua D. Drake wrote: > >> I just did a little research and it appears the other two big names in > >> this world (Novel and Ubuntu) are using something called App Armor. > > > As far as I can see, SUSE, Ubuntu and Debian provide SELinux option. > > But they are more conservative than RedHat/Fedora, because it is not > > enabled in the default installation. > > > I don't think it is unpreferable decision. Users can choose the option > > by themself according to requirements in the system. > > Based on Red Hat's experience, it is a safe bet that not enabling > SELinux by default guarantees the feature will remain useless to the > average user. As was pointed out upthread (and I can confirm from > personal experience), it's taken *years* for Red Hat to develop the > security policy to a point where it's even marginally usable by anyone > who isn't willing to put up with a great deal of annoyance because they > have an extreme need. And that's despite having a well-defined, not too > ambitious goal for what it is they are trying to secure: for the most > part, RH's default policy doesn't try to lock down anything except > network-accessible services. SUSE and the rest of them may "have the > feature", but they don't have it in a usable form, and won't ever have > it without a much larger effort than they're making. > > Even if we were to accept the SEPostgres patches lock stock and barrel > tomorrow, I don't foresee that it will ever get to the point of being > useful except to an extremely small group of users who are driven by > extreme need. Nobody else is going to have the motivation needed to > develop custom security policies, and there simply isn't any chance > of anyone developing any generally useful default policy. Red Hat's > policy has been trying to cope with cases like "which directories should > Apache be allowed to read, *given that it's running a Red-Hat-standard > configuration*?" That's far more circumscribed than any useful database > policy would be, because database applications aren't nearly that > standardized. > > If SEPostgres were a small patch that wouldn't need much ongoing effort, > I might think it's reasonable to adopt it for the benefit of only a small > group of users. However, it's not small, it's not simple, and it will > not be low-maintenance. I'm afraid the cost-benefit ratio from the > project's perspective is just not reasonable. > > regards, tom lane -- 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, > If we decide not to support SE-Linux, it is unlikely we will be adding > support for any other external security systems because SE-Linux has the > widest adoption. > > I think the big question is whether we are ready to extend Postgres to > support additional security infrastructures. PostgreSQL is the most security-conscious of the OSS databases, and is widely used by certain groups (security software, military, credit card processing) precisely because of this reputation. These folks, while unlikely to speak up on -hackers, are interested in new/further security features; when I was at the Pentagon 2 years ago several people there from HS were quite interested in SE-Postgres specifically. Further, I've been mentioning SE-Postgres in my "DB security talk" for the last 18 months and I *always* get a question about it. So while there might not be vocal proponents for innovative/hard-core security frameworks on this list currently, I think it will gain us some new users. Maybe more than we expect. When GIS was introduced to this list ten years ago it was criticized as a marginal feature and huge and intrusive. But today it's probably 40% of our user base, and growing far more rapidly than anything else with Postgres. Maybe SE will be more like Rules than like GIS in the long run, but there's no way for us to know that today. --Josh Berkus
Josh Berkus <josh@agliodbs.com> writes: > When GIS was introduced to this list ten years ago it was criticized as > a marginal feature and huge and intrusive. But today it's probably 40% > of our user base, and growing far more rapidly than anything else with > Postgres. Maybe SE will be more like Rules than like GIS in the long > run, but there's no way for us to know that today. What we do know is that GIS could be, and was, successfully developed outside core Postgres. It didn't need to suck away a major portion of the effort of the core developers. So it's not a very good analogy. In the end this is a debate about what the community should do with its finite development resources. Maybe, if we build this thing, they will come and we'll get so much additional contribution that it'll be a win all around. But somehow, alleged users who won't even decloak enough to tell us they want it don't seem like likely candidates for becoming major contributors. In words of one syllable: I do not care at all whether the NSA would use Postgres, if they're not willing to come and help us build it. If we tried to build it without their input, we'd probably not produce what they want anyway. regards, tom lane
On Wed, Dec 2, 2009 at 3:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Red Hat's > policy has been trying to cope with cases like "which directories should > Apache be allowed to read, *given that it's running a Red-Hat-standard > configuration*?" That's far more circumscribed than any useful database > policy would be, because database applications aren't nearly that > standardized. Actually that does sound useful for Redhat packages which themselves use database. So for example if I install my Redhat spam filter it should be able to automatically run createdb and load its schema and start using postgres as a backing store. Currently I think a lot of packages use sqlite by default just because manual intervention is required to set up postgres. So I'm unclear what advantage this has for Redhat and sysadmins over just setting up the database directly but then I'm unclear what the advantage is for SELinux in the first place so I'm probably just not in the target audience for it. But this seems like it would be directly analogous. I suppose an admin would be able to delegate more control to a new admin -- greg
Josh Berkus wrote: > Bruce, > >> If we decide not to support SE-Linux, it is unlikely we will be adding >> support for any other external security systems because SE-Linux has the >> widest adoption. >> >> I think the big question is whether we are ready to extend Postgres to >> support additional security infrastructures. > > PostgreSQL is the most security-conscious of the OSS databases, and is > widely used by certain groups (security software, military, credit card > processing) precisely because of this reputation. These folks, while > unlikely to speak up on -hackers, are interested in new/further security > features; when I was at the Pentagon 2 years ago several people there > from HS were quite interested in SE-Postgres specifically. Further, > I've been mentioning SE-Postgres in my "DB security talk" for the last > 18 months and I *always* get a question about it. > > So while there might not be vocal proponents for innovative/hard-core > security frameworks on this list currently, I think it will gain us some > new users. Maybe more than we expect. Good, I also have gotten many voices, questions and requirements from the viewpoints of enterprise users who make plans to launch their SaaS system typically. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: >> When GIS was introduced to this list ten years ago it was criticized as >> a marginal feature and huge and intrusive. But today it's probably 40% >> of our user base, and growing far more rapidly than anything else with >> Postgres. Maybe SE will be more like Rules than like GIS in the long >> run, but there's no way for us to know that today. > > What we do know is that GIS could be, and was, successfully developed > outside core Postgres. It didn't need to suck away a major portion of > the effort of the core developers. So it's not a very good analogy. > > In the end this is a debate about what the community should do with its > finite development resources. Maybe, if we build this thing, they will > come and we'll get so much additional contribution that it'll be a win > all around. But somehow, alleged users who won't even decloak enough > to tell us they want it don't seem like likely candidates for becoming > major contributors. > > In words of one syllable: I do not care at all whether the NSA would use > Postgres, if they're not willing to come and help us build it. If we > tried to build it without their input, we'd probably not produce what > they want anyway. I don't know any reputations of NSA in US, except for Hollywood often makes them baddie in movies. However, it is the fact SELinux is already an open source software supported by people and corporations in multiple nations including former communist nations, not only USA and its allied nations. Needless to say, NEC is also a supporter to develop and maintain SE-PgSQL feature. We believe it is a necessity feature to construct secure platform for SaaS/Cloud computing, so my corporation has funded to develop SE-PgSQL for more than two years. As I noted before, if you worried about I escape anyware, it is quite incorrect. Now I've been working to develop and integrate SE-PgSQL in full-time. We can also say SELinux community provides a development resource to other OSS communities. For example, the recent version of Xorg has SELinux support in userspace, such as SE-PgSQL, by the developer who originally worked in SELinux community. SE-PgSQL is a similar case. Anyway, I don't think we should build barrier between communities. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
KaiGai Kohei wrote:. > Needless to say, NEC is also a supporter to develop and maintain > SE-PgSQL feature. We believe it is a necessity feature to construct > secure platform for SaaS/Cloud computing, so my corporation has funded > to develop SE-PgSQL for more than two years. > > As I noted before, if you worried about I escape anyware, it is quite > incorrect. Now I've been working to develop and integrate SE-PgSQL in > full-time. > > We can also say SELinux community provides a development resource to > other OSS communities. For example, the recent version of Xorg has > SELinux support in userspace, such as SE-PgSQL, by the developer who > originally worked in SELinux community. SE-PgSQL is a similar case. > Anyway, I don't think we should build barrier between communities. > > > I think you have been remarkably good about our caution in accepting this. You certainly have my admiration for your patience. What would probably help us a lot would be to know some names of large users who want and will support this. NEC's name is a good start, but if a few other enterprise users spoke up it would help to make the decision a lot easier. My own experience with SE-Linux has been fairly unfortunate - I have tripped over it too many times and years ago adopted a practice of turning it off whenever I could. I suspect many people have similar war stories, and there will thus probably be quite some resistance to a feature I accept could well be of significant use to some classes of users. cheers andrew
KaiGai Kohei wrote: > Needless to say, NEC is also a supporter to develop and maintain > SE-PgSQL feature. We believe it is a necessity feature to construct > secure platform for SaaS/Cloud computing, so my corporation has funded > to develop SE-PgSQL for more than two years. Rather than "needless to say", I think this is worth elaborating on. Knowing how companies like NEC and their customers see SELinux and SE-PgSQL help their database projects would probably be one of the most compelling stories for getting broader support for the feature. Before googling "nec software" after seeing you mention this, I knew very little about NEC's software business. I can read some about NEC's software/database business for NEC North America's[1] and NEC Global Services[2] but imagine globally there's even more to it than that. Understanding how SE-PgSQL (and presumably SE-Linux) helps build a better SaaS/Cloud computing platform would probably help many people support this feature more. The cloud computing platforms I see more are ones that isolate a user's data either at a higher application layer (like salesforce) or a lower virtual machine layer (like amazon's elastic cloud). Is a vision of SE-PgSQL to help cloud computing companies sell customers access to a single underlying postgres instance, and share selected data between each other at a row level? Just curious. [1] http://www.necam.com/EntSw/ [2] http://www.necgs.com/partners.php
Joshua D. Drake wrote: > On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: >> "Joshua D. Drake" <jd@commandprompt.com> writes: >>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: >>>> This is totally separate from the really important question of whether >>>> SE-Linux has a future, and another about whether, if SE-Linux has a >>>> future, PostgreSQL needs to go there. >>> Why would we think that it doesn't? >> Have you noticed anyone except Red Hat taking it seriously? > > I just did a little research and it appears the other two big names in > this world (Novel and Ubuntu) are using something called App Armor. How much of SE-PgSQL would also complement the App Armor framework? Also, yet another MAC system called Tomoyo from NTT was merged into the linux kernel earlier this year. Is SE-PgSQL orthogonal and/or complimentary to all of those? Since I see MAC features continuing to be added to operating systems, I can certainly imagine they're important to some customers.
Greg Stark wrote: > So I'm unclear what advantage this has for Redhat and sysadmins over > just setting up the database directly but then I'm unclear what the > advantage is for SELinux in the first place so I'm probably just not > in the target audience for it. But this seems like it would be > directly analogous. I suppose an admin would be able to delegate more > control to a new admin We (security engineers) consider to coordinate access controls on whole of the system, not only database, although it might be an irritating wordage for pgsql-hackers. Needless to say, database is one of the most significant software components nowadays, but not all. From the perspective of security administration, we want to restrict user's privileges using a centralized basis, called security policy. The basis needs to be independent from structures of a certain subsystem, such as OS or DBMS. SELinux is well suitable for the requirements in Linux. Note that SELinux is implemented as a feature of OS in fact, but it makes its access control decision based on only a couple of security contexts which is a class-independent identifier. (It is called "reference monitor" in security region.) It is not a good idea to invent an another framework again for whole of the system security, because many of userspace applications already support SELinux features. It also means stuff to manage security context of resources, not only applying additional access controls based on SELinux policy like SE-PgSQL. For example, "ls -Z" shows security context of files, "mv" keeps security context of files, even if user tries to move a file across filesystems, "tar --selinux" support backup/restore security context of the files, ... There are various kind of options, however, SELinux provides most widespread support on various kind of software components. If we would be Oracle, we may be able to provide whole of the software components. But it is not right way in OSS community. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Ron Mayer wrote: > KaiGai Kohei wrote: >> Needless to say, NEC is also a supporter to develop and maintain >> SE-PgSQL feature. We believe it is a necessity feature to construct >> secure platform for SaaS/Cloud computing, so my corporation has funded >> to develop SE-PgSQL for more than two years. > > Rather than "needless to say", I think this is worth elaborating on. > > Knowing how companies like NEC and their customers see SELinux and > SE-PgSQL help their database projects would probably be one of the > most compelling stories for getting broader support for the feature. > > Before googling "nec software" after seeing you mention > this, I knew very little about NEC's software business. > I can read some about NEC's software/database business for > NEC North America's[1] and NEC Global Services[2] but imagine > globally there's even more to it than that. I'm talking about our future business, not existing one. Anyway, what is important here is that out corporation makes a decision to contribute to develop and maintain an innovative OSS project rather than what our business works well. > Understanding how SE-PgSQL (and presumably SE-Linux) helps > build a better SaaS/Cloud computing platform would probably > help many people support this feature more. The cloud computing > platforms I see more are ones that isolate a user's data either > at a higher application layer (like salesforce) or a lower > virtual machine layer (like amazon's elastic cloud). Is a > vision of SE-PgSQL to help cloud computing companies sell > customers access to a single underlying postgres instance, > and share selected data between each other at a row level? > Just curious. Basically, note than we have no magic-bullets in security region. Any approach has its merits and demerits. It depends on users what should be emphasized. If we tries to separate user's information assets in the application level (like salesforce), the code to be checked and bug-free are much larger than a case when we enforce accesses in OS/RDBMS. It shall make development cost to increase. If we tries to separate user's information assets in the virtual machine layer (like amazon), the worker-hour to maintain each virtual machines larger than a case when we enforce accesses in OS/RDBMS layer. It shall make maintenance cost to increase. If we tries to separate user's information assets in the OS/RDBMS layer, the code to be checked and bug-free are less than application level checks, and all administrator need to do is manage a limited number of instances. The granularity of access controls is not a primary matter. We can separate user's information assets in table level, not only row level. In addition, we cat set up a part of shared tables, unlike virtual machine approach. I don't mean this approach it a magic-bullets, but it can be an option for security-conscious users. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Ron Mayer wrote: > Joshua D. Drake wrote: >> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: >>> "Joshua D. Drake" <jd@commandprompt.com> writes: >>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: >>>>> This is totally separate from the really important question of whether >>>>> SE-Linux has a future, and another about whether, if SE-Linux has a >>>>> future, PostgreSQL needs to go there. >>>> Why would we think that it doesn't? >>> Have you noticed anyone except Red Hat taking it seriously? >> I just did a little research and it appears the other two big names in >> this world (Novel and Ubuntu) are using something called App Armor. > > How much of SE-PgSQL would also complement the App Armor framework? > > Also, yet another MAC system called Tomoyo from NTT was merged into > the linux kernel earlier this year. > > Is SE-PgSQL orthogonal and/or complimentary to all of those? > > Since I see MAC features continuing to be added to operating > systems, I can certainly imagine they're important to some > customers. Yes, nowadays, Linux has three MAC options: Linux, Smack and Tomoyo. And AppArmor is now under discussion to merge it. *In the current state*, our security hooks invoke SE-PgSQL routines directly, unlike LSM framework in Linux, because it is the first option for us, and no need to support multiple options now. (It will simply increase the size of changeset in this stage.) However, when the second option comes in, we can easily enhance the security hooks to support multiple MAC framework. The Smack also needs security label. It will be able to share facilities to manage security context with SE-PgSQL. I've often talked with developers of TOMOYO Linux. They currently give higher priority to upstream all their functionalities into Linux. But it also may be a valueable theme for them. At least, I don't think it requires much different hook points more than SELinux support. AppArmor's access control model is similar to TOMOYO. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Andrew Dunstan wrote: > I think you have been remarkably good about our caution in accepting > this. You certainly have my admiration for your patience. Agreed. > What would probably help us a lot would be to know some names of large > users who want and will support this. NEC's name is a good start, but if > a few other enterprise users spoke up it would help to make the decision > a lot easier. I think the open questions we have now are: o Is SE-Linux appropriate technology for Postgres?o Does SE-Linux have a sufficient user base or potential user baseto justify the additional code?o Can the code be maintained? And we have some partial answers. SE-Linux seems like the most popular of the security frameworks. There are a number of identified potential users, though we are looking to hear about more of them. Third, KaiGai is being paid by NEC to do this work and has shown to be extraordinarily dedicated to this feature. He has also offered to get other SE-Linux people involved in any patch review. I think the PostGIS example mentioned earlier is a good one. We did make some minor adjustments years ago to make things easier for them, but we had the luxury of having PostGIS be able to be developed outside of our main tree. I think with the current posted patch we have some of that benefit in that most of the code is in SE-Linux-specific directories, but the code outside those directories does have to be maintained. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> In words of one syllable: I do not care at all whether the NSA would use > Postgres, if they're not willing to come and help us build it. There's several 2-syllable words there. ;-) If we > tried to build it without their input, we'd probably not produce what > they want anyway. Yeah, the *complete* lack of input/help from the security community aside from the occasional "SE Linux good" posts we've gotten is troubling. We could end up with a SQL-J. Kaigai, you've said that you could get SELinux folks involved in the patch review. I think it's past time that they were; please solicit them. --Josh Berkus
On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> In words of one syllable: I do not care at all whether the NSA would use >> Postgres, if they're not willing to come and help us build it. > > There's several 2-syllable words there. ;-) > > If we >> tried to build it without their input, we'd probably not produce what >> they want anyway. > > Yeah, the *complete* lack of input/help from the security community > aside from the occasional "SE Linux good" posts we've gotten is > troubling. We could end up with a SQL-J. > > Kaigai, you've said that you could get SELinux folks involved in the > patch review. I think it's past time that they were; please solicit them. Actually, we tried that already, in a previous iteration of this discussion. Someone actually materialized and commented on a few things. The problem, as I remember it, was that they didn't know much about PostgreSQL, so we didn't get very far with it. Unfortunately, I can't find the relevant email thread at the moment. In fact, we've tried about everything with these patches. Tom reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed them, Stephen Frost reviewed them, Heikki took at least a brief look at them, and I think there were a few other people, too. The first person who I can recall being relatively happy with any version of this patch was Stephen Frost, commenting on the access control framework that we suggested KaiGai try to separate from the main body of the patch to break it into more managable chunks. That patch was summarily rejected by Tom for what I believe were valid reasons. In other words, in 18 months of trying we've yet to see something that is close to being committable. Contrast that with Hot Standby, which Heikki made a real shot at committing during the first CommitFest to which it was submitted. I think David Fetter summarized it pretty well here - the rest of the thread is worth reading, too. http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php I think the only chance of this ever getting committed is if a committer volunteers to take ownership of it, similar to what Heikki has done for Hot Standby and Streaming Replication. Right now, we don't have any volunteers, and even if Tom or Heikki were interested, I suspect it would occupy their entire attention for several CommitFests just as HS and SR have done for Heikki. I suspect the amount of work for SE-PostgreSQL might even be larger than for HS. If we DON'T have a committer who is willing to own this, then I don't think there's a choice other than giving up. ...Robert
Robert Haas wrote: > Actually, we tried that already, in a previous iteration of this > discussion. Someone actually materialized and commented on a few > things. The problem, as I remember it, was that they didn't know much > about PostgreSQL, so we didn't get very far with it. Unfortunately, I > can't find the relevant email thread at the moment. > > In fact, we've tried about everything with these patches. Tom > reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed > them, Stephen Frost reviewed them, Heikki took at least a brief look > at them, and I think there were a few other people, too. The first > person who I can recall being relatively happy with any version of > this patch was Stephen Frost, commenting on the access control > framework that we suggested KaiGai try to separate from the main body > of the patch to break it into more managable chunks. That patch was > summarily rejected by Tom for what I believe were valid reasons. In > other words, in 18 months of trying we've yet to see something that is > close to being committable. Contrast that with Hot Standby, which > Heikki made a real shot at committing during the first CommitFest to > which it was submitted. > > I think David Fetter summarized it pretty well here - the rest of the > thread is worth reading, too. > > http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php > > I think the only chance of this ever getting committed is if a > committer volunteers to take ownership of it, similar to what Heikki > has done for Hot Standby and Streaming Replication. Right now, we > don't have any volunteers, and even if Tom or Heikki were interested, > I suspect it would occupy their entire attention for several > CommitFests just as HS and SR have done for Heikki. I suspect the > amount of work for SE-PostgreSQL might even be larger than for HS. If > we DON'T have a committer who is willing to own this, then I don't > think there's a choice other than giving up. I offered to review it. I was going to mostly review the parts that impacted our existing code, and I wasn't going to be able to do a thorough job of the SE-Linux-specific files. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sat, Dec 5, 2009 at 12:14 AM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> Actually, we tried that already, in a previous iteration of this >> discussion. Someone actually materialized and commented on a few >> things. The problem, as I remember it, was that they didn't know much >> about PostgreSQL, so we didn't get very far with it. Unfortunately, I >> can't find the relevant email thread at the moment. >> >> In fact, we've tried about everything with these patches. Tom >> reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed >> them, Stephen Frost reviewed them, Heikki took at least a brief look >> at them, and I think there were a few other people, too. The first >> person who I can recall being relatively happy with any version of >> this patch was Stephen Frost, commenting on the access control >> framework that we suggested KaiGai try to separate from the main body >> of the patch to break it into more managable chunks. That patch was >> summarily rejected by Tom for what I believe were valid reasons. In >> other words, in 18 months of trying we've yet to see something that is >> close to being committable. Contrast that with Hot Standby, which >> Heikki made a real shot at committing during the first CommitFest to >> which it was submitted. >> >> I think David Fetter summarized it pretty well here - the rest of the >> thread is worth reading, too. >> >> http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php >> >> I think the only chance of this ever getting committed is if a >> committer volunteers to take ownership of it, similar to what Heikki >> has done for Hot Standby and Streaming Replication. Right now, we >> don't have any volunteers, and even if Tom or Heikki were interested, >> I suspect it would occupy their entire attention for several >> CommitFests just as HS and SR have done for Heikki. I suspect the >> amount of work for SE-PostgreSQL might even be larger than for HS. If >> we DON'T have a committer who is willing to own this, then I don't >> think there's a choice other than giving up. > > I offered to review it. I was going to mostly review the parts that > impacted our existing code, and I wasn't going to be able to do a > thorough job of the SE-Linux-specific files. Review it and commit it, after making whatever modifications are necessary? Or review it in part, leaving the final review and commit to someone else? I just read through the latest version of this patch and it does appear to be in significantly better shape than the versions I read back in July. So it might not require a Herculean feat of strength to get this in, but I still think it's going to be a big job. There's a lot of code here that needs to be verified and in some cases probably cleaned up or restructured. If you're prepared to take it on, I'm not going to speak against that, other than to say that I think you have your work cut out for you. ...Robert
Robert Haas wrote: > > I offered to review it. ?I was going to mostly review the parts that > > impacted our existing code, and I wasn't going to be able to do a > > thorough job of the SE-Linux-specific files. > > Review it and commit it, after making whatever modifications are > necessary? Or review it in part, leaving the final review and commit > to someone else? > > I just read through the latest version of this patch and it does > appear to be in significantly better shape than the versions I read > back in July. So it might not require a Herculean feat of strength to > get this in, but I still think it's going to be a big job. There's a > lot of code here that needs to be verified and in some cases probably > cleaned up or restructured. If you're prepared to take it on, I'm not > going to speak against that, other than to say that I think you have > your work cut out for you. This is no harder than many of the other seemingly crazy things I have done, e.g. Win32 port, client library threading. If this is a feature we should have, I will get it done or get others to help me complete the task. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Robert Haas wrote: > On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus <josh@agliodbs.com> wrote: >> Kaigai, you've said that you could get SELinux folks involved in the >> patch review. I think it's past time that they were; please solicit them. > > Actually, we tried that already, in a previous iteration of this > discussion. Someone actually materialized and commented on a few > things. The problem, as I remember it, was that they didn't know much > about PostgreSQL, so we didn't get very far with it. Unfortunately, I > can't find the relevant email thread at the moment. IIRC, at least a couple of the guys mentioned on the NSA's SE-Linux page[1] participated - Joshua Brindle[2] and Chad Sellers[3] (in addition to Kaigai/NEC who's credited on the NSA site as well). Perhaps one or two others too - but with common names it's hard to guess. Links to the threads with Chad and Joshua below. [1] http://www.nsa.gov/research/selinux/contrib.shtml [2] http://www.google.com/search?q=site%3Aarchives.postgresql.org+brindle [3] http://www.google.com/search?q=site%3Aarchives.postgresql.org+chad+sellers
On Sat, Dec 5, 2009 at 8:18 AM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> > I offered to review it. ?I was going to mostly review the parts that >> > impacted our existing code, and I wasn't going to be able to do a >> > thorough job of the SE-Linux-specific files. >> >> Review it and commit it, after making whatever modifications are >> necessary? Or review it in part, leaving the final review and commit >> to someone else? >> >> I just read through the latest version of this patch and it does >> appear to be in significantly better shape than the versions I read >> back in July. So it might not require a Herculean feat of strength to >> get this in, but I still think it's going to be a big job. There's a >> lot of code here that needs to be verified and in some cases probably >> cleaned up or restructured. If you're prepared to take it on, I'm not >> going to speak against that, other than to say that I think you have >> your work cut out for you. > > This is no harder than many of the other seemingly crazy things I have > done, e.g. Win32 port, client library threading. If this is a feature > we should have, I will get it done or get others to help me complete the > task. Well, I have always thought that it would be sort of a feather in our cap to support this, which is why I've done a couple of reviews of it in the past. I tend to agree with Tom that only a small fraction of our users will probably want it, but then again someone's been paying KaiGai to put a pretty hefty amount of work into this over the last year-plus, so obviously someone not only wants the feature but wants it merged. Within our community, I think that there have been a lot of people who have liked the concept of this feature but very few who have liked the patch, so there's somewhat of a disconnect between our aspirations and our better technical judgment. Tom is a notable exception who I believe likes neither the concept nor the patch, which is something we may need to resolve before getting too serious about this. ...Robert
Robert Haas wrote: > > This is no harder than many of the other seemingly crazy things I have > > done, e.g. Win32 port, client library threading. ?If this is a feature > > we should have, I will get it done or get others to help me complete the > > task. > > Well, I have always thought that it would be sort of a feather in our > cap to support this, which is why I've done a couple of reviews of it > in the past. I tend to agree with Tom that only a small fraction of > our users will probably want it, but then again someone's been paying > KaiGai to put a pretty hefty amount of work into this over the last > year-plus, so obviously someone not only wants the feature but wants > it merged. Within our community, I think that there have been a lot > of people who have liked the concept of this feature but very few who > have liked the patch, so there's somewhat of a disconnect between our > aspirations and our better technical judgment. Tom is a notable > exception who I believe likes neither the concept nor the patch, which > is something we may need to resolve before getting too serious about > this. Agreed. SE-Linux support might expand our user base and give us additional credibility, or it might be a feature that few people use --- and I don't think anyone knows the outcome. I wonder if we should rephrase this as, "How hard will this feature be to add, and how hard will it be to remove in a few years if we decide we don't want it?" SE-Linux support would certainly put Postgres in a unique security category, and it builds on our existing good security reputation. Personally, I think AppArmor is a saner security system: http://www.novell.com/linux/security/apparmor/selinux_comparison.html(Novell-hosted URL) but I am not advocating AppArmor support. I think the whole issue is whether support for external integrated security systems is appropriate for Postgres. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> > This is no harder than many of the other seemingly crazy things I have >> > done, e.g. Win32 port, client library threading. ?If this is a feature >> > we should have, I will get it done or get others to help me complete the >> > task. >> >> Well, I have always thought that it would be sort of a feather in our >> cap to support this, which is why I've done a couple of reviews of it >> in the past. I tend to agree with Tom that only a small fraction of >> our users will probably want it, but then again someone's been paying >> KaiGai to put a pretty hefty amount of work into this over the last >> year-plus, so obviously someone not only wants the feature but wants >> it merged. Within our community, I think that there have been a lot >> of people who have liked the concept of this feature but very few who >> have liked the patch, so there's somewhat of a disconnect between our >> aspirations and our better technical judgment. Tom is a notable >> exception who I believe likes neither the concept nor the patch, which >> is something we may need to resolve before getting too serious about >> this. > > Agreed. SE-Linux support might expand our user base and give us > additional credibility, or it might be a feature that few people use --- > and I don't think anyone knows the outcome. > > I wonder if we should rephrase this as, "How hard will this feature be > to add, and how hard will it be to remove in a few years if we decide we > don't want it?" SE-Linux support would certainly put Postgres in a > unique security category, and it builds on our existing good security > reputation. Yes, I think that's the right way to think about it. At a guess, it's two man-months of work to get it in, and ripping it out is likely technically fairly simple but will probably be politically impossible. > Personally, I think AppArmor is a saner security system: > > http://www.novell.com/linux/security/apparmor/selinux_comparison.html > (Novell-hosted URL) Agreed. > but I am not advocating AppArmor support. I think the whole issue is > whether support for external integrated security systems is appropriate > for Postgres. It's not something I've run into a need for in my own work, but I think there are definitely people out there who do need it, and I'd like to see us be able to support it. One of the things that I think would be worth looking into is whether there is a way to make this pluggable, so that selinux and apparmor and trusted solaris and so on could make use of the same framework, but that requires understanding all of them well enough to design a framework that can meet all of those needs. Every framework effort we've seen from KaiGai so far has seemed extremely SE-Linux-specific and therefore pointless. But really doing this right is a big development project, and not something I can do in my free time. ...Robert
Robert Haas <robertmhaas@gmail.com> wrote: > Bruce Momjian <bruce@momjian.us> wrote: >> Personally, I think AppArmor is a saner security system: >> >> http://www.novell.com/linux/security/apparmor/selinux_comparison.html > Agreed. > I'd like to see us be able to support it. One of the things that > I think would be worth looking into is whether there is a way to > make this pluggable, so that selinux and apparmor and trusted > solaris and so on could make use of the same framework Given the extreme patience and diligence exhibited by KaiGai, I hesitate to say this, but it seems to me that this would be critically important for the long term success of this feature. I have no idea how much work it would be to make the interface to the external security system pluggable, but if it's at all feasible, I think it should be done. -Kevin
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce@momjian.us> wrote: >> I wonder if we should rephrase this as, "How hard will this feature be >> to add, and how hard will it be to remove in a few years if we decide we >> don't want it?" > Yes, I think that's the right way to think about it. At a guess, it's > two man-months of work to get it in, It's not the "get it in" part that scares me. The problem I have with it is that I see it as a huge time sink for future maintenance problems, most of which will be classifiable as security breaches which increases the pain of dealing with them immeasurably. If I had more confidence that the basic design was right or useful I might not be so worried about the maintenance prospects, but frankly I have almost no confidence in it. This comes back to the lack of involvement of any potential user community. regards, tom lane
Kevin Grittner escribió: > > I'd like to see us be able to support it. One of the things that > > I think would be worth looking into is whether there is a way to > > make this pluggable, so that selinux and apparmor and trusted > > solaris and so on could make use of the same framework > > Given the extreme patience and diligence exhibited by KaiGai, I > hesitate to say this, but it seems to me that this would be > critically important for the long term success of this feature. I > have no idea how much work it would be to make the interface to the > external security system pluggable, but if it's at all feasible, I > think it should be done. This is how the code was developed initially -- the patch was called PGACE and SELinux was but the first implementation on top of it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote: > > Given the extreme patience and diligence exhibited by KaiGai, I > > hesitate to say this, but it seems to me that this would be > > critically important for the long term success of this feature. I > > have no idea how much work it would be to make the interface to the > > external security system pluggable, but if it's at all feasible, I > > think it should be done. > > This is how the code was developed initially -- the patch was called > PGACE and SELinux was but the first implementation on top of it. I find it astonishing that after SE-PgSQL was implemented on top of a pluggable system (PGACE) and this system was removed at request of the "community" [1] that at this late phase people are suggesting it needs to be added back again. Havn't the goalposts been moved enough times? [1] http://archives.postgresql.org/pgsql-hackers/2009-01/msg02295.php (It seems we've gone from a patch that had been around for years solving actual people's problems to a patch which does barely anything and we don't know whether it solves anybodies problem). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
Martijn van Oosterhout <kleptog@svana.org> writes: > I find it astonishing that after SE-PgSQL was implemented on top of a > pluggable system (PGACE) and this system was removed at request of the > "community" [1] that at this late phase people are suggesting it needs > to be added back again. Havn't the goalposts been moved enough times? The reason the goalposts keep moving is that nobody has a very clear handle on what the requirements are, which stems from the lack of a clear target community with definable needs. We have had a couple of apparently-knowledgeable people pop up and say "you should do this", but then they disappear again without sticking around for any detailed discussion of features (let alone code). > (It seems we've gone from a patch that had been around for years > solving actual people's problems to a patch which does barely anything > and we don't know whether it solves anybodies problem). Do we know that any version of this patch has solved any actual people's problems? I know KaiGai-san has been putting it out as a Fedora package but there's little if any evidence that anyone's actually using that. regards, tom lane
tgl@sss.pgh.pa.us (Tom Lane) writes: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce@momjian.us> wrote: >>> I wonder if we should rephrase this as, "How hard will this feature be >>> to add, and how hard will it be to remove in a few years if we decide we >>> don't want it?" > >> Yes, I think that's the right way to think about it. At a guess, it's >> two man-months of work to get it in, > > It's not the "get it in" part that scares me. The problem I have with > it is that I see it as a huge time sink for future maintenance problems, > most of which will be classifiable as security breaches which increases > the pain of dealing with them immeasurably. Ah, yes, the importance of this is not to be underestimated... Once "SE-Pg" is added in, *any* bug found in it is likely to be considered a security bug, and hence a candidate for being a CERT Advisory. Some bad things are liable to happen: a) Such problems turn into a "hue and cry" situation requiring dropping everything else to "fix the security problem." b) If everyone isn't using "SE-Pg", then people won't be particularly looking for bugs, and hence bugs are likely tolinger somewhat, with the consequence that a) occurs with some frequency. c) Having a series of CERT advisories issued is not going to be considered a good thing, reputation-wise! I feel about the same way about this as I did about the adding of "native Windows" support; I'm a bit concerned that this could be a destabilizing influence. I was wrong back then; the Windows support hasn't had the ill effects I was concerned it might have. I'd hope that my concerns about "SE-Pg" are just as wrong as my concerns about native Windows support. Hope doesn't make it so, alas... -- select 'cbbrowne' || '@' || 'gmail.com'; http://www3.sympatico.ca/cbbrowne/languages.html "Just because it's free doesn't mean you can afford it." -- Unknown
Chris Browne <cbbrowne@acm.org> writes: > I feel about the same way about this as I did about the adding of > "native Windows" support; I'm a bit concerned that this could be a > destabilizing influence. I was wrong back then; the Windows support > hasn't had the ill effects I was concerned it might have. That's an interesting analogy. I too am not entirely convinced that it's a good comparison, but if it is, consider these points: * The goal of the Windows port was pretty well-defined and easily tested: "make it work on Windows". The goalposts didn't move except perhaps when MS came out with new Windows versions. * We had a *lot* of users available to help flush out problems. * There wasn't any need to treat bugs as security sensitive, which is problematic not least because it restricts the free flow of information. Any one of those points would be good reason to think that getting SEPostgres to stability will be lots more drawn-out and painful than getting the Windows port to stability was. With all three pointing in the same direction, the tea leaves don't look good. regards, tom lane
Robert Haas wrote: > > Agreed. ?SE-Linux support might expand our user base and give us > > additional credibility, or it might be a feature that few people use --- > > and I don't think anyone knows the outcome. > > > > I wonder if we should rephrase this as, "How hard will this feature be > > to add, and how hard will it be to remove in a few years if we decide we > > don't want it?" ?SE-Linux support would certainly put Postgres in a > > unique security category, and it builds on our existing good security > > reputation. > > Yes, I think that's the right way to think about it. At a guess, it's > two man-months of work to get it in, and ripping it out is likely > technically fairly simple but will probably be politically impossible. I figure if there is sufficient usage, we will not need to remove it, and if there isn't, we will have no objections to removing it. > > but I am not advocating AppArmor support. ?I think the whole issue is > > whether support for external integrated security systems is appropriate > > for Postgres. > > It's not something I've run into a need for in my own work, but I > think there are definitely people out there who do need it, and I'd > like to see us be able to support it. One of the things that I think > would be worth looking into is whether there is a way to make this > pluggable, so that selinux and apparmor and trusted solaris and so on > could make use of the same framework, but that requires understanding > all of them well enough to design a framework that can meet all of > those needs. Every framework effort we've seen from KaiGai so far has > seemed extremely SE-Linux-specific and therefore pointless. But > really doing this right is a big development project, and not > something I can do in my free time. As Alvaro mentioned, the original patch used ACE but it added too much code so the community requested its removal from the patch. It could be re-added if we have a need. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Martijn van Oosterhout escribió: > On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote: > > This is how the code was developed initially -- the patch was called > > PGACE and SELinux was but the first implementation on top of it. > > I find it astonishing that after SE-PgSQL was implemented on top of a > pluggable system (PGACE) and this system was removed at request of the > "community" [1] that at this late phase people are suggesting it needs > to be added back again. Havn't the goalposts been moved enough times? Yeah. I think the idle discussions here have created more work themselves than the hypothetical maintenance work that would be spent on this (undoubtely useful) feature. > (It seems we've gone from a patch that had been around for years > solving actual people's problems to a patch which does barely anything > and we don't know whether it solves anybodies problem). Agreed :-( -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Bruce Momjian <bruce@momjian.us> writes: > Robert Haas wrote: >> Yes, I think that's the right way to think about it. At a guess, it's >> two man-months of work to get it in, and ripping it out is likely >> technically fairly simple but will probably be politically impossible. > I figure if there is sufficient usage, we will not need to remove it, > and if there isn't, we will have no objections to removing it. That leaves a wide gray area where there are a few people using it but not really enough to justify the support effort. Even if there are demonstrably no users (which can never be demonstrated in practice), politically it's very hard to rip out a "major feature" --- it makes the project look bad. So I think the above is Pollyanna-ish nonsense. Once we ship a release with SEPostgres in it, we're committed. > As Alvaro mentioned, the original patch used ACE but it added too much > code so the community requested its removal from the patch. It could be > re-added if we have a need. The main problem I saw with ACE was that it didn't appear to actually add any flexibility --- it was just an extra layer of function calls in an entirely SELinux-centric design. In order to have a "pluggable interface" layer that is worth the electrons it's written on, you need to start out with more than one target system in mind to be plugged in. So that would mean, at minimum, investigating something like AppArmor or TrustedSolaris to see what its needs are before we sit down to design the plugin layer. (Which, of course, nobody here is actually interested enough to do. But without that research there is no point in demanding a plugin layer.) regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Robert Haas wrote: > >> Yes, I think that's the right way to think about it. At a guess, it's > >> two man-months of work to get it in, and ripping it out is likely > >> technically fairly simple but will probably be politically impossible. > > > I figure if there is sufficient usage, we will not need to remove it, > > and if there isn't, we will have no objections to removing it. > > That leaves a wide gray area where there are a few people using it but > not really enough to justify the support effort. Even if there are > demonstrably no users (which can never be demonstrated in practice), > politically it's very hard to rip out a "major feature" --- it makes the > project look bad. So I think the above is Pollyanna-ish nonsense. I don't even know what "Pollyanna-ish nonsense" means, and it would be better if you used less flowery/inflamitory prose. > Once we ship a release with SEPostgres in it, we're committed. The MS Windows port took 1-2 years to solidify and during the solidification period we accepted problems and didn't treat it as a major platform. I think if SE-Linux support is added, there would be a similar period where the features is not treated as major while we work out any problems. We might even label it that way. Labeling SE-Postgres as such might minimize the political problems of removing it in the future, if that becomes necessary. I know there has been complaints about the lack of SE-PostgreSQL developers, but given the number of developers we had for the Win32 port vs. the installed base, I think having one dedicated SE-PostgreSQL developer is much more percentage-wise than we had for MS Windows. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: > As Alvaro mentioned, the original patch used ACE but it added too much > code so the community requested its removal from the patch. It could be > re-added if we have a need. Well, there's no point in putting that framework back in unless we can make it sufficiently general that it could be used to serve the needs of more than one security model. And so far, the signs have not been promising. David Quigley suggests downthread that making a truly general model isn't really possible, and he may be right, or not. I was just mentioning that it's an angle I have been thinking about investigating, but it may be a dead end. The real issue is making the code committable, and then maintaining it, as Tom rightly says, forever. We've got to make sure that we're willing to take that on before we do it, and I don't think it's a small task. It isn't so much whether we want the feature as whether the level of effort is proportionate to the benefit. ...Robert
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce@momjian.us> wrote: >>> I wonder if we should rephrase this as, "How hard will this feature be >>> to add, and how hard will it be to remove in a few years if we decide we >>> don't want it?" > >> Yes, I think that's the right way to think about it. At a guess, it's >> two man-months of work to get it in, > > It's not the "get it in" part that scares me. The problem I have with > it is that I see it as a huge time sink for future maintenance problems, > most of which will be classifiable as security breaches which increases > the pain of dealing with them immeasurably. We can clearly say that acception of this feature is equivalent to getting a new developer to maintain this feature into the community. It is preferable to change my role in this community; I'd like to perform as a maintainer of this feature rather than a person who send a large patch for each commit-fest. > If I had more confidence that the basic design was right or useful > I might not be so worried about the maintenance prospects, but frankly > I have almost no confidence in it. This comes back to the lack of > involvement of any potential user community. We should not ignore a fact several commercial database software provides advanced security options that are partially similar to SE-PgSQL. It allows them to reach a region where PgSQL has not reached yet, and these features are supported by an amount of users. Anyway, it seems to me it is counterproductive to discuss whether the potential users are larger or smaller, because it is a difficult job to estimate it correctly, even if we would be experienced marketers. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> Robert Haas wrote: >>>> Yes, I think that's the right way to think about it. At a guess, it's >>>> two man-months of work to get it in, and ripping it out is likely >>>> technically fairly simple but will probably be politically impossible. >>> I figure if there is sufficient usage, we will not need to remove it, >>> and if there isn't, we will have no objections to removing it. >> That leaves a wide gray area where there are a few people using it but >> not really enough to justify the support effort. Even if there are >> demonstrably no users (which can never be demonstrated in practice), >> politically it's very hard to rip out a "major feature" --- it makes the >> project look bad. So I think the above is Pollyanna-ish nonsense. > > I don't even know what "Pollyanna-ish nonsense" means, and it would be > better if you used less flowery/inflamitory prose. Apart from standpoint of the discussion, idiomatic phrases are not oftern friendly for non-native English speakers. >> Once we ship a release with SEPostgres in it, we're committed. > > The MS Windows port took 1-2 years to solidify and during the > solidification period we accepted problems and didn't treat it as a > major platform. I think if SE-Linux support is added, there would be a > similar period where the features is not treated as major while we work > out any problems. We might even label it that way. It also seems to me an realistic attitude. The first guy needs courage independently from the class of features. Thus, anybody attend to see case examples in conferences. I don't think here is no fundamental differences. > Labeling SE-Postgres as such might minimize the political problems of > removing it in the future, if that becomes necessary. For us, the name is not an important issue. And, I believe our continued contributions in the future shall make it unnecessary to remove it later. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Robert Haas wrote: > On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: >> As Alvaro mentioned, the original patch used ACE but it added too much >> code so the community requested its removal from the patch. It could be >> re-added if we have a need. > > Well, there's no point in putting that framework back in unless we can > make it sufficiently general that it could be used to serve the needs > of more than one security model. And so far, the signs have not been > promising. David Quigley suggests downthread that making a truly > general model isn't really possible, and he may be right, or not. I > was just mentioning that it's an angle I have been thinking about > investigating, but it may be a dead end. I also agree that the common framework just increases complexity of the patch at the moment. > The real issue is making the code committable, and then maintaining > it, as Tom rightly says, forever. We've got to make sure that we're > willing to take that on before we do it, and I don't think it's a > small task. It isn't so much whether we want the feature as whether > the level of effort is proportionate to the benefit. Needless to say, we can provide development resource to maintain this feature. If we escape to anywhere just after commit it, it will be removed as Bruce pointed out. But it shall be incorrect. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
I could not find the message from David P. Quigley in the list, although pgsql-hackers@postgresql.org was Cc:'ed. (something troubled?) So, I'll send it again for your information. -------- Original Message -------- Subject: Re: [HACKERS] Adding support for SE-Linux security Date: Mon, 07 Dec 2009 14:53:03 -0500 From: David P. Quigley <dpquigl@tycho.nsa.gov> Organization: National Security Agency To: Tom Lane <tgl@sss.pgh.pa.us> CC: Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, KaiGaiKohei <kaigai@ak.jp.nec.com>, jd@commandprompt.com, David Fetter <david@fetter.org>, Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>, KaiGai Kohei <kaigai@kaigai.gr.jp>, pgsql-hackers@postgresql.org References: <200912071800.nB7I0KB01863@momjian.us> <21873.1260209825@sss.pgh.pa.us> On Mon, 2009-12-07 at 13:17 -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Robert Haas wrote: > >> Yes, I think that's the right way to think about it. At a guess, it's > >> two man-months of work to get it in, and ripping it out is likely > >> technically fairly simple but will probably be politically impossible. > > > I figure if there is sufficient usage, we will not need to remove it, > > and if there isn't, we will have no objections to removing it. > > That leaves a wide gray area where there are a few people using it but > not really enough to justify the support effort. Even if there are > demonstrably no users (which can never be demonstrated in practice), > politically it's very hard to rip out a "major feature" --- it makes the > project look bad. So I think the above is Pollyanna-ish nonsense. > Once we ship a release with SEPostgres in it, we're committed. > > > As Alvaro mentioned, the original patch used ACE but it added too much > > code so the community requested its removal from the patch. It could be > > re-added if we have a need. > > The main problem I saw with ACE was that it didn't appear to actually > add any flexibility --- it was just an extra layer of function calls > in an entirely SELinux-centric design. In order to have a "pluggable > interface" layer that is worth the electrons it's written on, you need > to start out with more than one target system in mind to be plugged in. > So that would mean, at minimum, investigating something like AppArmor or > TrustedSolaris to see what its needs are before we sit down to design > the plugin layer. (Which, of course, nobody here is actually interested > enough to do. But without that research there is no point in demanding > a plugin layer.) > > regards, tom lane > Not to start a flame war here about access control models but you gave 3 different examples one of which I don't think has any means to do anything productive here. Looking at the 3 examples you gave and what SEPostgres is trying to accomplish here is what I see. The point of SEPostgres is to do object labeling in a database. Two of the three examples you gave are label based security mechanisms. AppArmor while it might be able to have a scheme to mediate access to database/table doesn't seem to have a reasonable way to write policy to individual records. Since AppArmor is path name based you need an identifiable path to whatever you want to write access control rules for. With something like a database where data dynamically comes and goes and changes doing rules on individual records seems difficult. I also can't find any information about AppArmor being used as a user-space object manager. If someone wants to prove me wrong I'm willing to listen to their argument. Lets look at the remaining two. Do you really mean TrustedSolaris(TSOL) or do you mean Solaris with Trusted Extensions(TX). There is a big difference here. From my understanding Sun no longer supports TSOL and moved on to TX. The difference here is that they moved from fine grained object labeling to zone based labeling. There is a project currently in development (although moving a bit slow) called FMAC which will bring SELinux style MAC to Solaris which will reintroduce fine grained labeling. You will still be able to use zones however process and object labels will not be based on zone in FMAC. I understand the concerns with a generic framework introducing a lot of code. The Linux Kernel LSM Framework seems to grow as more models are introduced but if you want to support various models you have to live with the fact that there is no common interface for all of these systems. It has been tried numerous times in the past and has failed. >From what I've seen I think that will be less of a concern with Postgres since the objects that Kaigai wants to mediate is a much smaller set than the kernel. If you want to see another instance of where work similar to this was done you should look at the X-Access Control eXtensions (X-ACE) found in the X server. Eamon Walsh designed this framework based not on anything SELinux specific but through an analysis of the X Server which yielded a list of object he though needed mediating. There are two modules for X-ACE now the FLASK module (SELinux) and a module put forth by Casey Schaufler for his SMACK work. >From what I've seen on the SELinux list Kaigai's design of SEPostgres was conducted in a similar way. I'll be willing to answer any questions you have for me in order to help Kaigai's work along. Normally another member of our team would be participating in this but he is unavailable at the moment. When he is available again I'm sure he will participate in the discussion. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
KaiGai Kohei escribió: > I could not find the message from David P. Quigley in the list, > although pgsql-hackers@postgresql.org was Cc:'ed. > (something troubled?) Weird. It didn't even made it to the moderator queue for some reason. Perhaps the system dropped it as spam. > So, I'll send it again for your information. Good move. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
David P. Quigley wrote: > Not to start a flame war here about access control models but you gave 3 > different examples one of which I don't think has any means to do > anything productive here. You won't be starting a flame war for the same reason some of the community members are so concerned about this patch. There aren't enough people familiar with this part of the security field within our database developer community to even be able to answer fairly basic questions like the one you just clarified. If you can help bring more qualified reviewers to bear on that, it would be extremely helpful. I even tried to organize a meetup between PostgreSQL hackers working in this area and the security people I knew around here (Baltimore/DC) last year, but just couldn't find any interested enough to show. Other than a brief visit on this list from some of the Tresys guys, we haven't seen much input here beyond that offered by the patch author, who's obviously qualified but at the end of the day is still only one opinion. He's also not in a good position to tell other people their ideas are misinformed either. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Mon, 2009-12-07 at 22:25 -0500, Greg Smith wrote: > David P. Quigley wrote: > > Not to start a flame war here about access control models but you gave 3 > > different examples one of which I don't think has any means to do > > anything productive here. > You won't be starting a flame war for the same reason some of the > community members are so concerned about this patch. There aren't enough > people familiar with this part of the security field within our database > developer community to even be able to answer fairly basic questions > like the one you just clarified. If you can help bring more qualified > reviewers to bear on that, it would be extremely helpful. I even tried > to organize a meetup between PostgreSQL hackers working in this area and > the security people I knew around here (Baltimore/DC) last year, but > just couldn't find any interested enough to show. Other than a brief > visit on this list from some of the Tresys guys, we haven't seen much > input here beyond that offered by the patch author, who's obviously > qualified but at the end of the day is still only one opinion. He's also > not in a good position to tell other people their ideas are misinformed > either. > I can't make any guarantees on who I can drag to a meeting but if you wanted to try to organize another meeting between the Postgres people and some of us I can try to organize it on our end. One of my coworkers that does a lot of commenting on stuff like this is on leave at the moment but when he gets back I'll discuss it with him. I'll also talk with some of the other people in the area on our end to see what I can arrange. If you have any questions in the meantime feel free to ask. If there are any specific parts of the patch that you'd like discussed I can do that as well. I do have to agree though that I'd rather see KaiGai's original security plugin framework go in and then merge a particular security module after that.From what I see it would require at least the hook framework and the label storage mechanism. I feel bad saying that knowing the KaiGai spent a lot of time ripping all of that out. However if you are concerned about supporting more than just SELinux as a MAC model then the plugin framework he originally proposed is the better solution. I'd be willing to take a look at the framework and see if it really is SELinux centric. If it is we can figure out if there is a way to accomodate something like SMACK and FMAC. I'd like to hear from someone with more extensive experience with Solaris Trusted Extensions about how TX would make use of this. I have a feeling it would be similar to the way it deals with NFS which is by having the process exist in the global zone as a privileged process and then multi-plexes it to the remaining zones. That way their getpeercon would get a label derived from the zone. Dave
On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: > I'd be willing to take a look at the framework and see if it really is > SELinux centric. If it is we can figure out if there is a way to > accomodate something like SMACK and FMAC. I'd like to hear from someone > with more extensive experience with Solaris Trusted Extensions about how > TX would make use of this. I have a feeling it would be similar to the > way it deals with NFS which is by having the process exist in the global > zone as a privileged process and then multi-plexes it to the remaining > zones. That way their getpeercon would get a label derived from the > zone. Well, the old patches should still be available in the mailing list archives. Maybe going back and looking at that code would be a good place to start. The non-ripped-out code has been cleaned up a lot since then, but at least it's a place to start. ...Robert
On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: > On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: >> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: >> > As Alvaro mentioned, the original patch used ACE but it added too much >> > code so the community requested its removal from the patch. It could be >> > re-added if we have a need. >> >> Well, there's no point in putting that framework back in unless we can >> make it sufficiently general that it could be used to serve the needs >> of more than one security model. And so far, the signs have not been >> promising. David Quigley suggests downthread that making a truly >> general model isn't really possible, and he may be right, or not. I >> was just mentioning that it's an angle I have been thinking about >> investigating, but it may be a dead end. >> >> The real issue is making the code committable, and then maintaining >> it, as Tom rightly says, forever. We've got to make sure that we're >> willing to take that on before we do it, and I don't think it's a >> small task. It isn't so much whether we want the feature as whether >> the level of effort is proportionate to the benefit. >> >> ...Robert >> > > So the issue with generality is that path name based MAC has a different > set of requirements than label based does. If you want to acomodate > several types of label based MAC models then a framework can be > developed for that similar to the one in the Linux Kernel. I asked > around after I sent the email yesterday and from what I understand > AppArmor does not have the concept of a userspace object manager so I > don't know what they'd do in this area. I'm sure they could come up with > a scheme to write policy for the database but I don't know how useful it > would be. > > If you look at the LSM framework in the Linux Kernel recently there have > been hooks added to accomodate path based MAC systems so it can be done > but adds another set of hooks. The important goal here though in > designing a framework is to make sure that you have a comprehensive list > of the objects you want to mediate and make sure you put the proper > enforcement points in. Someone may come along later and want to mediate > a new object or some new functionality may come along that introduces a > new object so a hook may then need to be added. Something to realize as > well is that a security model may not want to implement all of the hooks > and it doesn't have to. In the case of no module being loaded or someone > not wanting the loadable security module framework I'm sure we can > provide an option to reduce overhead or compile the framework out > completely. > > I'll take a look at his patches for the framework that KaiGai originally > proposed. It sounds like the pathname-based schemes are not really designed to work inside of a database anyway, so my first thought is we shouldn't worry about them. The label-based schemes are by their nature designed to apply in an arbitrary context being applied to arbitrary objects. ...Robert
On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote: > On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: > > On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: > >> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: > >> > As Alvaro mentioned, the original patch used ACE but it added too much > >> > code so the community requested its removal from the patch. It could be > >> > re-added if we have a need. > >> > >> Well, there's no point in putting that framework back in unless we can > >> make it sufficiently general that it could be used to serve the needs > >> of more than one security model. And so far, the signs have not been > >> promising. David Quigley suggests downthread that making a truly > >> general model isn't really possible, and he may be right, or not. I > >> was just mentioning that it's an angle I have been thinking about > >> investigating, but it may be a dead end. > >> > >> The real issue is making the code committable, and then maintaining > >> it, as Tom rightly says, forever. We've got to make sure that we're > >> willing to take that on before we do it, and I don't think it's a > >> small task. It isn't so much whether we want the feature as whether > >> the level of effort is proportionate to the benefit. > >> > >> ...Robert > >> > > > > So the issue with generality is that path name based MAC has a different > > set of requirements than label based does. If you want to acomodate > > several types of label based MAC models then a framework can be > > developed for that similar to the one in the Linux Kernel. I asked > > around after I sent the email yesterday and from what I understand > > AppArmor does not have the concept of a userspace object manager so I > > don't know what they'd do in this area. I'm sure they could come up with > > a scheme to write policy for the database but I don't know how useful it > > would be. > > > > If you look at the LSM framework in the Linux Kernel recently there have > > been hooks added to accomodate path based MAC systems so it can be done > > but adds another set of hooks. The important goal here though in > > designing a framework is to make sure that you have a comprehensive list > > of the objects you want to mediate and make sure you put the proper > > enforcement points in. Someone may come along later and want to mediate > > a new object or some new functionality may come along that introduces a > > new object so a hook may then need to be added. Something to realize as > > well is that a security model may not want to implement all of the hooks > > and it doesn't have to. In the case of no module being loaded or someone > > not wanting the loadable security module framework I'm sure we can > > provide an option to reduce overhead or compile the framework out > > completely. > > > > I'll take a look at his patches for the framework that KaiGai originally > > proposed. > > It sounds like the pathname-based schemes are not really designed to > work inside of a database anyway, so my first thought is we shouldn't > worry about them. The label-based schemes are by their nature > designed to apply in an arbitrary context being applied to arbitrary > objects. > > ...Robert So I was reading through a set of slides that KaiGai has and he mentioned a May commitfest link and I looked for the comments related to his PGACE patches. I've been crawling through the commitfest paces so I can figure out what the latest version of the pgace patch is. Does anyone know when the patch was reduced to what it is today? Dave
On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote: > On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote: >> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl@tycho.nsa.gov> >> wrote: >>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: >>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: >>>>> As Alvaro mentioned, the original patch used ACE but it added too much >>>>> code so the community requested its removal from the patch. It could be >>>>> re-added if we have a need. >>>> >>>> Well, there's no point in putting that framework back in unless we can >>>> make it sufficiently general that it could be used to serve the needs >>>> of more than one security model. And so far, the signs have not been >>>> promising. David Quigley suggests downthread that making a truly >>>> general model isn't really possible, and he may be right, or not. I >>>> was just mentioning that it's an angle I have been thinking about >>>> investigating, but it may be a dead end. >>>> >>>> The real issue is making the code committable, and then maintaining >>>> it, as Tom rightly says, forever. We've got to make sure that we're >>>> willing to take that on before we do it, and I don't think it's a >>>> small task. It isn't so much whether we want the feature as whether >>>> the level of effort is proportionate to the benefit. >>>> >>>> ...Robert >>>> >>> >>> So the issue with generality is that path name based MAC has a different >>> set of requirements than label based does. If you want to acomodate >>> several types of label based MAC models then a framework can be >>> developed for that similar to the one in the Linux Kernel. I asked >>> around after I sent the email yesterday and from what I understand >>> AppArmor does not have the concept of a userspace object manager so I >>> don't know what they'd do in this area. I'm sure they could come up with >>> a scheme to write policy for the database but I don't know how useful it >>> would be. >>> >>> If you look at the LSM framework in the Linux Kernel recently there have >>> been hooks added to accomodate path based MAC systems so it can be done >>> but adds another set of hooks. The important goal here though in >>> designing a framework is to make sure that you have a comprehensive list >>> of the objects you want to mediate and make sure you put the proper >>> enforcement points in. Someone may come along later and want to mediate >>> a new object or some new functionality may come along that introduces a >>> new object so a hook may then need to be added. Something to realize as >>> well is that a security model may not want to implement all of the hooks >>> and it doesn't have to. In the case of no module being loaded or someone >>> not wanting the loadable security module framework I'm sure we can >>> provide an option to reduce overhead or compile the framework out >>> completely. >>> >>> I'll take a look at his patches for the framework that KaiGai originally >>> proposed. >> >> It sounds like the pathname-based schemes are not really designed to >> work inside of a database anyway, so my first thought is we shouldn't >> worry about them. The label-based schemes are by their nature >> designed to apply in an arbitrary context being applied to arbitrary >> objects. >> >> ...Robert > > > So I was reading through a set of slides that KaiGai has and he > mentioned a May commitfest link and I looked for the comments related to > his PGACE patches. I've been crawling through the commitfest paces so I > can figure out what the latest version of the pgace patch is. Does > anyone know when the patch was reduced to what it is today? > > Dave > I'm another SELinux developer and I'd like to help out where I can here. I'm a bit confused by this discussion of PGACE. I thought the postgresql community agreed that they wanted this removed in order to make the patch size smaller. Has that changed? Is the increase in patch size now acceptable? Sorry if I'm joining the conversation late. Thanks, Chad Sellers
On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers@tresys.com> wrote: > On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote: > >> On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote: >>> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl@tycho.nsa.gov> >>> wrote: >>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: >>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: >>>>>> As Alvaro mentioned, the original patch used ACE but it added too much >>>>>> code so the community requested its removal from the patch. It could be >>>>>> re-added if we have a need. >>>>> >>>>> Well, there's no point in putting that framework back in unless we can >>>>> make it sufficiently general that it could be used to serve the needs >>>>> of more than one security model. And so far, the signs have not been >>>>> promising. David Quigley suggests downthread that making a truly >>>>> general model isn't really possible, and he may be right, or not. I >>>>> was just mentioning that it's an angle I have been thinking about >>>>> investigating, but it may be a dead end. >>>>> >>>>> The real issue is making the code committable, and then maintaining >>>>> it, as Tom rightly says, forever. We've got to make sure that we're >>>>> willing to take that on before we do it, and I don't think it's a >>>>> small task. It isn't so much whether we want the feature as whether >>>>> the level of effort is proportionate to the benefit. >>>>> >>>>> ...Robert >>>>> >>>> >>>> So the issue with generality is that path name based MAC has a different >>>> set of requirements than label based does. If you want to acomodate >>>> several types of label based MAC models then a framework can be >>>> developed for that similar to the one in the Linux Kernel. I asked >>>> around after I sent the email yesterday and from what I understand >>>> AppArmor does not have the concept of a userspace object manager so I >>>> don't know what they'd do in this area. I'm sure they could come up with >>>> a scheme to write policy for the database but I don't know how useful it >>>> would be. >>>> >>>> If you look at the LSM framework in the Linux Kernel recently there have >>>> been hooks added to accomodate path based MAC systems so it can be done >>>> but adds another set of hooks. The important goal here though in >>>> designing a framework is to make sure that you have a comprehensive list >>>> of the objects you want to mediate and make sure you put the proper >>>> enforcement points in. Someone may come along later and want to mediate >>>> a new object or some new functionality may come along that introduces a >>>> new object so a hook may then need to be added. Something to realize as >>>> well is that a security model may not want to implement all of the hooks >>>> and it doesn't have to. In the case of no module being loaded or someone >>>> not wanting the loadable security module framework I'm sure we can >>>> provide an option to reduce overhead or compile the framework out >>>> completely. >>>> >>>> I'll take a look at his patches for the framework that KaiGai originally >>>> proposed. >>> >>> It sounds like the pathname-based schemes are not really designed to >>> work inside of a database anyway, so my first thought is we shouldn't >>> worry about them. The label-based schemes are by their nature >>> designed to apply in an arbitrary context being applied to arbitrary >>> objects. >>> >>> ...Robert >> >> >> So I was reading through a set of slides that KaiGai has and he >> mentioned a May commitfest link and I looked for the comments related to >> his PGACE patches. I've been crawling through the commitfest paces so I >> can figure out what the latest version of the pgace patch is. Does >> anyone know when the patch was reduced to what it is today? >> >> Dave >> > I'm another SELinux developer and I'd like to help out where I can here. I'm > a bit confused by this discussion of PGACE. I thought the postgresql > community agreed that they wanted this removed in order to make the patch > size smaller. Has that changed? Is the increase in patch size now > acceptable? Sorry if I'm joining the conversation late. > > Thanks, > Chad Sellers Nothing's been decided. We're just trying to figure out the best way to tackle the problem. I think the main question here is who if anyone from among the committers is willing to put in the time and effort to maintain this feature over the short and long haul, but that's sort of an internal project issue. I was just thinking out loud about whether it was possible and/or desirable to try to modularize this a bit so that it could be used for more than just SE-Linux. Obviously, the labeling stuff could be generalize to accomodate a label from an arbitrary security system, but that's only a small piece of the problem. One of the major and fundamental stumbling blocks we've run into is that every solution we've looked at so far seems to involve adding SE-Linux-specific checks in many places in the code. It would be nice if it were possible to use the exist permissions-checking functions and have them check a few more things while they're at it, but it's looking like that won't be feasible, or at least no one's come up with a plausible design yet. Consequently there are checks spread throughout the code, which definitely complicates both validation and maintenance. One question I have is - are the places where those checks are placed specific to SE-Linux, or would they be applicable to any sort of label-based MAC? ...Robert
Robert Haas <robertmhaas@gmail.com> writes: > One of the major and fundamental stumbling blocks we've run into is > that every solution we've looked at so far seems to involve adding > SE-Linux-specific checks in many places in the code. It would be nice > if it were possible to use the exist permissions-checking functions > and have them check a few more things while they're at it, but it's > looking like that won't be feasible, or at least no one's come up with > a plausible design yet. I don't think that it's about SELinux. The real issue here is that KaiGai-san is about a mile out in front of the PG hackers community in terms of his ambitions for the scope of what can be controlled by security policy. If the patch were only doing what the community has actually agreed to, there would be little need for it to touch anything but the aclcheck functions. Now I recognize that a large part of the potential attraction in this for the security community is exactly the idea of having fine-grain security control. But if you ever want anything significantly different from SQL-standard permission mechanisms, there's going to have to be a whole lot more work done. Basically, nobody in the PG community has got any confidence either in the overall design or the implementation details for locking things down that aren't already controlled by SQL permission mechanisms. regards, tom lane
On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> One of the major and fundamental stumbling blocks we've run into is >> that every solution we've looked at so far seems to involve adding >> SE-Linux-specific checks in many places in the code. It would be nice >> if it were possible to use the exist permissions-checking functions >> and have them check a few more things while they're at it, but it's >> looking like that won't be feasible, or at least no one's come up with >> a plausible design yet. > > I don't think that it's about SELinux. The real issue here is that > KaiGai-san is about a mile out in front of the PG hackers community > in terms of his ambitions for the scope of what can be controlled by > security policy. If the patch were only doing what the community has > actually agreed to, there would be little need for it to touch anything > but the aclcheck functions. > > Now I recognize that a large part of the potential attraction in this > for the security community is exactly the idea of having fine-grain > security control. But if you ever want anything significantly different > from SQL-standard permission mechanisms, there's going to have to be a > whole lot more work done. Basically, nobody in the PG community has got > any confidence either in the overall design or the implementation > details for locking things down that aren't already controlled by SQL > permission mechanisms. I think that's basically right. Further, I think this is basically a resource issue. If you were inclined to spend a large amount of your time on this problem, you could either gain confidence in the present design and implementation or come up with a new one in which you did have confidence. But it doesn't seem important enough to you (or your employer) for the amount of time it would take, so you're not. I think there are other committers and community members in a similar situation - basically all of them. ...Robert
On 12/8/09 12:36 PM, "Robert Haas" <robertmhaas@gmail.com> wrote: > On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers@tresys.com> wrote: >> On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote: >> >>> On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote: >>>> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl@tycho.nsa.gov> >>>> wrote: >>>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: >>>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote: >>>>>>> As Alvaro mentioned, the original patch used ACE but it added too much >>>>>>> code so the community requested its removal from the patch. It could be >>>>>>> re-added if we have a need. >>>>>> >>>>>> Well, there's no point in putting that framework back in unless we can >>>>>> make it sufficiently general that it could be used to serve the needs >>>>>> of more than one security model. And so far, the signs have not been >>>>>> promising. David Quigley suggests downthread that making a truly >>>>>> general model isn't really possible, and he may be right, or not. I >>>>>> was just mentioning that it's an angle I have been thinking about >>>>>> investigating, but it may be a dead end. >>>>>> >>>>>> The real issue is making the code committable, and then maintaining >>>>>> it, as Tom rightly says, forever. We've got to make sure that we're >>>>>> willing to take that on before we do it, and I don't think it's a >>>>>> small task. It isn't so much whether we want the feature as whether >>>>>> the level of effort is proportionate to the benefit. >>>>>> >>>>>> ...Robert >>>>>> >>>>> >>>>> So the issue with generality is that path name based MAC has a different >>>>> set of requirements than label based does. If you want to acomodate >>>>> several types of label based MAC models then a framework can be >>>>> developed for that similar to the one in the Linux Kernel. I asked >>>>> around after I sent the email yesterday and from what I understand >>>>> AppArmor does not have the concept of a userspace object manager so I >>>>> don't know what they'd do in this area. I'm sure they could come up with >>>>> a scheme to write policy for the database but I don't know how useful it >>>>> would be. >>>>> >>>>> If you look at the LSM framework in the Linux Kernel recently there have >>>>> been hooks added to accomodate path based MAC systems so it can be done >>>>> but adds another set of hooks. The important goal here though in >>>>> designing a framework is to make sure that you have a comprehensive list >>>>> of the objects you want to mediate and make sure you put the proper >>>>> enforcement points in. Someone may come along later and want to mediate >>>>> a new object or some new functionality may come along that introduces a >>>>> new object so a hook may then need to be added. Something to realize as >>>>> well is that a security model may not want to implement all of the hooks >>>>> and it doesn't have to. In the case of no module being loaded or someone >>>>> not wanting the loadable security module framework I'm sure we can >>>>> provide an option to reduce overhead or compile the framework out >>>>> completely. >>>>> >>>>> I'll take a look at his patches for the framework that KaiGai originally >>>>> proposed. >>>> >>>> It sounds like the pathname-based schemes are not really designed to >>>> work inside of a database anyway, so my first thought is we shouldn't >>>> worry about them. The label-based schemes are by their nature >>>> designed to apply in an arbitrary context being applied to arbitrary >>>> objects. >>>> >>>> ...Robert >>> >>> >>> So I was reading through a set of slides that KaiGai has and he >>> mentioned a May commitfest link and I looked for the comments related to >>> his PGACE patches. I've been crawling through the commitfest paces so I >>> can figure out what the latest version of the pgace patch is. Does >>> anyone know when the patch was reduced to what it is today? >>> >>> Dave >>> >> I'm another SELinux developer and I'd like to help out where I can here. I'm >> a bit confused by this discussion of PGACE. I thought the postgresql >> community agreed that they wanted this removed in order to make the patch >> size smaller. Has that changed? Is the increase in patch size now >> acceptable? Sorry if I'm joining the conversation late. >> >> Thanks, >> Chad Sellers > > Nothing's been decided. Sorry, my mistake. This mailing list moves pretty quick so it's hard to catch up with everything. > We're just trying to figure out the best way > to tackle the problem. I think the main question here is who if > anyone from among the committers is willing to put in the time and > effort to maintain this feature over the short and long haul, but > that's sort of an internal project issue. I was just thinking out > loud about whether it was possible and/or desirable to try to > modularize this a bit so that it could be used for more than just > SE-Linux. So, a generalized framework is nice in that it supports multiple models, but it does bring with it an additional maintenance burden. I'm sure that's been discussed at length already. I will say that it's almost impossible to place hooks properly for imaginary users. So, if you create a framework, it's probably just a placeholder with hooks for the one user (SEPostgreSQL) that will later have to be modified/augmented to support additional users. This is how things went with LSM. LSM was added to Linux and created with input from several users (SELinux folks, Immunix (later AppArmor) folks, and others) and still took years before most of the other mechanisms could use it without extra patches. If you're trying to build a generalized access control framework with only one user, it will have to change the day user 2 comes along. > Obviously, the labeling stuff could be generalize to > accomodate a label from an arbitrary security system, but that's only > a small piece of the problem. > > One of the major and fundamental stumbling blocks we've run into is > that every solution we've looked at so far seems to involve adding > SE-Linux-specific checks in many places in the code. It would be nice > if it were possible to use the exist permissions-checking functions > and have them check a few more things while they're at it, but it's > looking like that won't be feasible, or at least no one's come up with > a plausible design yet. That's not surprising. If you look at the experience from adding access control hooks to the Linux kernel (both the initial patchset that added SELinux hooks directly, and the LSM hooks) as well as the XACE hooks added to X.org, you'll find similar experiences. > Consequently there are checks spread > throughout the code, which definitely complicates both validation and > maintenance. One question I have is - are the places where those > checks are placed specific to SE-Linux, or would they be applicable to > any sort of label-based MAC? > My guess would be most of them are applicable to most sorts of label-based MAC. While LSM needed work to be used by the path-based systems out there, SMACK (which uses labels of a different ilk) required very few (maybe no?) changes to LSM to work. Looking through the hooks, I see very little that doesn't look like it would not work for some other label-based systems (though possibly not all). Thanks, Chad Sellers
On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: > On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> One of the major and fundamental stumbling blocks we've run into is > >> that every solution we've looked at so far seems to involve adding > >> SE-Linux-specific checks in many places in the code. It would be nice > >> if it were possible to use the exist permissions-checking functions > >> and have them check a few more things while they're at it, but it's > >> looking like that won't be feasible, or at least no one's come up with > >> a plausible design yet. > > > > I don't think that it's about SELinux. The real issue here is that > > KaiGai-san is about a mile out in front of the PG hackers community > > in terms of his ambitions for the scope of what can be controlled by > > security policy. If the patch were only doing what the community has > > actually agreed to, there would be little need for it to touch anything > > but the aclcheck functions. > > > > Now I recognize that a large part of the potential attraction in this > > for the security community is exactly the idea of having fine-grain > > security control. But if you ever want anything significantly different > > from SQL-standard permission mechanisms, there's going to have to be a > > whole lot more work done. Basically, nobody in the PG community has got > > any confidence either in the overall design or the implementation > > details for locking things down that aren't already controlled by SQL > > permission mechanisms. > > I think that's basically right. Further, I think this is basically a > resource issue. If you were inclined to spend a large amount of your > time on this problem, you could either gain confidence in the present > design and implementation or come up with a new one in which you did > have confidence. But it doesn't seem important enough to you (or your > employer) for the amount of time it would take, so you're not. I > think there are other committers and community members in a similar > situation - basically all of them. > > ...Robert > I have to agree with Chad (downthread) that I don't see much in KaiGai's hook patch that prevents its use by other security models. I will say though one thing that might have been done wrong was with how it was presented. In actuality his patch set is two projects (at least). The first is the framework. So I think the goal should have been to get the framework integrated first and then work on the SELinux module after that. The framework patch alone consists of at least 4 sets of logical changes that could have been separated to make review easier. Once the framework was in, work could be done to get the SELinux module in while reducing overhead from the case where no module is loaded. So with regard to confidence in the design I think that part of the reason for the skepticism in the fact that it was such a large code drop. Even the separated parts were very large. I think if the framework patches are broken up more logically and in a way that is easier to discuss then that might help the community get a grasp on what it is trying to accomplish. In terms of documentation I was reading through the wiki at sepgsql.googlecode.com and aside from some wordsmithing/grammar things it is pretty solid with describing what it is trying to accomplish. One problem that I see is that at first glance it does appear to be very SELinux centric. It describes access based on types and SELinux contexts which is understandable based on the fact that it describes the framework and the module. Something to note is that the documentation describes an object model for the program. I think that would be a good place to focus the discussion with respect to a framework if we decide to pursue it. Dave
* Robert Haas (robertmhaas@gmail.com) wrote: > One of the major and fundamental stumbling blocks we've run into is > that every solution we've looked at so far seems to involve adding > SE-Linux-specific checks in many places in the code. I've really got to take exception to this. I've only been following along and not really participating because, to be honest, I'm frustrated with how this has gone down. In the end there were at least two patches, in my view, that *didn't* involve adding SE-Linux-specific checks everywhere. The patch that I reviewed that got thrown out by Tom, and the original PGACE framework. Both of those added alot of *hooks*, because they were necessary, but nothing made those hooks particularly "SELinux-specifc". We're hearing alot about things being SELinux-specific from people who also profess to not know SELinux. Indeed, as I recall, the patch I reviewed was primairly trying to just addess pulling out the hooks necessary for the existing PostgreSQL security model. Very little of it was SE-Linux specific *anything*. I contend that while the specific hooks which would be added *in places that don't already have checks* (in most places, the hook was added to replace an existing check) are hooks that then make sense for SELinux, they would also make sense for other frameworks. They may also not be a complete list, but once the *framework* is in place, adding new hooks (presuming another model would like a hook somewhere that SELinux and the existing PG security framework don't) should not require some kind of forklift upgrade. > It would be nice > if it were possible to use the exist permissions-checking functions > and have them check a few more things while they're at it, but it's > looking like that won't be feasible, or at least no one's come up with > a plausible design yet. The problem is that the existing permissions-checking is done all over the place. That's not ideal from the get-go, in my opinion. Unfortuantely, when we moved all of the permissions-checking to a single place, it required knowing about alot of the backend, which Tom took exception to. I agree that's frustrating, but I don't see it as a particular reason to throw out the entire concept of a modular security framework. Perhaps we need to better expose just those pieces the security framework cares about from the other parts of the backend- it's entirely likely that the reason it has to know about everything is that, due to where all the existing security checks are, they just (ab)used the fact that they had access to that information at hand for that object type. > Consequently there are checks spread > throughout the code, which definitely complicates both validation and > maintenance. One question I have is - are the places where those > checks are placed specific to SE-Linux, or would they be applicable to > any sort of label-based MAC? The patch which I worked with Kaigai on was specifically geared to first try to get a patch which addressed the existing PG security model in a modular way, to allow additional hooks to be added later in places which needed them, and to provide the information for other models to make a decision about the permission. I don't feel it was particularly SE-Linux specific at all, but rather a first step towards being able to support something beyond the model we have today (anything..). Thanks, Stephen
On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: > On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: >> On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > Robert Haas <robertmhaas@gmail.com> writes: >> >> One of the major and fundamental stumbling blocks we've run into is >> >> that every solution we've looked at so far seems to involve adding >> >> SE-Linux-specific checks in many places in the code. It would be nice >> >> if it were possible to use the exist permissions-checking functions >> >> and have them check a few more things while they're at it, but it's >> >> looking like that won't be feasible, or at least no one's come up with >> >> a plausible design yet. >> > >> > I don't think that it's about SELinux. The real issue here is that >> > KaiGai-san is about a mile out in front of the PG hackers community >> > in terms of his ambitions for the scope of what can be controlled by >> > security policy. If the patch were only doing what the community has >> > actually agreed to, there would be little need for it to touch anything >> > but the aclcheck functions. >> > >> > Now I recognize that a large part of the potential attraction in this >> > for the security community is exactly the idea of having fine-grain >> > security control. But if you ever want anything significantly different >> > from SQL-standard permission mechanisms, there's going to have to be a >> > whole lot more work done. Basically, nobody in the PG community has got >> > any confidence either in the overall design or the implementation >> > details for locking things down that aren't already controlled by SQL >> > permission mechanisms. >> >> I think that's basically right. Further, I think this is basically a >> resource issue. If you were inclined to spend a large amount of your >> time on this problem, you could either gain confidence in the present >> design and implementation or come up with a new one in which you did >> have confidence. But it doesn't seem important enough to you (or your >> employer) for the amount of time it would take, so you're not. I >> think there are other committers and community members in a similar >> situation - basically all of them. > > I have to agree with Chad (downthread) that I don't see much in KaiGai's > hook patch that prevents its use by other security models. I will say > though one thing that might have been done wrong was with how it was > presented. In actuality his patch set is two projects (at least). The > first is the framework. So I think the goal should have been to get the > framework integrated first and then work on the SELinux module after > that. The framework patch alone consists of at least 4 sets of logical > changes that could have been separated to make review easier. Once the > framework was in, work could be done to get the SELinux module in while > reducing overhead from the case where no module is loaded. I can say from experience that this project is very skeptical of frameworks that aren't accompanied by at least one, and preferably multiple, working implementations. So there is a bit of a chicken and egg problem here. What can sometimes work is to say, look, here's a place where I can put a hook and later I will do something complex with it but here are a couple of relatively simple but useful examples to get started. The examples form the justification for the commit because they are independently useful, but they are much simpler than what the framework may eventually end up being used for. I don't believe that this approach is feasible for SE-PostgreSQL. A simple version of label security is still going to be very complicated, and there are probably even fewer customers for such a thing than there are for SE-PostgreSQL. > So with regard to confidence in the design I think that part of the > reason for the skepticism in the fact that it was such a large code > drop. Even the separated parts were very large. Definitely true. > I think if the framework > patches are broken up more logically and in a way that is easier to > discuss then that might help the community get a grasp on what it is > trying to accomplish. Maybe, maybe not. Nobody's going to commit anything unless it's a complete feature. It can be a cut-down feature, but it has to be of independent use. If there are parts that can be peeled off of SE-PostgreSQL and committed independently to some good benefit, then I think that's a great idea. But if it's just a separation of the patch for clarity, I don't think there's much value in that. > In terms of documentation I was reading through the wiki at > sepgsql.googlecode.com and aside from some wordsmithing/grammar things > it is pretty solid with describing what it is trying to accomplish. One > problem that I see is that at first glance it does appear to be very > SELinux centric. It describes access based on types and SELinux contexts > which is understandable based on the fact that it describes the > framework and the module. Something to note is that the documentation > describes an object model for the program. I think that would be a good > place to focus the discussion with respect to a framework if we decide > to pursue it. I have proofread earlier versions of the docs and found them inadequate. There were language issues, but the bigger problem was that they were both too specific and yet not sufficiently detailed. For example, they'd say "install X package on Red Hat". Well, what if I'm not on Red Hat? The on the other hand they'd say "this GUC enables mcstrans" which means nothing to me. I think this has been improved somewhat in more recent version, but clearly we need (1) good developer documentation, so someone other than KaiGai has a chance of maintaining the code and keeping it correct as other things are changed; (2) user documentation, so that someone can read the "feature story" for this capability; and (3) reference documentation, cross-referenced with the user documentation. Having said that, fixing the documentation won't get this patch committed, though it's certainly a step in the right direction. For that we need a committer-owner. ...Robert
On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: > > One of the major and fundamental stumbling blocks we've run into is > > that every solution we've looked at so far seems to involve adding > > SE-Linux-specific checks in many places in the code. > > I've really got to take exception to this. I've only been following > along and not really participating because, to be honest, I'm frustrated > with how this has gone down. In the end there were at least two > patches, in my view, that *didn't* involve adding SE-Linux-specific > checks everywhere. The patch that I reviewed that got thrown out by > Tom, and the original PGACE framework. Both of those added alot of > *hooks*, because they were necessary, but nothing made those hooks > particularly "SELinux-specifc". We're hearing alot about things being > SELinux-specific from people who also profess to not know SELinux. > > Indeed, as I recall, the patch I reviewed was primairly trying to just > addess pulling out the hooks necessary for the existing PostgreSQL > security model. Very little of it was SE-Linux specific *anything*. > > I contend that while the specific hooks which would be added *in > places that don't already have checks* (in most places, the hook was > added to replace an existing check) are hooks that then make sense > for SELinux, they would also make sense for other frameworks. They > may also not be a complete list, but once the *framework* is in > place, adding new hooks (presuming another model would like a hook > somewhere that SELinux and the existing PG security framework don't) > should not require some kind of forklift upgrade. > > > It would be nice > > if it were possible to use the exist permissions-checking functions > > and have them check a few more things while they're at it, but it's > > looking like that won't be feasible, or at least no one's come up with > > a plausible design yet. > > The problem is that the existing permissions-checking is done all over > the place. That's not ideal from the get-go, in my opinion. > Unfortuantely, when we moved all of the permissions-checking to a single > place, it required knowing about alot of the backend, which Tom took > exception to. I agree that's frustrating, but I don't see it as a > particular reason to throw out the entire concept of a modular security > framework. Perhaps we need to better expose just those pieces the > security framework cares about from the other parts of the backend- it's > entirely likely that the reason it has to know about everything is that, > due to where all the existing security checks are, they just (ab)used > the fact that they had access to that information at hand for that > object type. > > > Consequently there are checks spread > > throughout the code, which definitely complicates both validation and > > maintenance. One question I have is - are the places where those > > checks are placed specific to SE-Linux, or would they be applicable to > > any sort of label-based MAC? > > The patch which I worked with Kaigai on was specifically geared to first > try to get a patch which addressed the existing PG security model in a > modular way, to allow additional hooks to be added later in places which > needed them, and to provide the information for other models to make a > decision about the permission. I don't feel it was particularly > SE-Linux specific at all, but rather a first step towards being able to > support something beyond the model we have today (anything..). > > Thanks, > > Stephen I think what makes people think that the changes are SELinux specific is that the examples given use SELinux contexts. I think it should be made clear that saying that in the PG there is a database object and we want to mediate access to create database objects is not SELinux or even MAC model specific (asside from labels). However to say that a program labeled myapp_t can connect to the database and create a table and when its created its labeled mytable_t that would be something SELinux specific. The framework idea separates that. It says hey here are the objects in the system and here are the actions on them that we want to mediate. I will admit that since SELinux is the driving MAC model for the framework you're going to find that the objects and permissions are the ones that it wants to control. However like Steven said, adding a hook later on or having a model not use a hook is not a Herculean task. We've proven time and time again with the LSM framework that when a feature is added it is trivial to introduce a new hook to mediate it or to place an existing hook. I understand that PostgreSQL is a fast moving target with a large developer base but so is the Linux Kernel and a similar framework has been working there for years now. Dave
On mån, 2009-12-07 at 17:33 +0100, Martijn van Oosterhout wrote: > On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote: > > > Given the extreme patience and diligence exhibited by KaiGai, I > > > hesitate to say this, but it seems to me that this would be > > > critically important for the long term success of this feature. I > > > have no idea how much work it would be to make the interface to the > > > external security system pluggable, but if it's at all feasible, I > > > think it should be done. > > > > This is how the code was developed initially -- the patch was called > > PGACE and SELinux was but the first implementation on top of it. > > I find it astonishing that after SE-PgSQL was implemented on top of a > pluggable system (PGACE) and this system was removed at request of the > "community" [1] that at this late phase people are suggesting it needs > to be added back again. Havn't the goalposts been moved enough times? PGACE wasn't a plugin system. It was an API inside the core code. If it had been a plugin system, this would have been much easier, because the plugin itself could have been developed independently.
On mån, 2009-12-07 at 11:45 -0500, Chris Browne wrote: > I feel about the same way about this as I did about the adding of > "native Windows" support; I'm a bit concerned that this could be a > destabilizing influence. I was wrong back then; the Windows support > hasn't had the ill effects I was concerned it might have. Windows support certainly has had ill effects, but the benefits of supporting Windows clearly outweigh that.
On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> One of the major and fundamental stumbling blocks we've run into is >> that every solution we've looked at so far seems to involve adding >> SE-Linux-specific checks in many places in the code. > > I've really got to take exception to this. I've only been following > along and not really participating because, to be honest, I'm frustrated > with how this has gone down. In the end there were at least two > patches, in my view, that *didn't* involve adding SE-Linux-specific > checks everywhere. The patch that I reviewed that got thrown out by > Tom, and the original PGACE framework. Both of those added alot of > *hooks*, because they were necessary, but nothing made those hooks > particularly "SELinux-specifc". We're hearing alot about things being > SELinux-specific from people who also profess to not know SELinux. Sorry. I spent a lot of time for both CommitFest 2008-11 and CommitFest 2009-07 in the hopes of getting something committable, and I wasn't successful. I'm just at the end of my rope. It seems fairly clear that Tom isn't going to commit any piece of SE-PostgreSQL at all, ever. So who's going to do it? It doesn't make any sense to continue trucking along with this patch into the indefinite future if it has no hope of being committed. Frankly, I think this comes down to money. There are several PostgreSQL companies which employ very capable PostgreSQL committers. When someone is willing to pony up enough money to get those people interested (as, I gather, has happened with block-checksumming) then this will happen. Until then, I don't believe anyone is going to volunteer to be responsible for a 10,000-line patch in their free time. Tom is the only one crazy enough for that, and he said no. The next time someone submits a huge, unsolicited patch to do ANYTHING, we should do them a favor and tell them this up front, rather than a year and a half later. Then they could have the appropriate conversations with the appropriate people and determine whether to budget for it or give up. What has happened with this patch has not served KaiGai well, or improved the image of this community. > I agree that's frustrating, but I don't see it as a > particular reason to throw out the entire concept of a modular security > framework. I don't either. There were certainly technical things in the previous patch that could stand to have been improved, and I think the general approach has some potential. ...Robert
On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote: [snip...] > > I can say from experience that this project is very skeptical of > frameworks that aren't accompanied by at least one, and preferably > multiple, working implementations. So there is a bit of a chicken and > egg problem here. What can sometimes work is to say, look, here's a > place where I can put a hook and later I will do something complex > with it but here are a couple of relatively simple but useful examples > to get started. The examples form the justification for the commit > because they are independently useful, but they are much simpler than > what the framework may eventually end up being used for. > > I don't believe that this approach is feasible for SE-PostgreSQL. A > simple version of label security is still going to be very > complicated, and there are probably even fewer customers for such a > thing than there are for SE-PostgreSQL. > Ok if it is a chicken and egg problem then we need to find a smaller egg. I agree that having a huge patch set isn't ideal which is why I understand the desire to have KaiGai cut back his patches. However the patches he is putting forward from what I've gathered have no row based labeling and no MAC enforcement. I can understand if you want to cut back the object model so you're not mediating every object in the system but cutting those two features make it unusable by the customers we have who want to use it. > > So with regard to confidence in the design I think that part of the > > reason for the skepticism in the fact that it was such a large code > > drop. Even the separated parts were very large. > > Definitely true. > > > I think if the framework > > patches are broken up more logically and in a way that is easier to > > discuss then that might help the community get a grasp on what it is > > trying to accomplish. > > Maybe, maybe not. Nobody's going to commit anything unless it's a > complete feature. It can be a cut-down feature, but it has to be of > independent use. If there are parts that can be peeled off of > SE-PostgreSQL and committed independently to some good benefit, then I > think that's a great idea. But if it's just a separation of the patch > for clarity, I don't think there's much value in that. I don't think it would be just for clarity. I know that not all open source communities are the same so I'll try to leave the anecdotal evidence light. When submit patches for the Linux Kernel we take a single feature and structure them as self contained logical changes. Separating the changes logically doesn't just improve clarity but also makes it easy to cherry pick features that can be useful on their own. Just because the framework and the SEPostgreSQL features would be two patch sets doesn't mean they aren't being developed in parallel. It looks to me that we're in the same boat we were in with SELinux. We had the feature and proposed it and someone brought up "well what about other security models". So time was spent developing a framework that everyone could use and as that was being done the SELinux patches were modified to use this new framework. They were two separate features developed in tandem. If we do it right the SEPostgreSQL code will be isolated from the framework and we can spend time putting the framework in and just plug in the specific security module when time comes. The X-ACE work went in to X before the corresponding SELinux Flask module for it and I don't believe LSM and SELinux went into the same merge window as well. > > I have proofread earlier versions of the docs and found them > inadequate. There were language issues, but the bigger problem was > that they were both too specific and yet not sufficiently detailed. > For example, they'd say "install X package on Red Hat". Well, what if > I'm not on Red Hat? The on the other hand they'd say "this GUC > enables mcstrans" which means nothing to me. I think this has been > improved somewhat in more recent version, but clearly we need (1) good > developer documentation, so someone other than KaiGai has a chance of > maintaining the code and keeping it correct as other things are > changed; (2) user documentation, so that someone can read the "feature > story" for this capability; and (3) reference documentation, > cross-referenced with the user documentation. > > Having said that, fixing the documentation won't get this patch > committed, though it's certainly a step in the right direction. For > that we need a committer-owner. > True but hopefully proper documentation will help someone decide that they have enough information to take on that position. > ...Robert
Peter Eisentraut <peter_e@gmx.net> writes: > PGACE wasn't a plugin system. It was an API inside the core code. If > it had been a plugin system, this would have been much easier, because > the plugin itself could have been developed independently. Well, it should certainly have used function pointers or something to allow better pluggability, but that would have been a trivial change. I don't believe that doing so would have made development any easier. The real problem in all this is to answer the question "do we have the right hooks in the right places?". Whether the hooks lead to function pointers or hard-wired calls doesn't enter into that. Moreover, since we can confidently say that all the early answers will be "no", it would be a serious mistake to try to develop the plugin independently. Having to keep two independent sets of source code in sync would waste a lot of effort every time you realized you needed to adjust the hook definitions. Once you'd gotten to a releasable state maybe you could assume the hook definitions would become stable, but right now I have no confidence in that at all. regards, tom lane
On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > PGACE wasn't a plugin system. It was an API inside the core code. If > > it had been a plugin system, this would have been much easier, because > > the plugin itself could have been developed independently. > > Well, it should certainly have used function pointers or something to > allow better pluggability, but that would have been a trivial change. > I don't believe that doing so would have made development any easier. > The real problem in all this is to answer the question "do we have the > right hooks in the right places?". Whether the hooks lead to function > pointers or hard-wired calls doesn't enter into that. Moreover, since > we can confidently say that all the early answers will be "no", it would > be a serious mistake to try to develop the plugin independently. > Having to keep two independent sets of source code in sync would waste > a lot of effort every time you realized you needed to adjust the hook > definitions. Once you'd gotten to a releasable state maybe you could > assume the hook definitions would become stable, but right now I have no > confidence in that at all. > > regards, tom lane > I disagree with several of your statements above. While the question of whether or not the hooks are in the right place is up for debate what the hooks should be is something that I think has been explored pretty well. The hooks should reflect the object model. Where you need to put them to enforce permission is a different story. Also maintaining a module and a framework is not a waste of time. If your security module has a tremendous code churn when the interface to the program is modified you should reevaluate your design. Both SELinux and the Flask X-ACE modules are examples where an existing extension had a modular framework developed after the fact and easily integrated into the project. The majority of the work is moving to a framework not changing function prototypes in code that's already in the framework. Dave
Robert Haas wrote: > On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: >> I'd be willing to take a look at the framework and see if it really is >> SELinux centric. If it is we can figure out if there is a way to >> accomodate something like SMACK and FMAC. I'd like to hear from someone >> with more extensive experience with Solaris Trusted Extensions about how >> TX would make use of this. I have a feeling it would be similar to the >> way it deals with NFS which is by having the process exist in the global >> zone as a privileged process and then multi-plexes it to the remaining >> zones. That way their getpeercon would get a label derived from the >> zone. > > Well, the old patches should still be available in the mailing list > archives. Maybe going back and looking at that code would be a good > place to start. The non-ripped-out code has been cleaned up a lot > since then, but at least it's a place to start. We can see old branches here: http://code.google.com/p/sepgsql/source/browse/branches/pgsql-8.3.x/sepgsql/src/backend/security/pgaceHooks.c But I don't provide this framework for the 8.4.x/8.5.x, because this idea was rejected in the earlier discussion. Please consider it represent just a concept. Thanks. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Robert Haas wrote: > Sorry. I spent a lot of time for both CommitFest 2008-11 and > CommitFest 2009-07 in the hopes of getting something committable, and > I wasn't successful. I'm just at the end of my rope. It seems fairly > clear that Tom isn't going to commit any piece of SE-PostgreSQL at > all, ever. So who's going to do it? It doesn't make any sense to > continue trucking along with this patch into the indefinite future if > it has no hope of being committed. > > Frankly, I think this comes down to money. There are several > PostgreSQL companies which employ very capable PostgreSQL committers. > When someone is willing to pony up enough money to get those people > interested (as, I gather, has happened with block-checksumming) then > this will happen. Until then, I don't believe anyone is going to > volunteer to be responsible for a 10,000-line patch in their free > time. Tom is the only one crazy enough for that, and he said no. I have offered to review/commit the patch. I don't promise my effort will be pretty, but I will get the job done. I have not started yet because I think we are still unclear if the feature is worth the additional code maintenance. I frankly think the patch should be thought of as the SE-Linux-specific directory files, which KaiGai can maintain, and the other parts, which I think I can handle. > The next time someone submits a huge, unsolicited patch to do > ANYTHING, we should do them a favor and tell them this up front, > rather than a year and a half later. Then they could have the > appropriate conversations with the appropriate people and determine > whether to budget for it or give up. What has happened with this > patch has not served KaiGai well, or improved the image of this > community. Yes, this has not been our finest hour. :-( I think the causes have been explained already: o early patches did not have community buy-ino we are unclear about the size of the user communityo we are unclear whatthe end user will wanto the feature is complexo the features is in an unfamiliar problem-domain -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
David P. Quigley wrote: > So I was reading through a set of slides that KaiGai has and he > mentioned a May commitfest link and I looked for the comments related to > his PGACE patches. I've been crawling through the commitfest paces so I > can figure out what the latest version of the pgace patch is. Does > anyone know when the patch was reduced to what it is today? I could salvage a legacy PGACE patch: http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch However, its code base was v8.4devel, so conflictable to the latest CVS HEAD. In addition, it contains various kind of concepts within a single patch.* comprehensive security hooks* a facility to storesecurity identifier on the header of each row* a facility to translate between security identifier (int) and securitycontext (text)* "security_context" writable system column support. From the current perspective, we can understand these features should be proposed as separated features. But I was young. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
David P. Quigley wrote: > I understand that PostgreSQL is a fast moving target with a large developer base but so is the Linux Kernel and a > similar framework has been working there for years now. > It sounds like how you're thinking about this project's development model is inverted from the reality, and it's import to sort that out because it really impacts why there's so much resistance here. One reason the Linux kernel moves so fast because they don't care one lick for many types of backward compatibility, they'll just change interfaces as necessary to work around problems. To use the terms of the old 2.4 Linux kernel, there is no "stable" branch development happens against anymore; just the fast changing unstable one, that if everyone is lucky eventually converges into some usable versions anyway. Here, there is zero tolerance for any commit that destabilizes the codebase even temporarily. Until you get the whole thing sorted out usefully enough to be shippable quality, you don't go into the main (and only official) branch. Also, the PostgreSQL developers like to deliver a stable release and then change *nothing* to it except to fix bugs, supporting that release for years. We consider a released piece of software like a contract to the users, and everyone goes through lots of work to avoid changing anything unless absolutely necessary. A very large component of the concern here comes from that mindset. If this goes out, and there's a fundamental problem with it, this community doesn't even have a good process to fix that until the next major release, around a year later. In general, there is no such thing as an upgrade to a stable version that includes a serious behavior change. Having that happen is considered a major breakdown in the process, and there's only been a very small number of such situations in the past, when some just impossible to work around bug was introduced. Instead, just the absolute minimum of changes needed to fix bugs are applied to the stable, shipped versions. If a version ships with a broken enough behavior, it's quite possible that fixing it cannot be done in a way that can be distributed and applied via the standard minor version upgrade procedure used at all. The idea here is not "if it's not quite right, development is fast so it will get sorted out eventually". Instead it's "if it's not believed to be free of non-trivial bugs, don't commit it at all". SEPostgres has lived in this state for a while now. And it's not known bugs that are the problem, it's that almost all of the Postgres community can't even accurately gauge whether there are bugs or not in the code/design, which is really uncomfortable given how things work here. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
David P. Quigley wrote: > On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote: > [snip...] >> I can say from experience that this project is very skeptical of >> frameworks that aren't accompanied by at least one, and preferably >> multiple, working implementations. So there is a bit of a chicken and >> egg problem here. What can sometimes work is to say, look, here's a >> place where I can put a hook and later I will do something complex >> with it but here are a couple of relatively simple but useful examples >> to get started. The examples form the justification for the commit >> because they are independently useful, but they are much simpler than >> what the framework may eventually end up being used for. >> >> I don't believe that this approach is feasible for SE-PostgreSQL. A >> simple version of label security is still going to be very >> complicated, and there are probably even fewer customers for such a >> thing than there are for SE-PostgreSQL. >> > > Ok if it is a chicken and egg problem then we need to find a smaller > egg. I agree that having a huge patch set isn't ideal which is why I > understand the desire to have KaiGai cut back his patches. However the > patches he is putting forward from what I've gathered have no row based > labeling and no MAC enforcement. I can understand if you want to cut > back the object model so you're not mediating every object in the system > but cutting those two features make it unusable by the customers we have > who want to use it. The coverage of access controls are tradeoff between amount of the changeset and valuable functionalities, in generally. Ultimately it is a role of developer to decide what is unseparatable core feture and what is separatable secondary one. It is my decision to restrict types of database objects to reduce burden of reviewers, so the latest one apply SELinux specific access controls on only databases, schemas, tables and columns. Even if we have a framework to host label-based MAC, its coverage shall be unchanged, because comprehensive support at once obviously makes harder to review. >>> So with regard to confidence in the design I think that part of the >>> reason for the skepticism in the fact that it was such a large code >>> drop. Even the separated parts were very large. >> Definitely true. >> >>> I think if the framework >>> patches are broken up more logically and in a way that is easier to >>> discuss then that might help the community get a grasp on what it is >>> trying to accomplish. >> Maybe, maybe not. Nobody's going to commit anything unless it's a >> complete feature. It can be a cut-down feature, but it has to be of >> independent use. If there are parts that can be peeled off of >> SE-PostgreSQL and committed independently to some good benefit, then I >> think that's a great idea. But if it's just a separation of the patch >> for clarity, I don't think there's much value in that. > > I don't think it would be just for clarity. I know that not all open > source communities are the same so I'll try to leave the anecdotal > evidence light. When submit patches for the Linux Kernel we take a > single feature and structure them as self contained logical changes. > Separating the changes logically doesn't just improve clarity but also > makes it easy to cherry pick features that can be useful on their own. > Just because the framework and the SEPostgreSQL features would be two > patch sets doesn't mean they aren't being developed in parallel. It > looks to me that we're in the same boat we were in with SELinux. We had > the feature and proposed it and someone brought up "well what about > other security models". So time was spent developing a framework that > everyone could use and as that was being done the SELinux patches were > modified to use this new framework. They were two separate features > developed in tandem. If we do it right the SEPostgreSQL code will be > isolated from the framework and we can spend time putting the framework > in and just plug in the specific security module when time comes. The > X-ACE work went in to X before the corresponding SELinux Flask module > for it and I don't believe LSM and SELinux went into the same merge > window as well. It is necessary to deploy the framework and SELinux support at same time or the framework earlier than SELinux? We can organize a common framework when the second security module will come in. From our experience, it may need similar security hooks on same or similar strategic points. In the development history, the code size and complexity had been a matter for inclusion. I also think the idea to invoke security modules via mac framework is right approach, but it increases the initial code size compared to the current approach in spite of even user visible whorth. >> I have proofread earlier versions of the docs and found them >> inadequate. There were language issues, but the bigger problem was >> that they were both too specific and yet not sufficiently detailed. >> For example, they'd say "install X package on Red Hat". Well, what if >> I'm not on Red Hat? The on the other hand they'd say "this GUC >> enables mcstrans" which means nothing to me. I think this has been >> improved somewhat in more recent version, but clearly we need (1) good >> developer documentation, so someone other than KaiGai has a chance of >> maintaining the code and keeping it correct as other things are >> changed; (2) user documentation, so that someone can read the "feature >> story" for this capability; and (3) reference documentation, >> cross-referenced with the user documentation. >> >> Having said that, fixing the documentation won't get this patch >> committed, though it's certainly a step in the right direction. For >> that we need a committer-owner. >> > > True but hopefully proper documentation will help someone decide that > they have enough information to take on that position. If you have any concern about documentations, I very welcome any feedbacks. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
2009/12/9 Bruce Momjian <bruce@momjian.us>: > I frankly think the patch should be thought of as the SE-Linux-specific > directory files, which KaiGai can maintain, and the other parts, which I > think I can handle. I think that's a horribly bad idea. We have already got a similar issue with ECPG, which clearly stagnates whenever Michael is busy and don't have time to go through the patches. Because it's "his code", and nobody else knows how to and/or cares to maintain it. And this is just a single piece of the frontend that doesn't affect anything else. If you want to do something similar for sepg, then sepg needs to be turned into a full plugin system, where the plugin is a completely separate thing. In which case the plugin can be developed separately, for example on pgfoundry (and be considered to merge later, if we want, but not necessarily ever since it has a narrow user base). I haven't looked at the patch properly for quite a while, but I imagine turning it into such a plugin is not feasible. Because if it is, why haven't this been done already? :) But if it is, perhaps that is something we should consider, since it lessens the maintenance burden into "just" the API (which is still a huge burden compared to many of our APIs, but it is a lot less than what the patch is now) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> One of the major and fundamental stumbling blocks we've run into is >> that every solution we've looked at so far seems to involve adding >> SE-Linux-specific checks in many places in the code. > > I've really got to take exception to this. I've only been following > along and not really participating because, to be honest, I'm frustrated > with how this has gone down. In the end there were at least two > patches, in my view, that *didn't* involve adding SE-Linux-specific > checks everywhere. The patch that I reviewed that got thrown out by > Tom, and the original PGACE framework. Both of those added alot of > *hooks*, because they were necessary, but nothing made those hooks > particularly "SELinux-specifc". We're hearing alot about things being > SELinux-specific from people who also profess to not know SELinux. > > Indeed, as I recall, the patch I reviewed was primairly trying to just > addess pulling out the hooks necessary for the existing PostgreSQL > security model. Very little of it was SE-Linux specific *anything*. > > I contend that while the specific hooks which would be added *in > places that don't already have checks* (in most places, the hook was > added to replace an existing check) are hooks that then make sense > for SELinux, they would also make sense for other frameworks. They > may also not be a complete list, but once the *framework* is in > place, adding new hooks (presuming another model would like a hook > somewhere that SELinux and the existing PG security framework don't) > should not require some kind of forklift upgrade. Basically, I don't think it is a bad idea to provide a framework to host multiple label-based security mechanisms, because they have same origin so they have similar features, such as security label and policy. However, we have a tradeoff betweem an ideal image (multiple enhanced security stuff can be launched via common hooks) and amount of changeset. The latest SE-PgSQL/Lite patch support only four kind of database objects (databases, schemas, tables and columns), so it puts security hooks on the strategic points corresponding to these objects, such as createdb(). If we simply replace the invocations by the common hooks, coverage of the framework will be restricted to these four objects. Is it possible to call them as a framework? If it will be comprehensive from the first, we shall face a nightmare again. I think we can replace the sepgsql_*() invocations by the framework when the second enhancement (such as Solaris-TX?) will come in. Note that label-based security has historically same origin, so we can expect much smaller arrangement than integration DAC and MAC. >> Consequently there are checks spread >> throughout the code, which definitely complicates both validation and >> maintenance. One question I have is - are the places where those >> checks are placed specific to SE-Linux, or would they be applicable to >> any sort of label-based MAC? > > The patch which I worked with Kaigai on was specifically geared to first > try to get a patch which addressed the existing PG security model in a > modular way, to allow additional hooks to be added later in places which > needed them, and to provide the information for other models to make a > decision about the permission. I don't feel it was particularly > SE-Linux specific at all, but rather a first step towards being able to > support something beyond the model we have today (anything..). Right, the default PG model has been already comprehensive, and has a different origin from label-based securities, so we needed massive changeset to organize both of DAC (the default PG model) and MAC into a common security framework. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus@hagander.net> wrote: > 2009/12/9 Bruce Momjian <bruce@momjian.us>: >> I frankly think the patch should be thought of as the SE-Linux-specific >> directory files, which KaiGai can maintain, and the other parts, which I >> think I can handle. > > I think that's a horribly bad idea. Me, too. The ECPG comparison is apt, except that this code is far more deeply integrated into core. The idea that the SE-Linux directory files can be maintained separately from the "other parts" does not seem realistic to me. The problems that are going to occur here are things like: somebody wants to rearrange some part of the permissions checking for some reason. So they move a bunch of code around and break SE-PostgreSQL. Someone has to review that patch and understand the danger it causes. That's going to require understanding both the SE-PostgreSQL-specific files and the other parts, and the relationship between the two of them. ...Robert
Robert Haas wrote: > On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus@hagander.net> wrote: > > 2009/12/9 Bruce Momjian <bruce@momjian.us>: > >> I frankly think the patch should be thought of as the SE-Linux-specific > >> directory files, which KaiGai can maintain, and the other parts, which I > >> think I can handle. > > > > I think that's a horribly bad idea. > > Me, too. The ECPG comparison is apt, except that this code is far > more deeply integrated into core. The idea that the SE-Linux > directory files can be maintained separately from the "other parts" > does not seem realistic to me. The problems that are going to occur > here are things like: somebody wants to rearrange some part of the > permissions checking for some reason. So they move a bunch of code > around and break SE-PostgreSQL. Someone has to review that patch and > understand the danger it causes. That's going to require > understanding both the SE-PostgreSQL-specific files and the other > parts, and the relationship between the two of them. We did something similar for Win32 because it was the only way to do it. We don't have the luxury of educating our developers on SE-Linux API for a while --- there is the ideal world, and there is reality. What this means is that SE-Linux would break when permissions changes happen, and the SE-Linux folks will have to come in and clean things up later. If you want to avoid all good reasons for this features and are looking for reasons why this patch is a bad idea, I am sure you can find them. -- 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: > Robert Haas wrote: >> On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> 2009/12/9 Bruce Momjian <bruce@momjian.us>: >>>> I frankly think the patch should be thought of as the SE-Linux-specific >>>> directory files, which KaiGai can maintain, and the other parts, which I >>>> think I can handle. >>> I think that's a horribly bad idea. >> Me, too. The ECPG comparison is apt, except that this code is far >> more deeply integrated into core. The idea that the SE-Linux >> directory files can be maintained separately from the "other parts" >> does not seem realistic to me. The problems that are going to occur >> here are things like: somebody wants to rearrange some part of the >> permissions checking for some reason. So they move a bunch of code >> around and break SE-PostgreSQL. Someone has to review that patch and >> understand the danger it causes. That's going to require >> understanding both the SE-PostgreSQL-specific files and the other >> parts, and the relationship between the two of them. > > We did something similar for Win32 because it was the only way to do it. > We don't have the luxury of educating our developers on SE-Linux API for > a while --- there is the ideal world, and there is reality. What this > means is that SE-Linux would break when permissions changes happen, and > the SE-Linux folks will have to come in and clean things up later. > > If you want to avoid all good reasons for this features and are looking > for reasons why this patch is a bad idea, I am sure you can find them. > Right, I (and my employer) offers development and maintenance resource for the feature. If I'll be busy in future days, it means I'm devotedly working on this feature. When we need to change permission mechanism in the future, we can provide our efforts not to break them. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian <bruce@momjian.us> wrote: > If you want to avoid all good reasons for this features and are looking > for reasons why this patch is a bad idea, I am sure you can find them. You seem to be suggesting that our reactions are pure obstructionism, or that they have an ulterior motive. ...Robert
Robert Haas wrote: > On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian <bruce@momjian.us> wrote: > > If you want to avoid all good reasons for this features and are looking > > for reasons why this patch is a bad idea, I am sure you can find them. > > You seem to be suggesting that our reactions are pure obstructionism, > or that they have an ulterior motive. I am merely stating that this is the same as the Win32 port, and that there are many reasons to believe the SE-PostgreSQL patch will cause all sorts of problems --- this is not a surprise. I am giving a realistic analysis of the patch --- if people want to say that thinking of it as two separate patches that have to be maintained separately is a terrible idea, I have no reply except to say that realistically that is the only possible direction I see for this feature in the short term. Few Postgres people modifying the permissions system are going to understand how to modify SE-Linux support routines to match their changes. I got a similar reaction when I wanted to do the Win32 port, and the reasons not to do it were similar to the ones I am hearing now. Finally the agreement was that I could attempt the Win32 port as long as I didn't destabilize the rest of the code --- not exactly a resounding endorsement. Looking back I think everyone is glad we did the port, but at the time there wasn't much support. I got the same reaction to pg_migrator. I am having trouble figuring out when I should heed community concerns, and when the concerns are merely because the task is hard/messy/difficult. Frankly, we don't analyze hard/messy/difficult tasks very well. Now, I am not saying that the SE-PostgreSQL patch should be pursued, but I am saying that we shouldn't avoid it for these reasons, because sometimes hard/messy/difficult is necessary to accomplish dramatic software advances. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, Dec 9, 2009 at 10:43 PM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian <bruce@momjian.us> wrote: >> > If you want to avoid all good reasons for this features and are looking >> > for reasons why this patch is a bad idea, I am sure you can find them. >> >> You seem to be suggesting that our reactions are pure obstructionism, >> or that they have an ulterior motive. > > I am merely stating that this is the same as the Win32 port, and that > there are many reasons to believe the SE-PostgreSQL patch will cause all > sorts of problems --- this is not a surprise. I am giving a realistic > analysis of the patch --- if people want to say that thinking of it as > two separate patches that have to be maintained separately is a terrible > idea, I have no reply except to say that realistically that is the only > possible direction I see for this feature in the short term. Few > Postgres people modifying the permissions system are going to understand > how to modify SE-Linux support routines to match their changes. > > I got a similar reaction when I wanted to do the Win32 port, and the > reasons not to do it were similar to the ones I am hearing now. Finally > the agreement was that I could attempt the Win32 port as long as I > didn't destabilize the rest of the code --- not exactly a resounding > endorsement. Looking back I think everyone is glad we did the port, but > at the time there wasn't much support. I got the same reaction to > pg_migrator. > > I am having trouble figuring out when I should heed community concerns, > and when the concerns are merely because the task is > hard/messy/difficult. Frankly, we don't analyze hard/messy/difficult > tasks very well. Now, I am not saying that the SE-PostgreSQL patch > should be pursued, but I am saying that we shouldn't avoid it for these > reasons, because sometimes hard/messy/difficult is necessary to > accomplish dramatic software advances. I don't have any easy answers here. I'm actually trying not to make a value judgment about the feature and focus on the technical problems with the patch. If those problems are fixed, which as you say probably doable, then I don't mind seeing it committed. I think that the reason we don't analyze hard/messy/difficult problems very well is because on the one hand you have people saying "this feature would be great". On the other hand you have people saying "this feature will be a lot of work". But those things are not opposites. Unlike Tom (I think), I do believe that there is demand (possibly only from a limited number of people, but demand all the same) for this feature. And I also believe that most people in our community are generally supportive of the idea, but only a minority are willing to put in time to make it happen. So I have no problem saying to the people who want the feature - none of our committers feel like working on this. Sorry. On the other hand, I also have no problem telling them - good news, Bruce Momjian thinks this is a great feature and wants to help you get it done. I *do* have a problem with saying - we don't really know whether anyone will ever want to work on this with you or not. ...Robert
Robert Haas <robertmhaas@gmail.com> writes: > Unlike Tom (I think), I do believe that there is demand (possibly only > from a limited number of people, but demand all the same) for this > feature. Please note that I do not think there is *zero* demand for the feature. There is obviously some. What I find highly dubious is whether there is enough demand to justify the amount of effort, both short- and long-term, that the community would have to put into it. > And I also believe that most people in our community are > generally supportive of the idea, but only a minority are willing to > put in time to make it happen. So I have no problem saying to the > people who want the feature - none of our committers feel like working > on this. Sorry. On the other hand, I also have no problem telling > them - good news, Bruce Momjian thinks this is a great feature and > wants to help you get it done. I *do* have a problem with saying - we > don't really know whether anyone will ever want to work on this with > you or not. If I thought that Bruce could go off in a corner and make this happen and it would create no demands on anybody but him and KaiGai-san, I would say "fine, if that's where you want to spend your time, go for it". But even to state that implied claim is to see how false it is. Bruce is pointing to the Windows port, but he didn't make it happen by himself, or any close approximation of that. Everybody who works on this project has been affected by that, and we're *still* putting significant amounts of time into Windows compatibility, over five years later. My guess is that a credible SEPostgres offering will require a long-term amount of work at least equal to, and very possibly a good deal more than, what it took to make a native Windows port. If SEPostgres could bring us even 10% as many new users as the Windows port did, it'd probably be a worthwhile use of our resources. But again, that's an assumption that's difficult to type without bursting into laughter. regards, tom lane
On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > Unlike Tom (I think), I do believe that there is demand (possibly only > > from a limited number of people, but demand all the same) for this > > feature. > > Please note that I do not think there is *zero* demand for the feature. > There is obviously some. What I find highly dubious is whether there is > enough demand to justify the amount of effort, both short- and long-term, > that the community would have to put into it. > > > And I also believe that most people in our community are > > generally supportive of the idea, but only a minority are willing to > > put in time to make it happen. So I have no problem saying to the > > people who want the feature - none of our committers feel like working > > on this. Sorry. On the other hand, I also have no problem telling > > them - good news, Bruce Momjian thinks this is a great feature and > > wants to help you get it done. I *do* have a problem with saying - we > > don't really know whether anyone will ever want to work on this with > > you or not. > > If I thought that Bruce could go off in a corner and make this happen > and it would create no demands on anybody but him and KaiGai-san, I > would say "fine, if that's where you want to spend your time, go for > it". But even to state that implied claim is to see how false it is. > Bruce is pointing to the Windows port, but he didn't make it happen > by himself, or any close approximation of that. Everybody who works > on this project has been affected by that, and we're *still* putting > significant amounts of time into Windows compatibility, over five years > later. > > My guess is that a credible SEPostgres offering will require a long-term > amount of work at least equal to, and very possibly a good deal more > than, what it took to make a native Windows port. If SEPostgres could > bring us even 10% as many new users as the Windows port did, it'd > probably be a worthwhile use of our resources. But again, that's an > assumption that's difficult to type without bursting into laughter. > > regards, tom lane So a couple of us in the Maryland/DC area went to the BWPUG meeting last night and we sat down for two hours and answered a bunch of questions from Greg Smith, Steve Frost, and a few others. Greg was taking notes during the entire meeting and I believe he will be starting a thread with the minutes from the meeting. Greg brought up 5 or 6 concerns that he has observed in the community about the work including the issue of who is going to use this. The minutes will give a much better account of the conversation but Josh Brindle and I have gave examples outside of DoD where the MAC framework without row based access controls can be useful. For our purposes in DoD we need the MAC Framework and the row based access controls but if a good starting point is to just do the access control over the database objects then it will be useful for some commercial cases and some limited military cases. Dave
Hi, On Thursday 10 December 2009 23:08:17 Tom Lane wrote: > My guess is that a credible SEPostgres offering will require a long-term > amount of work at least equal to, and very possibly a good deal more > than, what it took to make a native Windows port. If SEPostgres could > bring us even 10% as many new users as the Windows port did, it'd > probably be a worthwhile use of our resources. But again, that's an > assumption that's difficult to type without bursting into laughter. Sorry, could not resist: It could possibly bring us more interesting users... While mainly an humoristic remark, I think it might even have some truth to it... Andres
My two cents - if it's desired - I invariably disable selinux from all of my production machines. Once upon a time I tried to work with it time and time again - but it was such a head ache to administer for what I considered to be marginal gains, that I eventually gave up. Every time I add a server, it needs to be setup. Or it runs in tolerant mode at which point I'm not sure what value I am really getting at all. Too many times people have come to me with weird problems of servers not starting, or not working properly, and I have now started with the question "do you have selinux running?" "try turning it off..." I'm sure some people somewhere love selinux - but I suspect most people find the most relief once they turn it off. I vote for PostgreSQL committers spending their time on things that bring value to the most number of people. Cheers, mark -- Mark Mielke<mark@mielke.cc>
Tom Lane wrote: > My guess is that a credible SEPostgres offering will require a long-term > amount of work at least equal to, and very possibly a good deal more > than, what it took to make a native Windows port. Wow, if I thought that was the case I'd be as negative about the whole thing as you obviously are. In my head, I've been mentally bounding the effort by thinking that its worst case work would be more like what it took to add the role-based security to the system. I'd think that adding a new feature to the existing security setup couldn't be more painful than adding security in the first place, right? I didn't carefully watch either play out , but I was under the impression that the Windows port was quite a bit more work than that. Since the current discussion keeps going around in circles, the way I was trying to tilt the other thread I started towards was asking the question "what would need to change in the current PostgreSQL code to make the impact of adding the SEPostgreSQL code smaller?" I'd be curious to hear any thoughts you had on that topic. We already sort of refactored out "adding row-level security" as one answer to that, I feel like there may be others in there too. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If I thought that Bruce could go off in a corner and make this happen > and it would create no demands on anybody but him and KaiGai-san, I > would say "fine, if that's where you want to spend your time, go for > it". But even to state that implied claim is to see how false it is. > Bruce is pointing to the Windows port, but he didn't make it happen > by himself, or any close approximation of that. Everybody who works > on this project has been affected by that, and we're *still* putting > significant amounts of time into Windows compatibility, over five years > later. This is also one of my concerns. Bruce has been careful to say that he will either make this happen himself or find others to help. The thing is, who are the others, are they people we already trust, and how do we know whether they'll be around after this is committed? I'm excited to see Greg Smith getting more involved in dealing with this patch-set, and I know Stephen Frost did some reviewing as well, but overall the community support has been pretty limpid. It's probably impossible to completely eliminate the impact of this feature on the community, but having a core of involved people - preferably including several committers - who will maintain it would help a lot. We're not there yet. > My guess is that a credible SEPostgres offering will require a long-term > amount of work at least equal to, and very possibly a good deal more > than, what it took to make a native Windows port. If SEPostgres could > bring us even 10% as many new users as the Windows port did, it'd > probably be a worthwhile use of our resources. But again, that's an > assumption that's difficult to type without bursting into laughter. The SEPostgres community is surely a lot smaller than the Windows community, but I'm not sure whether the effort estimate is accurate or not. If "credible" includes "row-level security", then I think I might agree, but right now we're just trying to get off the ground. ...Robert
David P. Quigley wrote: > On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> Unlike Tom (I think), I do believe that there is demand (possibly only >>> from a limited number of people, but demand all the same) for this >>> feature. >> Please note that I do not think there is *zero* demand for the feature. >> There is obviously some. What I find highly dubious is whether there is >> enough demand to justify the amount of effort, both short- and long-term, >> that the community would have to put into it. >> >>> And I also believe that most people in our community are >>> generally supportive of the idea, but only a minority are willing to >>> put in time to make it happen. So I have no problem saying to the >>> people who want the feature - none of our committers feel like working >>> on this. Sorry. On the other hand, I also have no problem telling >>> them - good news, Bruce Momjian thinks this is a great feature and >>> wants to help you get it done. I *do* have a problem with saying - we >>> don't really know whether anyone will ever want to work on this with >>> you or not. >> If I thought that Bruce could go off in a corner and make this happen >> and it would create no demands on anybody but him and KaiGai-san, I >> would say "fine, if that's where you want to spend your time, go for >> it". But even to state that implied claim is to see how false it is. >> Bruce is pointing to the Windows port, but he didn't make it happen >> by himself, or any close approximation of that. Everybody who works >> on this project has been affected by that, and we're *still* putting >> significant amounts of time into Windows compatibility, over five years >> later. >> >> My guess is that a credible SEPostgres offering will require a long-term >> amount of work at least equal to, and very possibly a good deal more >> than, what it took to make a native Windows port. If SEPostgres could >> bring us even 10% as many new users as the Windows port did, it'd >> probably be a worthwhile use of our resources. But again, that's an >> assumption that's difficult to type without bursting into laughter. >> >> regards, tom lane > > So a couple of us in the Maryland/DC area went to the BWPUG meeting last > night and we sat down for two hours and answered a bunch of questions > from Greg Smith, Steve Frost, and a few others. Greg was taking notes > during the entire meeting and I believe he will be starting a thread > with the minutes from the meeting. Greg brought up 5 or 6 concerns that > he has observed in the community about the work including the issue of > who is going to use this. The minutes will give a much better account of > the conversation but Josh Brindle and I have gave examples outside of > DoD where the MAC framework without row based access controls can be > useful. For our purposes in DoD we need the MAC Framework and the row > based access controls but if a good starting point is to just do the > access control over the database objects then it will be useful for some > commercial cases and some limited military cases. > I repent that I live in behind of the earth. :( I'd like to introduce a story related to Maryland/Baltimore where is the first city I've visited in US a bit. The SELinux symposium and developers summit had been held in Baltimore between 2005 and 2007. (It has been held with LinuxCon at Portland/OR in recent years.) I also had a short (works-in-progress) session in the symposium of 2007 to introduce an early concept and design of SE-PostgreSQL. http://selinux-symposium.org/2007/wipsbofs.php#sepostgresql After the 20 minutes talks, I was encircled by several stalwart-guys and pestered with questions about its behavior and so on. He also gave me a contact address in ".mil" domain. It was the first experience for me to see this domain actually. Maybe, we cannot see these people in PGcon. What I want to say in this story is that our domain of audiences depends on our standpoint. If eyesight of developers cannot catch their figures, we may misunderstand actual voice and demands from (potential) users. However, it is *never* easy job. Please remind how much cost our company have spent on marketing research annually. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> My guess is that a credible SEPostgres offering will require a long-term >> amount of work at least equal to, and very possibly a good deal more >> than, what it took to make a native Windows port. > The SEPostgres community is surely a lot smaller than the Windows > community, but I'm not sure whether the effort estimate is accurate or > not. If "credible" includes "row-level security", then I think I > might agree, but right now we're just trying to get off the ground. It's been perfectly clear since day one, and was reiterated as recently as today http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com that what the security community wants is row-level security. The proposals to make SEPostgres drive regular SQL permissions never came out of anyone from that side, they were proposed by PG people looking for a manageable first step. Whatever you might believe about the potential market for SEPostgres, you should divide by about a hundred as long as it's only an alternate interface to SQL permissions. See particularly here: http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security "Without it, it's questionable whether committing the existing stripped-down patch really accomplishes anything" --- how much clearer can they be? If you're not prepared to assume that we're going to do row level security, it's not apparent why we should be embarking on this course at all. And if you do assume that, I strongly believe that my effort estimate above is on the optimistic side. regards, tom lane
Tom Lane wrote: > It's been perfectly clear since day one, and was reiterated as recently > as today > http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com > that what the security community wants is row-level security. I think David Quigley's comments from earlier today summarize the situation better than I did: "For our purposes in DoD we need the MAC Framework and the row based access controls. But if a good starting point is to just do the access control over the database objects, then it will be useful for some commercial cases and some limited military cases" So it's not without value even in its current "Lite" form. But there's clearly a whole lot more use-cases that would benefit from a version with row filtering. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If you're not prepared to assume that we're going to do row level > security, it's not apparent why we should be embarking on this course > at all. And if you do assume that, I strongly believe that my effort > estimate above is on the optimistic side. Row-level security is going to be a very difficult project, no question about it. However, if we implement a general facility rather than something SE-Linux specific, I think we will have a killer feature. I realize it's not for everyone, but for those who need it, it's kick-ass. But we have a while before we get to the point where we can even start worrying about that pain. Stephen Frost's statements about the way our access controls are scattered throughout our code are, I think, on target. And cleaning that up seems to me to have value independently of SE-PostgreSQL. I'm feeling (right now, anyway) like it would make sense to pursue further the patch that KaiGai submitted for the last CF and you rejected. It needed work, but I don't think it was hopeless, or valueless. ...Robert
Robert Haas wrote: > On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If you're not prepared to assume that we're going to do row level >> security, it's not apparent why we should be embarking on this course >> at all. And if you do assume that, I strongly believe that my effort >> estimate above is on the optimistic side. > > Row-level security is going to be a very difficult project, no > question about it. Yes, I also agree it is a reasonable decision to separate row-level from the initial proposition. > However, if we implement a general facility rather > than something SE-Linux specific, I think we will have a killer > feature. I realize it's not for everyone, but for those who need it, > it's kick-ass. > > But we have a while before we get to the point where we can even start > worrying about that pain. Stephen Frost's statements about the way > our access controls are scattered throughout our code are, I think, on > target. And cleaning that up seems to me to have value independently > of SE-PostgreSQL. I'm feeling (right now, anyway) like it would make > sense to pursue further the patch that KaiGai submitted for the last > CF and you rejected. It needed work, but I don't think it was > hopeless, or valueless. Here is a few issues to salvage the access control reworks patch. It tried to provide a set of common entry points both of the default PG security model and SELinux (and upcoming ones). However, the default PG model does not have same origin with label-based mandatory access controls, such as SELinux, from a historical angle. So, this reworks needed many of unobvious changes to the core routines. ("core routines" means code except for enhanced security features.) It tried to provide a set of comprehensive entry points to replace existing PG checks at once. However, the SE-PgSQL/Lite patch covers accesses on only database, schema, tables and columns. Is it necessary to be comprehensive from the beginning? It might be too aggressive changes at once. Frankly, I hesitate to salvage the patch once rejected, as is. If we implement a set of security hooks, It seems to me the following approach is reasonable: * It does not touch the existing PG default checks. The purpose of security hooks are to host "enhanced" security features. * It does not deploy hooks on which no security provider is now proposed. It is important to reduce unnecessary changeset. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> My guess is that a credible SEPostgres offering will require a long-term >>> amount of work at least equal to, and very possibly a good deal more >>> than, what it took to make a native Windows port. > >> The SEPostgres community is surely a lot smaller than the Windows >> community, but I'm not sure whether the effort estimate is accurate or >> not. If "credible" includes "row-level security", then I think I >> might agree, but right now we're just trying to get off the ground. > > It's been perfectly clear since day one, and was reiterated as recently > as today > http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com > that what the security community wants is row-level security. The If that is true, then shouldn't we have an implementation of row level security *first*, and then an implementation of selinux hooks that work with this row level security feature? Rather than first doing selinux hooks, then row level security, which will likely need new and/or changed hooks... I'm not convinced that row level security is actually that necessary (though it's a nice feature, with or without selinux), but if it is, it seems we are approaching the problem from the wrong direction. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Tom, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > It's been perfectly clear since day one, and was reiterated as recently > as today > http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com > that what the security community wants is row-level security. Yes, they do want row-level security. That being said, KaiGai, and others, have pointed out time and time over again that SEPG without row-level security is still useful. Additionally, I see absolutely no way that PG would accept a full SEPG+PGACE+row-level security, etc, patch in as one whole patch, ever. I have extreme doubt it would even be something done over one *release*. That all aside, for the moment, I feel that we should begin a 'two-prong' attack here. First, continue down the path that I've started to lay out for SEPG. Second, let's hash out a design for row-level security using the existing PG security model; ideally using the best features and design decisions of the numerous row-level security systems already implemented by the major SQL vendors today. I'll start a new thread on this specific topic to hopefully pull out anyone who's focus is more on that than on SEPG. > The > proposals to make SEPostgres drive regular SQL permissions never came > out of anyone from that side, they were proposed by PG people looking > for a manageable first step. I do not believe this to be accurate. Josh, were you able to find any public documentation on Trusted Rubix (is that the right name?)? The RDBMS security policy hashed out on the SELinux list during the discussion of Rubix and SEPG certainly included support for table-level objects, did it not? I expect that the SELinux list contributors would have pointed out if they didn't feel that was at all valuable. Perhaps what is at issue is the terminology being used here though, or the approach to enforment being considered. Part of the discussion at the BWPUG meeting involved the option for SEPG to be a "more-restrictive only model" in it's implementation. Essentially, this means that all permissions handling is done the same as it is today, except that once the PG model has decided an action is allowed, SEPG kicks in and does any additional checking of the action being requested it wants and may deny it. At the end of the day, I don't feel that it really changes the architecture of the code though. Perhaps users of SELinux will always want that, but the argument we've heard time and time again here is that this should be a generalized approach that other security managers could hook into and use. To do that, I feel we first have to start with the PG model, which *does* care about all the SQL permissions. Let's extract the various complaints and concerns about SELinux that have been thrown around this list and instead consider our first "client" of the PG modular security framework to be the existing PG SQL permissions system. If we can agree to that, then it's clear that we can't just hand-wave the requirement that it be capable of driving the regular SQL permissions. > Whatever you might believe about the > potential market for SEPostgres, you should divide by about a hundred > as long as it's only an alternate interface to SQL permissions. See > particularly here: > http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security > "Without it, it's questionable whether committing the existing > stripped-down patch really accomplishes anything" --- how much > clearer can they be? Again, let's please address row-level security first at the PG level. That was recommended previously by many on this list and is clearly a useful feature which can stand alone in any case. > If you're not prepared to assume that we're going to do row level > security, it's not apparent why we should be embarking on this course > at all. And if you do assume that, I strongly believe that my effort > estimate above is on the optimistic side. I do assume we're going to do row level security, but I do not feel that we need to particularly put one in front of the other. I also feel that SEPG will be valuable even without row-level security. One of the realms that we discussed at BWPUG for this is PCI compliance. I'm hopeful Josh will have an opportunity to review the PCI compliance "cheat-sheet" that I recall Robert Treat offering and comes to agreement that SEPG w/o row-level security would greatly improve our ability to have a PCI compliant system backed with PG. Thanks, Stephen
On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> My guess is that a credible SEPostgres offering will require a long-term >>>> amount of work at least equal to, and very possibly a good deal more >>>> than, what it took to make a native Windows port. >> >>> The SEPostgres community is surely a lot smaller than the Windows >>> community, but I'm not sure whether the effort estimate is accurate or >>> not. If "credible" includes "row-level security", then I think I >>> might agree, but right now we're just trying to get off the ground. >> >> It's been perfectly clear since day one, and was reiterated as recently >> as today >> http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com >> that what the security community wants is row-level security. The > > If that is true, then shouldn't we have an implementation of row level > security *first*, and then an implementation of selinux hooks that > work with this row level security feature? Rather than first doing > selinux hooks, then row level security, which will likely need new > and/or changed hooks... > > I'm not convinced that row level security is actually that necessary > (though it's a nice feature, with or without selinux), but if it is, > it seems we are approaching the problem from the wrong direction. I don't think there's a correct ordering to SE-PostgreSQL and row-level security. They're better together, but I don't think either has to be done first. If we were going to pick one to do first, I'd pick SE-PostgreSQL. Row-level security is going to be a @$#! of a project if we want it done right (and we do). ...Robert
2009/12/11 KaiGai Kohei <kaigai@ak.jp.nec.com>: > It tried to provide a set of comprehensive entry points to replace existing > PG checks at once. > However, the SE-PgSQL/Lite patch covers accesses on only database, schema, > tables and columns. Is it necessary to be comprehensive from the beginning? > It might be too aggressive changes at once. > > Frankly, I hesitate to salvage the patch once rejected, as is. > > If we implement a set of security hooks, It seems to me the following approach > is reasonable: > > * It does not touch the existing PG default checks. > The purpose of security hooks are to host "enhanced" security features. > > * It does not deploy hooks on which no security provider is now proposed. > It is important to reduce unnecessary changeset. I think that we should try to move the PG default checks inside the hook functions. If we can't do that cleanly, it's a good sign that the hook functions are not correctly placed to enforce arbitrary security policy. Furthermore, it defeats what I think would be a good side goal here, which is to better modularize the existing code. What I would suggest is that you develop a version of that patch that is stripped down to apply to only a single object type (databases? tables and columns - these might have to be together??) and which addresses Tom's criticisms from the last time around, and post that (on a new thread) for discussion. That will be much easier to review (and I will personally commit to reviewing it) but should allow us to flush out some of the design issues. If we can get agreement on that as a concept patch, we can move on to talking about which object types should be included in a committable version of that patch. ...Robert
Stephen Frost wrote: > Tom, > <snip> >> The >> proposals to make SEPostgres drive regular SQL permissions never came >> out of anyone from that side, they were proposed by PG people looking >> for a manageable first step. > > I do not believe this to be accurate. Josh, were you able to find any > public documentation on Trusted Rubix (is that the right name?)? The > RDBMS security policy hashed out on the SELinux list during the > discussion of Rubix and SEPG certainly included support for table-level > objects, did it not? I expect that the SELinux list contributors would > have pointed out if they didn't feel that was at all valuable. Trusted RUBIX does use the same SELinux object classes and permissions that were originally added to the policy to support SEPostgreSQL. You can look at <http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf> and see how they use SELinux in their RDBMS. Pay particular attention to page 15 where they are saying which object classes and permissions they are using. They even implement row level security (the db_tuple object class) > > Perhaps what is at issue is the terminology being used here though, or > the approach to enforment being considered. Part of the discussion at > the BWPUG meeting involved the option for SEPG to be a "more-restrictive > only model" in it's implementation. Essentially, this means that all > permissions handling is done the same as it is today, except that once > the PG model has decided an action is allowed, SEPG kicks in and does > any additional checking of the action being requested it wants and may > deny it. > > At the end of the day, I don't feel that it really changes the > architecture of the code though. Perhaps users of SELinux will always > want that, but the argument we've heard time and time again here is that > this should be a generalized approach that other security managers could > hook into and use. To do that, I feel we first have to start with the > PG model, which *does* care about all the SQL permissions. Let's > extract the various complaints and concerns about SELinux that have been > thrown around this list and instead consider our first "client" of the > PG modular security framework to be the existing PG SQL permissions > system. If we can agree to that, then it's clear that we can't just > hand-wave the requirement that it be capable of driving the regular SQL > permissions. > >> Whatever you might believe about the >> potential market for SEPostgres, you should divide by about a hundred >> as long as it's only an alternate interface to SQL permissions. See >> particularly here: >> http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security >> "Without it, it's questionable whether committing the existing >> stripped-down patch really accomplishes anything" --- how much >> clearer can they be? > > Again, let's please address row-level security first at the PG level. > That was recommended previously by many on this list and is clearly a > useful feature which can stand alone in any case. > >> If you're not prepared to assume that we're going to do row level >> security, it's not apparent why we should be embarking on this course >> at all. And if you do assume that, I strongly believe that my effort >> estimate above is on the optimistic side. > > I do assume we're going to do row level security, but I do not feel that > we need to particularly put one in front of the other. I also feel that > SEPG will be valuable even without row-level security. One of the > realms that we discussed at BWPUG for this is PCI compliance. I'm > hopeful Josh will have an opportunity to review the PCI compliance > "cheat-sheet" that I recall Robert Treat offering and comes to agreement > that SEPG w/o row-level security would greatly improve our ability to > have a PCI compliant system backed with PG. > > Thanks, > > Stephen
On Fri, 2009-12-11 at 09:20 -0500, Robert Haas wrote: > On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander <magnus@hagander.net> wrote: > > On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Robert Haas <robertmhaas@gmail.com> writes: > >>> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>>> My guess is that a credible SEPostgres offering will require a long-term > >>>> amount of work at least equal to, and very possibly a good deal more > >>>> than, what it took to make a native Windows port. > >> > >>> The SEPostgres community is surely a lot smaller than the Windows > >>> community, but I'm not sure whether the effort estimate is accurate or > >>> not. If "credible" includes "row-level security", then I think I > >>> might agree, but right now we're just trying to get off the ground. > >> > >> It's been perfectly clear since day one, and was reiterated as recently > >> as today > >> http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com > >> that what the security community wants is row-level security. The > > > > If that is true, then shouldn't we have an implementation of row level > > security *first*, and then an implementation of selinux hooks that > > work with this row level security feature? Rather than first doing > > selinux hooks, then row level security, which will likely need new > > and/or changed hooks... > > > > I'm not convinced that row level security is actually that necessary > > (though it's a nice feature, with or without selinux), but if it is, > > it seems we are approaching the problem from the wrong direction. > > I don't think there's a correct ordering to SE-PostgreSQL and > row-level security. They're better together, but I don't think either > has to be done first. If we were going to pick one to do first, I'd > pick SE-PostgreSQL. Row-level security is going to be a @$#! of a > project if we want it done right (and we do). I'm not sure it is a strong analogy, but as an example, in the case of Linux, we started by integrating support for a base set of access controls over directories and files, and only later introduced support for multi-level/polyinstantiated directories by building upon Linux's per-process filesystem namespace construct. The base set of access controls for directories and files were certainly useful on their own even before we had the support for polyinstantiated directories. In any event, I would agree that support for applying MAC over the database objects and operations is useful even without row-level security, although ultimately we would like both. -- Stephen Smalley National Security Agency
On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote: > 2009/12/11 KaiGai Kohei <kaigai@ak.jp.nec.com>: > > It tried to provide a set of comprehensive entry points to replace existing > > PG checks at once. > > However, the SE-PgSQL/Lite patch covers accesses on only database, schema, > > tables and columns. Is it necessary to be comprehensive from the beginning? > > It might be too aggressive changes at once. > > > > Frankly, I hesitate to salvage the patch once rejected, as is. > > > > If we implement a set of security hooks, It seems to me the following approach > > is reasonable: > > > > * It does not touch the existing PG default checks. > > The purpose of security hooks are to host "enhanced" security features. > > > > * It does not deploy hooks on which no security provider is now proposed. > > It is important to reduce unnecessary changeset. > > I think that we should try to move the PG default checks inside the > hook functions. If we can't do that cleanly, it's a good sign that > the hook functions are not correctly placed to enforce arbitrary > security policy. Furthermore, it defeats what I think would be a good > side goal here, which is to better modularize the existing code. So from the meeting on Wednesday I got the impression that Steve already did this. However it was rejected because too much information was need to be passed around. I gathered and I could be wrong but the reason for this is that instead of developing proper abstractions for the security code people made use of whatever local stuff was available to them at that location. With the X-ACE work that Eamon Walsh did he did exactly what you're saying. He figured out the object model for the X-Server and created the hook framework. In the merge of the hook framework he also moved the existing X server security model into the framework. > > What I would suggest is that you develop a version of that patch that > is stripped down to apply to only a single object type (databases? > tables and columns - these might have to be together??) and which > addresses Tom's criticisms from the last time around, and post that > (on a new thread) for discussion. That will be much easier to review > (and I will personally commit to reviewing it) but should allow us to > flush out some of the design issues. If we can get agreement on that > as a concept patch, we can move on to talking about which object types > should be included in a committable version of that patch. They may have been said before but what exactly are the design issues? The main concern I hear is that people are worried that this is an SELinux specific design. I heard at the meeting on Wednesday that the Trusted Extensions people looked at the framework and said it meets their needs as well. If thats the case where does the concept that the design is SELinux specific stem from? We've asked Casey Schaufler the developer of another label based MAC system for Linux to look at the hooks as well and make a statement about their usability. Dave
Magnus, * Magnus Hagander (magnus@hagander.net) wrote: > On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > It's been perfectly clear since day one, and was reiterated as recently > > as today > > http://archives.postgresql.org/message-id/4B21757E.7090806@2ndquadrant.com > > that what the security community wants is row-level security. The > > If that is true, then shouldn't we have an implementation of row level > security *first*, and then an implementation of selinux hooks that > work with this row level security feature? Rather than first doing > selinux hooks, then row level security, which will likely need new > and/or changed hooks... The proposal we're currently grappling with is to pull all the various checks which are sprinkled through our code into a single area. Clearly, if that work is done before we implement row-level security, then the patch for row-level security will just add it's checks in the security/ area and it'd be then easily picked up by SELinux, etc. > I'm not convinced that row level security is actually that necessary > (though it's a nice feature, with or without selinux), but if it is, > it seems we are approaching the problem from the wrong direction. It has to be implemented independent of the security/SELinux/etc changes in any case, based on what was said previously.. So I don't particularly understand why it matters a great deal which one happens first. They're independently useful features, though both are not nearly as good on their own as when they are combined. Sorry, I just don't see this as a "cart-before-the-horse" case. Thanks, Stephen
On Fri, 2009-12-11 at 08:56 -0500, Stephen Frost wrote: [snip...] > I do assume we're going to do row level security, but I do not feel that > we need to particularly put one in front of the other. I also feel that > SEPG will be valuable even without row-level security. One of the > realms that we discussed at BWPUG for this is PCI compliance. I'm > hopeful Josh will have an opportunity to review the PCI compliance > "cheat-sheet" that I recall Robert Treat offering and comes to agreement > that SEPG w/o row-level security would greatly improve our ability to > have a PCI compliant system backed with PG. > So I downloaded and read through the PCI DSS document (74 pages is pretty light compared to NFSv4.1 hehe...) and There are several areas there where I think strong access controls in the database will not only fulfill the requirement but provide much stronger guarantees than can be provided from the application server alone. The requirements in section 7 can definitely benefit from SEPG. If you implement these requirements in the application server and in PG access controls alone there is still an attack vector where a malicious user manages to steal the credentials for a particular role. With PG-ACE you can write a security module (although SEPG already allows for this) to restrict access to the data using the existing role-based access controls in PG and then apply additional restrictions such as, only this program may act as this role or access this database. This provides better guarantees than exist in current PCI compliant implementations using PG today. Dave
David, * David P. Quigley (dpquigl@tycho.nsa.gov) wrote: > So I downloaded and read through the PCI DSS document (74 pages is > pretty light compared to NFSv4.1 hehe...) and There are several areas > there where I think strong access controls in the database will not only > fulfill the requirement but provide much stronger guarantees than can be > provided from the application server alone. Thanks for taking a look! That sounds like excellent news. My apologies for attributing the action item to the wrong individual. :) > The requirements in section 7 can definitely benefit from SEPG. I don't mean to be a pain, and we're all busy, but perhaps you could include a short description of what 'requirements in section 7' are.. It would help keep the mailing list archive coherent, and be simpler for folks who aren't familiar with PCI to play along. A link to the specific PCI DSS document you looked at would be an alternative, tho not as good as a 'dumbed-down' description. ;) That would at least avoid confusion over which document, since I presume there's more than one out there. Thanks again for looking over this! Treat, you've dealt alot with PCI in your commercial work; could you comment on this for the benefit of the list? I don't doubt David in the least, but it never hurts to have someone as lucky as yourself in frequent dealings with PCI compliance to provide any additional insight. Thanks! Stephen
* David P. Quigley (dpquigl@tycho.nsa.gov) wrote: > On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote: > > I think that we should try to move the PG default checks inside the > > hook functions. If we can't do that cleanly, it's a good sign that > > the hook functions are not correctly placed to enforce arbitrary > > security policy. Furthermore, it defeats what I think would be a good > > side goal here, which is to better modularize the existing code. > > So from the meeting on Wednesday I got the impression that Steve already > did this. However it was rejected because too much information was need > to be passed around. KaiGai did all the work, but it was my suggestion to go down this route and I reviewed KaiGai's patch to do it. The specific 'review/rejection' email is here: http://archives.postgresql.org/message-id/10495.1255627322@sss.pgh.pa.us > I gathered and I could be wrong but the reason for > this is that instead of developing proper abstractions for the security > code people made use of whatever local stuff was available to them at > that location. That's certainly one concern I continue to have, but as I've been rereading the threads I'm less confident it's a huge problem- the issue seemed to be more about the single access_control.c knowing about the entire PG world. > With the X-ACE work that Eamon Walsh did he did exactly > what you're saying. He figured out the object model for the X-Server and > created the hook framework. In the merge of the hook framework he also > moved the existing X server security model into the framework. It's great to hear specific examples of other projects which have gone through this headache and come out the other side better for it. > > What I would suggest is that you develop a version of that patch that > > is stripped down to apply to only a single object type (databases? > > tables and columns - these might have to be together??) and which > > addresses Tom's criticisms from the last time around, and post that > > (on a new thread) for discussion. That will be much easier to review > > (and I will personally commit to reviewing it) but should allow us to > > flush out some of the design issues. If we can get agreement on that > > as a concept patch, we can move on to talking about which object types > > should be included in a committable version of that patch. > > They may have been said before but what exactly are the design issues? Unfortunately, "design" isn't nearly as well defined a term as one would hope. I believe KaiGai's latest suggestion (which is probably what his original PGACE implementation was, but I'm going to avoid looking, the community has enough egg on it's face already wrt this :/) is a good approach, along with splitting the huge access_control.c file into per-object pieces. That's a design change, tho perhaps not the kind of one others who have commented on the design were thinking about when they made those statements. Basically, there's the design of the code layout and how each piece knows about the other pieces (through header files, etc), and then there's the design of the function calls/ABI and actual code paths which are taken when the code is executed (which doesn't particularly care how the code is laid out in the source tree). I feel like the design issues raised have been more about the former and less about the latter. > The main concern I hear is that people are worried that this is an > SELinux specific design. I heard at the meeting on Wednesday that the > Trusted Extensions people looked at the framework and said it meets > their needs as well. If thats the case where does the concept that the > design is SELinux specific stem from? We've asked Casey Schaufler the > developer of another label based MAC system for Linux to look at the > hooks as well and make a statement about their usability. Hope I didn't steal your thunder wrt Casey! Thanks again. Thanks, Stephen
On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: > On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote: >> 2009/12/11 KaiGai Kohei <kaigai@ak.jp.nec.com>: >> > It tried to provide a set of comprehensive entry points to replace existing >> > PG checks at once. >> > However, the SE-PgSQL/Lite patch covers accesses on only database, schema, >> > tables and columns. Is it necessary to be comprehensive from the beginning? >> > It might be too aggressive changes at once. >> > >> > Frankly, I hesitate to salvage the patch once rejected, as is. >> > >> > If we implement a set of security hooks, It seems to me the following approach >> > is reasonable: >> > >> > * It does not touch the existing PG default checks. >> > The purpose of security hooks are to host "enhanced" security features. >> > >> > * It does not deploy hooks on which no security provider is now proposed. >> > It is important to reduce unnecessary changeset. >> >> I think that we should try to move the PG default checks inside the >> hook functions. If we can't do that cleanly, it's a good sign that >> the hook functions are not correctly placed to enforce arbitrary >> security policy. Furthermore, it defeats what I think would be a good >> side goal here, which is to better modularize the existing code. > > So from the meeting on Wednesday I got the impression that Steve already > did this. However it was rejected because too much information was need > to be passed around. I am not sure who "Steve" is or which patch you're talking about, but suffice it to say that I think the problem you are articulating here is exactly the one we need to get out from under. I don't know how to do that yet and... > They may have been said before but what exactly are the design issues? ...that's the design issue I think we need to surmount. I think it will be easier to talk through that with a mini-patch that only affects one object type. I'll stop here because I see that Stephen Frost has just sent an insightful email on this topic as well. Hmm, maybe that's the Steve you were referring to. ...Robert
* Robert Haas (robertmhaas@gmail.com) wrote: > I'll stop here because I see that Stephen Frost has just sent an > insightful email on this topic as well. Hmm, maybe that's the Steve > you were referring to. I have doubts- but then I don't ever see my comments as insightful for some reason. ;) Thanks! Stephen
On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote: > The main concern I hear is that people are worried that this is an > SELinux specific design. I heard at the meeting on Wednesday that the > Trusted Extensions people looked at the framework and said it meets > their needs as well. If thats the case where does the concept that the > design is SELinux specific stem from? We've asked Casey Schaufler the > developer of another label based MAC system for Linux to look at the > hooks as well and make a statement about their usability. OK, on second thought I want to address this a little more, since some of these concerns came from me. SE-Linux-specific may be the wrong way to say it. There's an old saying that goes something like: if a function has 10 parameters, it has 11 parameters. In other words, if you're passing too much information across a supposed abstraction boundary, it's not really an abstraction boundary at all. If we design a security abstraction layer, the interfaces need to really be abstraction boundaries. Passing the table OID and then also the tablespace OID because PG DAC needs that to make its access control decision is crap. As soon as some other security model comes along you will need to add additional arguments for all of the things that the new security model cares about, and when a third security model comes along you will need to pass those things now too. If we're doing that sort of thing, we might as well leave the entire jumble of spaghetti code in its original location so that at least you don't have to flip back and forth between two different source files. And if we're going to do that, we might as well quit now because our heads will explode (Tom's first). I actually have an idea how to solve the problem in this particular case, but I'm reluctant to say what it is because I'm not sure if I'm right, and at any rate *I don't want to write this patch*. I may review it and if it's good I may commit it (or more likely a more extensive version of it after we have agreement on the basic principles) but I don't to want to write it or do substantial cleanup of it. I have my own list of things to work on and I presently have no reason to put this on that list. As a community, I think that at times we have a tendency to say "well, the committer is just going to rewrite this anyway, so it doesn't really matter what we do". As far as I am concerned that is flat false. I do not want to rewrite your patch. I want to look at your patch, convince myself that it is correct, and commit it. That won't always happen, and I'm certainly willing to do more than that especially in cases where it's a feature that I really care about, but AFAIAC the initiative is with the patch author to provide something committable, NOT with the committer to fix what the patch author did wrong. I realize that's subjective at times, and I'm going to make my best effort not to be a jerk about it, but given that there are only so many hours in the day (and not all of the can be spent on PostgreSQL) I think that's the goal we need to shoot for. ...Robert
On Fri, 2009-12-11 at 11:28 -0500, Stephen Frost wrote: [snip...] > > The main concern I hear is that people are worried that this is an > > SELinux specific design. I heard at the meeting on Wednesday that the > > Trusted Extensions people looked at the framework and said it meets > > their needs as well. If thats the case where does the concept that the > > design is SELinux specific stem from? We've asked Casey Schaufler the > > developer of another label based MAC system for Linux to look at the > > hooks as well and make a statement about their usability. > > Hope I didn't steal your thunder wrt Casey! Thanks again. So we contacted Casey about another MAC model for PG using PG-ACE and he got back to us with these reponses. Josh Brindle (JB): So my question is, does smack have a facility for userspace object managers? Casey Schaufler (cs): Yes. The smack-util package includes a small library which supports a user space version ofthe kernel smackaccess() function. You pass it the subject label, object label, and desired access and it returnsa yes/no answer based on what it reads from /smack/load. So this answers our questions on whether or not SMACK has the faculties to act as the security decision engine for PG. JB: If so, I want to make the argument that doing a smack integration using the pgace abstraction layer wouldnot only work but be fairly easy. CS: Looking at some of the documentation I think that you can safely make that argument. The security_label column would just be the Smack label. The rules can be enforcedby the user space smackaccess(). "System" rows, whatever that might be, could get the floor ("_") label. Casey mentions the row level access control in here but its safe to say we've broken row based access control into a followup discussion/project. JB: All the sepgsql docs and code are up at <http://code.google.com/p/sepgsql/> and I'd like to get your feedback before I start making claims... CS: I can't see how it would take more than about a day if pgace does what it looks like it should. This seems to be a favorable assesment of the pgace framework's ability to be used by something other than SELinux. So Casey's Smack module plus the Sun guys saying it is usable by their legacy TSOL or TX code would lend credence to the idea that pgace is bringing to the table. It may be possible that you're not happy with certain aspects of the implementation but the objects and permissions listed in pgace are definitely ones that are worth mediating. Dave Dave
On Fri, 2009-12-11 at 11:16 -0500, Stephen Frost wrote: > David, > > * David P. Quigley (dpquigl@tycho.nsa.gov) wrote: > > So I downloaded and read through the PCI DSS document (74 pages is > > pretty light compared to NFSv4.1 hehe...) and There are several areas > > there where I think strong access controls in the database will not only > > fulfill the requirement but provide much stronger guarantees than can be > > provided from the application server alone. > > Thanks for taking a look! That sounds like excellent news. My > apologies for attributing the action item to the wrong individual. :) Nahh you attributed it to the correct person I just got a little bored yesterday and poked my nose into it :) > > > The requirements in section 7 can definitely benefit from SEPG. > > I don't mean to be a pain, and we're all busy, but perhaps you could > include a short description of what 'requirements in section 7' are.. > It would help keep the mailing list archive coherent, and be simpler for > folks who aren't familiar with PCI to play along. A link to the > specific PCI DSS document you looked at would be an alternative, tho not > as good as a 'dumbed-down' description. ;) That would at least avoid > confusion over which document, since I presume there's more than one out > there. So the document I read is linked below [1]. Requirement 7 falls under "Implement Strong Access Control Measures". The two main requirements under requirement 7 seem to be "limit access to system components and card holder data to only those individuals whose job requires such access" and "Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed." The major flaw with this system is that stolen credentials allow you to completely bypass the logic for this in the application layer. If the person manages to get the login and password for an account on the database it doesn't matter what their authenticated use is because the logic to prevent accountant bob from cutting his own payroll check is in the application layer. The way that MAC controls can strengthen the protections by making sure that only certain components can perform certain actions. If you want to make sure that only the accounting application can mess with that data regardless of whether you have the database credentials or not then you can do that. You can write policy for SEPG to say only programs with this label can perform these actions on the database. Only applications labeled with the accounting_tool label can modify the table labeled accounting_data. This way if the system is compromised and someone manages to get the username and password for the database account/role that you were protecting the table with since the request isn't coming from a process labeled accounting_tool the database will deny those accesses. This is why I mean by adding stronger protections. This way you've minimized the amount of code that you have to accredit for compliance in your application server. [1] https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf > > Thanks again for looking over this! > > Treat, you've dealt alot with PCI in your commercial work; could you > comment on this for the benefit of the list? I don't doubt David in > the least, but it never hurts to have someone as lucky as yourself in > frequent dealings with PCI compliance to provide any additional > insight. It is definitely good to have a second opinion on this since I've just only started reading the PCI compliance documents. I'm definitely not an expert in PCI compliance but from what I've read there are definite benefits for using SEPG or PG-ACE with a special security module in making much stronger guarantees about who and what can touch the card data. Dave
On Fri, 2009-12-11 at 11:30 -0500, Robert Haas wrote: [snip...] > > I'll stop here because I see that Stephen Frost has just sent an > insightful email on this topic as well. Hmm, maybe that's the Steve > you were referring to. > > ...Robert > Yea I never asked Stephen if he goes by Stephen or Steve when I met him on Wednesday. I guess calling him Steve is me being a bit presumptuous :)
Robert, * Robert Haas (robertmhaas@gmail.com) wrote: > I actually have an idea how to solve the problem in this particular > case, but I'm reluctant to say what it is because I'm not sure if I'm > right, and at any rate *I don't want to write this patch*. As far as crap goes, I'd have to put this at the top. If you're not willing to share ideas, then I may have to reconsider my personal feeling on if you should be a committer or not. No one is asking you to write the patch. We all know that we can be wrong (I tend to be more wrong than most), and we all hate to "jerk people around", but I feel it's far worse to self-censor discussion on ideas. It's also about the worst form of rock-management that I think I could come up with in an open source community. If you don't share your idea, yet you feel that it's "right", and see nothing to dissuade you from that position (after all, we can't present an argument for or against it if we don't know what it is), then I find it likely that you're going to constantly be comparing patches presented to the ideal one in your head based on your idea and we'd never get there. If you're not willing to discuss your idea, then I would ask that you not be involved in either this discussion or review of the patch. Rock-management, for those not familiar with the term, is essentially asking "I need a rock", and then, when presented with a rock saying "sorry, that's not the rock I wanted". This doesn't provide any insight into what kind of rock you're looking for. Rest of the "I don't want to write it" whine omitted. No one's asking you to. Thanks, Stephen
All, * Robert Haas (robertmhaas@gmail.com) wrote: > If we design a security abstraction layer, the interfaces need to > really be abstraction boundaries. Passing the table OID and then also > the tablespace OID because PG DAC needs that to make its access > control decision is crap. Now, to address the small useful bit of this mail- I tend to agree with this. I'm not convinced there's an alternative, but I'd like to throw out a couple of my ideas on how it could be addressed. I'd like to solicit for feedback on these. First off, we have alot of the information available from the catalog. Basically, given an OID, we should be able to find out the other information associated with that OID (such as what kind of object it is, what tablespace it resides in, etc). OID isn't sufficient, however, as we know from the dependency system. To address this, we would need OID and SubOID. Now, any information which we can derive from those should not be included in the API. To be honest, I don't think we've actually been all that bad about this, but I'll reserve any definitive answer until I've gone back through the API we have specifically thinking about this issue. On further thought, I'm probably wrong and should have caught this during my review. Sorry. Second, the information we *don't* have from above is generally information about what the requesting action is. For example, when changing ownership of an object, we can't possibly use introspection to find out the role which is on the receiving end, since at that time we've just learned it from the parser. Now, we might build an entire new object, pass the "result of this action" OID to the security system and ask it "can we change OID X into OID Y?", but I don't particularly like it. We really don't want to do any *changes* to things until after we've determined the permissions allow for it, and I'm not sure how to get around that without building an independent introspection system for "what might be". Perhaps we're comfortable enough saying "we'll just rollback the command if it turns out to have not been allowed" but I just don't like it. Feels like a higher risk solution to me. I don't see a way to get around the second piece since what information is needed about the action is typically action-specific. Perhaps we could have an 'action-ID' (uh, we have an ID per command already, no? Probably doesn't fit the mold close enough though), and then a way to query information about "what is this action trying to do?". Doesn't seem likely to be very clean though. Other thoughts? Thanks, Stephen
On Fri, Dec 11, 2009 at 1:52 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> I actually have an idea how to solve the problem in this particular >> case, but I'm reluctant to say what it is because I'm not sure if I'm >> right, and at any rate *I don't want to write this patch*. > > As far as crap goes, I'd have to put this at the top. If you're not > willing to share ideas, then I may have to reconsider my personal > feeling on if you should be a committer or not. No one is asking you to > write the patch. We all know that we can be wrong (I tend to be more > wrong than most), and we all hate to "jerk people around", but I feel > it's far worse to self-censor discussion on ideas. OK, it's clear that I've handled this badly. Sorry. My fear (however unjustified) was that someone would go and rewrite the patch based on an opinion that I express whether they agree with it or not. I don't know the right way to do this and I'm sorry to have given you the impression that I think I do and am hiding the ball. So with that said, the idea I had was to try to pass around pre-existing data structures related to the objects on which access control decisions are being made, rather than Oids. It's pretty clear that you're never going to be able to make an access control decision just based on the Oid, but the Relation descriptor or pg_something HeapTuple might be enough - or at least whatever else you need is likely something you would have had to look up anyway, even without the interface layer. I don't know if that makes sense or actually works, but you could give it a try. > It's also about the worst form of rock-management that I think I could > come up with in an open source community. If you don't share your idea, > yet you feel that it's "right", and see nothing to dissuade you from > that position (after all, we can't present an argument for or against it > if we don't know what it is), then I find it likely that you're going to > constantly be comparing patches presented to the ideal one in your head > based on your idea and we'd never get there. It's a little unfortunate that we're arguing about this because that's exactly what I'm reacting AGAINST, and emphatically not when I intend to do. I think this is the first time in my adult life I've been criticized for being too UN-willing to share my opinions, but I guess there's a first time for everything. Again, sorry for handling this badly. I just feel like the discussions that we've had so far have been very much in the dynamic of throw some code over the wall and see if the committer likes it... looks like no, let's go back around and try again. It does have a bit of a rock management feel to it and I really want to see if we can find a way to break that cycle. ...Robert
David, * David P. Quigley (dpquigl@tycho.nsa.gov) wrote: > So the document I read is linked below [1]. Great, thanks again. [agree with all the rest] > It is definitely good to have a second opinion on this since I've just > only started reading the PCI compliance documents. I'm definitely not an > expert in PCI compliance but from what I've read there are definite > benefits for using SEPG or PG-ACE with a special security module in > making much stronger guarantees about who and what can touch the card > data. Indeed. The other nice piece about getting the opinion of Treat (or others who have to deal with PCI) is that while the PCI documentation says what you're supposed to do, the PCI folks also have auditing requirments (as in, a third-party vendor has to audit your system, and there are required scans and scanning tools, etc) which don't always marry up to what they say they require. Thanks! Stephen
* David P. Quigley (dpquigl@tycho.nsa.gov) wrote: > Yea I never asked Stephen if he goes by Stephen or Steve when I met him > on Wednesday. I guess calling him Steve is me being a bit > presumptuous :) Oh, either is fine, tho people will probably follow a bit better if you say "Stephen". As a reminder- KaiGai's the one who did all the actual code, I just tried to steer him in a direction I thought made sense to make it easier to get core to accept it, and reviewed the results of his work. Thanks! Stephen
On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfrost@snowman.net> wrote: > Second, the information we *don't* have from above is generally > information about what the requesting action is. For example, when > changing ownership of an object, we can't possibly use introspection to > find out the role which is on the receiving end, since at that time > we've just learned it from the parser. I'm not sure that I follow what you're saying here. I think maybe it would help to discuss a concrete example, which is why I proposed a concept patch. Or perhaps you'd like just to pick out a specific case to discuss. > Now, we might build an entire > new object, pass the "result of this action" OID to the security system > and ask it "can we change OID X into OID Y?", but I don't particularly > like it. We really don't want to do any *changes* to things until after > we've determined the permissions allow for it, and I'm not sure how to > get around that without building an independent introspection system for > "what might be". Perhaps we're comfortable enough saying "we'll just > rollback the command if it turns out to have not been allowed" but I > just don't like it. Feels like a higher risk solution to me. Yeah, that seems like a non-starter. > I don't see a way to get around the second piece since what information > is needed about the action is typically action-specific. Perhaps we > could have an 'action-ID' (uh, we have an ID per command already, no? > Probably doesn't fit the mold close enough though), and then a way to > query information about "what is this action trying to do?". Doesn't > seem likely to be very clean though. Object creation seems to be one of the tougher cases here. When you're altering or dropping an existing object, the decision is likely to be based (in any system) on the properties of that object. When you're creating an object, the decision will of course have to be based on the properties of something else, but different access control models might not agree on the value of "something else". It's not immediately clear to me how to deal with that, but again it's hard for me to discuss it in the abstract. ...Robert
On Fri, 2009-12-11 at 14:11 -0500, Stephen Frost wrote: > All, > > * Robert Haas (robertmhaas@gmail.com) wrote: > > If we design a security abstraction layer, the interfaces need to > > really be abstraction boundaries. Passing the table OID and then also > > the tablespace OID because PG DAC needs that to make its access > > control decision is crap. > > Now, to address the small useful bit of this mail- I tend to agree with > this. I'm not convinced there's an alternative, but I'd like to throw > out a couple of my ideas on how it could be addressed. I'd like to > solicit for feedback on these. > > First off, we have alot of the information available from the catalog. > Basically, given an OID, we should be able to find out the other > information associated with that OID (such as what kind of object it is, > what tablespace it resides in, etc). OID isn't sufficient, however, as > we know from the dependency system. To address this, we would need OID > and SubOID. Now, any information which we can derive from those should > not be included in the API. To be honest, I don't think we've actually > been all that bad about this, but I'll reserve any definitive answer > until I've gone back through the API we have specifically thinking about > this issue. On further thought, I'm probably wrong and should have > caught this during my review. Sorry. > > Second, the information we *don't* have from above is generally > information about what the requesting action is. For example, when > changing ownership of an object, we can't possibly use introspection to > find out the role which is on the receiving end, since at that time > we've just learned it from the parser. Now, we might build an entire > new object, pass the "result of this action" OID to the security system > and ask it "can we change OID X into OID Y?", but I don't particularly > like it. We really don't want to do any *changes* to things until after > we've determined the permissions allow for it, and I'm not sure how to > get around that without building an independent introspection system for > "what might be". Perhaps we're comfortable enough saying "we'll just > rollback the command if it turns out to have not been allowed" but I > just don't like it. Feels like a higher risk solution to me. > > I don't see a way to get around the second piece since what information > is needed about the action is typically action-specific. Perhaps we > could have an 'action-ID' (uh, we have an ID per command already, no? > Probably doesn't fit the mold close enough though), and then a way to > query information about "what is this action trying to do?". Doesn't > seem likely to be very clean though. > > Other thoughts? In the Linux LSM case, we define a separate hook interface for each logical operation/action, where hook name identifies the action/operation and the set of arguments to that hook interface are the complete set of inputs that may be relevant to deciding whether to permit the operation/action. These arguments typically include pointer(s) to one or more object data structures as well as ancillary arguments (e.g. new owner value if chown). Reference: http://www.usenix.org/event/sec02/wright.html http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h The XACE framework for the X server is described by: http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html Unlike the LSM framework, it passes resource identifiers rather than direct object pointers. The FreeBSD MAC framework is described by: http://www.freebsd.org/doc/en/books/arch-handbook/mac.html It provides more abstraction than LSM does, at a cost in the overhead of the framework itself. -- Stephen Smalley National Security Agency
* Robert Haas (robertmhaas@gmail.com) wrote: > OK, it's clear that I've handled this badly. Sorry. My fear (however > unjustified) was that someone would go and rewrite the patch based on > an opinion that I express whether they agree with it or not. That's always going to be a risk in an open-discussion environment. Additionally, that's exactly what happened to me last go round- KaiGai rewrote the patch based on my ideas and suggestions, and the result was summarairly tossed out by Tom. Did it suck? Yes, heavily, and it frustrated me to the point that I specifically asked to not be the reviewer for SEPG during the next commitfest. At the same time, what KaiGai or others spend time on is up to them (and/or their employers). I sincerely hope that even if you suggest an approach down the road unrelated to this on some other patch you're reviewing, and then you see the results and say "whoah, that's horrible, and should never be committed", that you understand none of us would want you to commit it. Sharing your ideas or putting out suggestions isn't a commitment on your part that you'll commit the results when someone else rights it. Heck, I bet you've been down that road on your own projects and come to the realization at the end of "err, bad idea" and not committed it. Allow me to say, my apologies, I feel like I may have over-reacted a bit for my part as well. > So with that said, the idea I had was to try to pass around > pre-existing data structures related to the objects on which access > control decisions are being made, rather than Oids. That thought had crossed my mind as well, but I wasn't convinced that would actually be seen as a signifigantly different API to just having the arguments passed inline... Then again, using structures does allow you to add to them without having to modify the function definitions, and would allow David's suggestion of using function pointers to work, which we do in some other specific cases. I guess I'm curious if we (PG) have any particular feeling one way or the other about function pointers; I just don't recall seeing them used terribly often and would worry about that they might be passively discouraged? > It does have a bit of a rock management feel to it and I > really want to see if we can find a way to break that cycle. Agreed. It's been a point of frustration for me, but I've been trying to work with it so long as we at least get some constructive critisim back (Tom's review of the patch I reviewed fell into the "questionable" category for me on that call, which is what really frustrated me the most about it). A cyclic approach is typical in all software development, it's when information stops flowing about why something doesn't meet expectations or requirments that progress breaks down. Thanks! Stephen
* Robert Haas (robertmhaas@gmail.com) wrote: > On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Second, the information we *don't* have from above is generally > > information about what the requesting action is. For example, when > > changing ownership of an object, we can't possibly use introspection to > > find out the role which is on the receiving end, since at that time > > we've just learned it from the parser. > > I'm not sure that I follow what you're saying here. I think maybe it > would help to discuss a concrete example, which is why I proposed a > concept patch. Or perhaps you'd like just to pick out a specific case > to discuss. Hrm, I thought I had given a specific example. Didn't do a good job of it, apparently. Let me try to be a bit more clear: ALTER TABLE x OWNER TO y; If given the table OID, there's a ton of information we can then pull about the table- the tablespace, the owner, the schema, the columns, the privileges, etc, etc. What we can't possibly figure out from the OID is the value of y. Yet, in the PG security model, the value of y matters! You have to know what y is to check if y has 'create' rights on the schema. If it doesn't (and the user executing the command isn't the superuser) then the request (under the PG model) is denied. Does that help clarify my example case? > Object creation seems to be one of the tougher cases here. When > you're altering or dropping an existing object, the decision is likely > to be based (in any system) on the properties of that object. When > you're creating an object, the decision will of course have to be > based on the properties of something else, but different access > control models might not agree on the value of "something else". It's > not immediately clear to me how to deal with that, but again it's hard > for me to discuss it in the abstract. That sounds like a pretty good example to me too, to be honest. It goes back to the same issue though- that's information you get from the command that's trying to be run and isn't available from existing objects. Using structures to track this information, allowing the function arguments to remain identical, is certainly something which can be done, and probably done with a minimal amount of fuss. Thanks, Stephen
Stephen (great name!), * Stephen Smalley (sds@tycho.nsa.gov) wrote: > Reference: > http://www.usenix.org/event/sec02/wright.html > http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h > > The XACE framework for the X server is described by: > http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html > > The FreeBSD MAC framework is described by: > http://www.freebsd.org/doc/en/books/arch-handbook/mac.html Thanks for these pointers! I'm sure KaiGai has probably already done a review of these, but I'll take a look and would ask others who are interested to please do the same. Seeing the different options that people have gone with (as opposed to just the SELinux/kernel version) will undoubtably be helpful in deciding the best approach forward. Thanks again! Stephen
On Fri, Dec 11, 2009 at 3:28 PM, Stephen Frost <sfrost@snowman.net> wrote: > I sincerely hope that even if you suggest an approach down the road > unrelated to this on some other patch you're reviewing, and then you see > the results and say "whoah, that's horrible, and should never be > committed", that you understand none of us would want you to commit it. I have to thank you for saying this - unfortunately, I don't think everyone takes this approach. As you can probably figure out, my alleged rock management upthread was actually a poorly executed attempt to avoid being accused of bait-and-switch. If I don't tell you how to write the patch, you can't accuse me of moving the goalposts (of course I've now discovered the pitfalls of that approach as well...). > Sharing your ideas or putting out suggestions isn't a commitment on your > part that you'll commit the results when someone else rights it. Heck, > I bet you've been down that road on your own projects and come to the > realization at the end of "err, bad idea" and not committed it. Well, I haven't been a committer long enough to have gone through that precise process, but sure, I've tossed out ideas when they don't turn out to be good. >> So with that said, the idea I had was to try to pass around >> pre-existing data structures related to the objects on which access >> control decisions are being made, rather than Oids. > > That thought had crossed my mind as well, but I wasn't convinced that > would actually be seen as a signifigantly different API to just having > the arguments passed inline... If you'll forgive me for saying so, this is exactly the sort of thinking that I think is killing us. Who cares how it will be seen? Seen by whom? We shouldn't be writing this code to be seen - we should be writing it to be good. If doing this makes a clean, tight abstraction layer, then it's a good design. If it doesn't, then it sucks. I realize that opinions enter into this at some level, but let's try to proceed as though there's a technically right answer out there and bend our best efforts to finding it. > Then again, using structures does > allow you to add to them without having to modify the function > definitions, Personal opinion time, but I think that "without having to modify the function definitions" is a CRITICAL design component. Furthermore, "adding to them [the structures]" shouldn't be something that only happens when we decide to support a new security model, or we're little better off than if we just passed a kajillion arguments. Again, I don't want to overstate my confidence in this point, but it feels to me like we need to pass PRE-EXISTING data structures that are already being used for other things and happen to be the right stuff to enable access control decisions, and to which fields that are likely to be needed are likely to get added anyway. But it's difficult to know whether this approach can be made to work without trying it, and there are bound to be problem cases that need to be thought about, and that thinking will be more likely to lead to a good result if it happens in the community, rather than by KaiGai or any other single person in isolation. > and would allow David's suggestion of using function > pointers to work, which we do in some other specific cases. I guess I'm > curious if we (PG) have any particular feeling one way or the other > about function pointers; I just don't recall seeing them used terribly > often and would worry about that they might be passively discouraged? I'm going to vote fairly strongly against inserting function pointers at the outset. I think that we should look at the first phase of this project as an attempt to restructure the code so that the access control decisions are isolated from the rest of the code. *If* we can do that successfully, I think it will represent good progress all on its own. Inserting function pointers is something that can be done later if it turns out to be useful with a very small, self-contained patch. >> It does have a bit of a rock management feel to it and I >> really want to see if we can find a way to break that cycle. > > Agreed. It's been a point of frustration for me, but I've been trying > to work with it so long as we at least get some constructive critisim > back (Tom's review of the patch I reviewed fell into the "questionable" > category for me on that call, which is what really frustrated me the > most about it). A cyclic approach is typical in all software > development, it's when information stops flowing about why something > doesn't meet expectations or requirments that progress breaks down. Part of my frustration here is that I don't see a lot of evidence that anyone is willing to put really tangible resources into this other than KaiGai and his employer. I don't want to keep reviewing the same patches over again just because they keep getting resubmitted with various modifications. I am willing to try to be helpful with this project if that is something that you and others who are involved feel is helpful and if it can be done with a small time commitment or if, uh, I get paid. But I don't want to see a lot of community resources go into a project that is basically doomed from the get-go because KaiGai is the only one caring about it. This has already gone on for a really long time with less progress than might be hoped for, and if it's not going to live, I want it to die. Having it stick around as a zombie is the worst possible outcome. ...Robert
On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost@snowman.net> wrote: > Hrm, I thought I had given a specific example. Didn't do a good job of > it, apparently. Let me try to be a bit more clear: > > ALTER TABLE x OWNER TO y; > > If given the table OID, there's a ton of information we can then pull > about the table- the tablespace, the owner, the schema, the columns, the > privileges, etc, etc. > > What we can't possibly figure out from the OID is the value of y. Yet, > in the PG security model, the value of y matters! You have to know what > y is to check if y has 'create' rights on the schema. If it doesn't > (and the user executing the command isn't the superuser) then the > request (under the PG model) is denied. > > Does that help clarify my example case? That case doesn't seem terribly problematic to me. It seems clear that we'll want to pass some information about both x and y. What is less clear is exactly what the argument types will be, and the right answer probably depends somewhat on the structure of the existing code, which I have not looked at. What I'm more concerned about is if the access control decision in this case were based on u for PG DAC, v for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System. If that's the case, and our function signature looks like (x,y,u,v,w), the we should worry. ...Robert
* Robert Haas (robertmhaas@gmail.com) wrote: > If I don't tell > you how to write the patch, you can't accuse me of moving the > goalposts (of course I've now discovered the pitfalls of that approach > as well...). Indeed, we also yell and scream when we don't know which direction the goalposts are in. ;) > > That thought had crossed my mind as well, but I wasn't convinced that > > would actually be seen as a signifigantly different API to just having > > the arguments passed inline... > > If you'll forgive me for saying so, this is exactly the sort of > thinking that I think is killing us. Who cares how it will be seen? erp. mea culpa. I meant that I didn't think of it as being enough of a novelty for you to be suggesting-it-but-not-telling-us.. It just kind of came off as too-obvious, however, the reality is that I didn't understand your suggestion, see below. > > Then again, using structures does > > allow you to add to them without having to modify the function > > definitions, > > Personal opinion time, but I think that "without having to modify the > function definitions" is a CRITICAL design component. Furthermore, > "adding to them [the structures]" shouldn't be something that only > happens when we decide to support a new security model, or we're > little better off than if we just passed a kajillion arguments. > Again, I don't want to overstate my confidence in this point, but it > feels to me like we need to pass PRE-EXISTING data structures that are > already being used for other things and happen to be the right stuff > to enable access control decisions, and to which fields that are > likely to be needed are likely to get added anyway. Ah, now that makes alot of sense.. Unfortunately, having been involved in at least some of this code in the past, sadly I don't think we have such pre-existing data structures for the information that's primairly at issue here. Specifically, the data structures we tend to have pre-existing are the ones that come from the catalog and would fall out from an OID+SubOID based API. Sure, we could pass those structures in instead of using SysCache to pull the data out, but that's not really how we 'typically' do things in the code base from my experience, and I don't really see it having alot of advantage. Using OID+SubOID and SysCache *will* pick up new things as they're added to the catalogs- for the information *in* the catalogs. There are very few data structures outside of the parse tree which include the information from the parse tree.. And to be honest, the ones that *are* out there don't typically have the world's best structure for use by this kind of a framework (thinking back to specifically what's passed around for column-level privs..). > But it's > difficult to know whether this approach can be made to work without > trying it, and there are bound to be problem cases that need to be > thought about, and that thinking will be more likely to lead to a good > result if it happens in the community, rather than by KaiGai or any > other single person in isolation. I agree with this- one issue is, unfortunately, an overabundance from KaiGai of "code-writing man-power". This is an odd situation for this community, in general, so we're having a hard time coming to grasp with it. KaiGai, can you hold off on implementing any of these approaches until we can hammer down something a bit better for you to work from as a baseline? I'll start with Robert's suggestion of a single-object example case and throw out some example code for people to shoot down of different approachs. After a few iterations of that, with comments from all (KaiGai, you're welcome to comment on it too, of course), we'll turn you loose on it again to implement fully (if you're still willing to). Following along that though, as we'd like this to be the design forum, when you come across problems or issues implementing it, could you come back to this forum and explain the issue and why it doesn't fit, as soon as you hit it? What you tend to do is disappear for a while, then come back, instead, with a full patch which works, but has places where you've gone down an unexpected path because you found a case which wasn't covered, designed a solution for it which "kinda" fits and then implemented it immediately. I feel that's something I've encouraged you to do, unfortunately, and my apologies for that. I'm trying to get time from my employer (and my wife) to dedicate to this, to hopefully avoid that happening in the future. > I'm going to vote fairly strongly against inserting function pointers > at the outset. I think that we should look at the first phase of this > project as an attempt to restructure the code so that the access > control decisions are isolated from the rest of the code. *If* we can > do that successfully, I think it will represent good progress all on > its own. Inserting function pointers is something that can be done > later if it turns out to be useful with a very small, self-contained > patch. Sure, works for me. > Part of my frustration here is that I don't see a lot of evidence that > anyone is willing to put really tangible resources into this other > than KaiGai and his employer. I feel like there is momentum here to resolve this. I'm certainly trying to. We're getting more responsive input from the security community too. As we work through and point out the commercial issues this could help solve, I'm hopeful we'll be able to improve the situation further. Josh's discussion about why this isn't some oft-requested feature is a good one, in my view. > Having it stick around as a zombie is the worst possible outcome. I agree, though I have to admit that I'm torn because I really feel this would be a great additional capability for PG. Thanks, Stephen
* Robert Haas (robertmhaas@gmail.com) wrote: > On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Does that help clarify my example case? > > That case doesn't seem terribly problematic to me. It seems clear > that we'll want to pass some information about both x and y. What is > less clear is exactly what the argument types will be, and the right > answer probably depends somewhat on the structure of the existing > code, which I have not looked at. Allow me to assist- y is never in a structure once you're out of the parser: ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing) I expect you'll find this is more the rule than the exception to alot of the existing PG security model, because much of it's responsibility is in what I'll call the DDL (under commands/) aspects. The DML pieces (under the executor) are a bit better about this, specifically you could pass in a RangeTblEntry, exactly how ExecCheckRTEPerms handles it. Actually, in a fit of barely-contained mirth, it strikes me that PG really has already done what you're suggesting for the 'hard' part- and the RangeTblEntry plus ExecCheckRTEPerms is exactly it. It's all the *other* checks we do for the PG security model, under commands/, that are the problem here. The parts of the code that, to be honest, I think all us database geeks have historically cared alot less about. > What I'm more concerned about is if > the access control decision in this case were based on u for PG DAC, v > for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System. > If that's the case, and our function signature looks like (x,y,u,v,w), > the we should worry. Right, I understand that. What I offer in reply is that we focus our attention on using the OID+SubOID approach, as I'm suggesting, to the fullest extent possible through that mechanism, and appreciate that the other arguments passed to the function are derived specifically from the parser and therefore unlikely to be changed until and unless we change the base syntax of the command and calling function, at which time we may have to add arguments to the function signature. This would continue at least until we get to the point where we decide that the caller needs to be changed because it's got a huge function sig, and move it to something like the structure of the executor and the equivilant of ExecCheckRTEPerms() would get updated along with it, at that time. Thanks, Stephen
Stephen Frost wrote: > I agree with this- one issue is, unfortunately, an overabundance from > KaiGai of "code-writing man-power". This is an odd situation for this > community, in general, so we're having a hard time coming to grasp with > it. There are plenty of parallels to when Zdenek was writing a ton of in-place upgrade code faster than anyone else was fully consuming it. The "do it right or don't do it at all" approach of the PG community seems particularly hard to reconcile with larger patches from people we don't get enough face time with. It's easy to get deadlocked and not have a good way to navigate out when faced with a set of difficult decisions and only electronic communications between participants. Shoot, you and Robert have spent time doing technical arguments in person and we still got a little rough patch on-list this week out of the debate. I hate to even use this terminology, but these big patches seem to need a project manager advocate sometimes: someone who knows everyone well enough to clear these stalled spots, smooth over any personality conflicts, and is motivated to intervene because they need the feature. I see it as a sort of scaling problem that might be a recurring one. It would be nice if we could all get better at identifying when it does happen, and perhaps find someone to help with planning before we waste so much time chasing code that isn't going to be accepted yet again. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
I just did a round of integrating some of the big-picture feedback that has shown up here since the meeting into http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG , mainly supplementing the references in the "Works outside of SELinux" section with the new suggested reading here suggested by Stephen Smalley and Joshua Brindle. I'm trying to keep that a fairly readable intro to the controversial parts rather than going deeply technical. What I'm not going to try to track is all the low-level implementation details that are bouncing around right now, my brain is too full this week to cram more about OID trivia into it right now. That would be a good idea for someone to summarize eventually and then throw that onto the wiki somewhere else, so that it's easier to remember the context of what/why decisions were made. The way Simon has been keeping an ongoing log at http://wiki.postgresql.org/wiki/Hot_Standby shows a reasonable way to organize such a thing from a similarly complicated patch. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Fri, Dec 11, 2009 at 5:36 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost@snowman.net> wrote: >> > Does that help clarify my example case? >> >> That case doesn't seem terribly problematic to me. It seems clear >> that we'll want to pass some information about both x and y. What is >> less clear is exactly what the argument types will be, and the right >> answer probably depends somewhat on the structure of the existing >> code, which I have not looked at. > > Allow me to assist- y is never in a structure once you're out of the > parser: Well this is why you're writing the patch and not me. :-) > ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing) > > I expect you'll find this is more the rule than the exception to alot of > the existing PG security model, because much of it's responsibility is > in what I'll call the DDL (under commands/) aspects. The DML pieces > (under the executor) are a bit better about this, specifically you could > pass in a RangeTblEntry, exactly how ExecCheckRTEPerms handles it. > > Actually, in a fit of barely-contained mirth, it strikes me that PG > really has already done what you're suggesting for the 'hard' part- and > the RangeTblEntry plus ExecCheckRTEPerms is exactly it. It's all the > *other* checks we do for the PG security model, under commands/, that > are the problem here. The parts of the code that, to be honest, I think > all us database geeks have historically cared alot less about. Hmm, interesting. >> What I'm more concerned about is if >> the access control decision in this case were based on u for PG DAC, v >> for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System. >> If that's the case, and our function signature looks like (x,y,u,v,w), >> the we should worry. > > Right, I understand that. What I offer in reply is that we focus our > attention on using the OID+SubOID approach, as I'm suggesting, to the > fullest extent possible through that mechanism, and appreciate that the > other arguments passed to the function are derived specifically from the > parser and therefore unlikely to be changed until and unless we change > the base syntax of the command and calling function, at which time we > may have to add arguments to the function signature. This would > continue at least until we get to the point where we decide that the > caller needs to be changed because it's got a huge function sig, and > move it to something like the structure of the executor and the > equivilant of ExecCheckRTEPerms() would get updated along with it, at > that time. What exactly do you mean by a SubOID? I'm not really following that part. ...Robert
Robert Haas <robertmhaas@gmail.com> writes: > What exactly do you mean by a SubOID? I'm not really following that part. I assume he's talking about the object reference representation used in pg_depend, which is actually class OID + object OID + sub-object ID. The only object type that has sub-objects at the moment is tables, wherein the sub-objects are columns and the sub-object IDs are column numbers. The sub-object ID is zero for all other cases. regards, tom lane
Robert Haas wrote: > On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost@snowman.net> wrote: >> Hrm, I thought I had given a specific example. Didn't do a good job of >> it, apparently. Let me try to be a bit more clear: >> >> ALTER TABLE x OWNER TO y; >> >> If given the table OID, there's a ton of information we can then pull >> about the table- the tablespace, the owner, the schema, the columns, the >> privileges, etc, etc. >> >> What we can't possibly figure out from the OID is the value of y. Yet, >> in the PG security model, the value of y matters! You have to know what >> y is to check if y has 'create' rights on the schema. If it doesn't >> (and the user executing the command isn't the superuser) then the >> request (under the PG model) is denied. >> >> Does that help clarify my example case? > > That case doesn't seem terribly problematic to me. It seems clear > that we'll want to pass some information about both x and y. What is > less clear is exactly what the argument types will be, and the right > answer probably depends somewhat on the structure of the existing > code, which I have not looked at. What I'm more concerned about is if > the access control decision in this case were based on u for PG DAC, v > for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System. > If that's the case, and our function signature looks like (x,y,u,v,w), > the we should worry. Theoretically, (x,y,u) -> (x,y,u,v) -> (x,y,u,v,w) may happen. However, if the new suggested security model is too far from the known security model, we should consider whether it performs correctly at first before commit it. As long as we describe a security model corresponding to database objects, it is hard to consider a possibility of infinite increasing in the future. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > Unlike Tom (I think), I do believe that there is demand (possibly only > > from a limited number of people, but demand all the same) for this > > feature. > > Please note that I do not think there is *zero* demand for the feature. > There is obviously some. What I find highly dubious is whether there is > enough demand to justify the amount of effort, both short- and long-term, > that the community would have to put into it. Well, the bottom line is that this effort should grow the development and user community of Postgres --- it if doesn't, it is a failure. > > And I also believe that most people in our community are > > generally supportive of the idea, but only a minority are willing to > > put in time to make it happen. So I have no problem saying to the > > people who want the feature - none of our committers feel like working > > on this. Sorry. On the other hand, I also have no problem telling > > them - good news, Bruce Momjian thinks this is a great feature and > > wants to help you get it done. I *do* have a problem with saying - we > > don't really know whether anyone will ever want to work on this with > > you or not. > > If I thought that Bruce could go off in a corner and make this happen > and it would create no demands on anybody but him and KaiGai-san, I > would say "fine, if that's where you want to spend your time, go for > it". But even to state that implied claim is to see how false it is. > Bruce is pointing to the Windows port, but he didn't make it happen > by himself, or any close approximation of that. Everybody who works > on this project has been affected by that, and we're *still* putting > significant amounts of time into Windows compatibility, over five years > later. The Windows port was primiarly done by Magnus, Claudio Natoli, and Andrew Dunstan. The good thing about that group is that their involvement in Win32 did not take them away from existing Postgres work --- in fact I think it increased Magnus's and Andrew's involvement. As I stated above, I expect the SE-Postgres work to be done mostly by new people and to expand our development team. KaiGai is certainly a new addition, and I think there is already an indication that new people are getting involved. Of course, our existing people will have to help too, but as I stated a few days ago, I expect security-specific stuff to be maintained mostly by new people, and our existing folks are going to have to help with hooks, plus adding things like mandatory access control and row-level security to base Postgres. (I do think it is inevitable that those will be added some day. I agree the security folks will be accelerating that. Hopefully we will get more good out of this than the inconvenience of this accelerated security stuff.) > My guess is that a credible SEPostgres offering will require a long-term > amount of work at least equal to, and very possibly a good deal more > than, what it took to make a native Windows port. If SEPostgres could > bring us even 10% as many new users as the Windows port did, it'd > probably be a worthwhile use of our resources. But again, that's an > assumption that's difficult to type without bursting into laughter. Odds are SEPostgres will add perhaps 1% new users compared to Win32, but perhaps very important, energetic, and visible users. As stated earlier, the base Postgres security additions like row-level security are going to be inconvenient, but I do think we will eventually need them anyway, so I don't see them as SE-Postgres burdens. I am not replying to many of these emails so I don't appear to be brow-beating (forcing) the community into accepting this features. I might be brow-beating the community, but I don't want to _appear_ to be brow-beating. ;-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, Dec 11, 2009 at 8:41 PM, Bruce Momjian <bruce@momjian.us> wrote: > I am not replying to many of these emails so I don't appear to be > brow-beating (forcing) the community into accepting this features. I > might be brow-beating the community, but I don't want to _appear_ to be > brow-beating. ;-) LOL. At least you're honest... ...Robert
Bruce Momjian wrote: > Well, the bottom line is that this effort should grow the development > and user community of Postgres --- it if doesn't, it is a failure. Really? Even if it only allows existing Postgres users and companies to expand their use into higher security applications IMHO it's a success. If a main goal were increasing users, implementing MySQL-isms and MSFTSqlServer-isms would seem the biggest bang for the buck.
* Robert Haas (robertmhaas@gmail.com) wrote: > > Allow me to assist- y is never in a structure once you're out of the > > parser: > > Well this is why you're writing the patch and not me. :-) Sure, just trying to explain why your suggestion isn't quite the direction that probably makes the most sense.. At least for args which come from the parser. > What exactly do you mean by a SubOID? I'm not really following that part. Sorry, it's basically things like attnum, check the dependency code for example usage. It's "this is something we need to track due to dependencies but it's at a level below OID", or perhaps "a component of an object which has an OID"- specifically: a column of a table. The table has an OID, but the column does not. To uniquely identify the column you need both the OID and the 'SubOID'/attnum. Thanks, Stephen
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > What exactly do you mean by a SubOID? I'm not really following that part. > > I assume he's talking about the object reference representation used in > pg_depend, which is actually class OID + object OID + sub-object ID. > The only object type that has sub-objects at the moment is tables, > wherein the sub-objects are columns and the sub-object IDs are column > numbers. The sub-object ID is zero for all other cases. You're right, of course, but for some reason I thought that there was another usage of it besides just the table/column case. Thanks, Stephen
* Stephen Frost (sfrost@snowman.net) wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > I assume he's talking about the object reference representation used in > > pg_depend, which is actually class OID + object OID + sub-object ID. > > The only object type that has sub-objects at the moment is tables, > > wherein the sub-objects are columns and the sub-object IDs are column > > numbers. The sub-object ID is zero for all other cases. > > You're right, of course, but for some reason I thought that there was > another usage of it besides just the table/column case. Ah, I realize what I was thinking about now.. The dependency system has two flavors (pg_depend and pg_shdepend). We had SubIDs for columns in pg_depend but not pg_shdepend- until column-level privs were added which meant we could have roles depend on columns (due to privileges on that column). To clarify- pg_depend is for database dependencies while pg_shdepend is for cluster dependencies. Thanks, Stephen
* Bruce Momjian (bruce@momjian.us) wrote: > I am not replying to many of these emails so I don't appear to be > brow-beating (forcing) the community into accepting this features. I > might be brow-beating the community, but I don't want to _appear_ to be > brow-beating. ;-) My apologies if I come across this way- I don't intend to... But I'm also very enthusiastic about this. Also, it's become a much more personal issue for me due to this: http://csrc.nist.gov/news_events/documents/omb/draft-omb-fy2010-security-metrics.pdf OMB is now looking to include label-based security in their metrics. This directly impacts some of the PG-based systems I run. Thanks, Stephen
Stephen Frost wrote: > * Bruce Momjian (bruce@momjian.us) wrote: > > I am not replying to many of these emails so I don't appear to be > > brow-beating (forcing) the community into accepting this features. I > > might be brow-beating the community, but I don't want to _appear_ to be > > brow-beating. ;-) > > My apologies if I come across this way- I don't intend to... But I'm You are fine. I was just saying that at a time I was one of the few loud voices on this, and if this is going to happen, it will be because we have a team that wants to do this, not because I am being loud. I see the team forming nicely. > also very enthusiastic about this. Also, it's become a much more > personal issue for me due to this: > > http://csrc.nist.gov/news_events/documents/omb/draft-omb-fy2010-security-metrics.pdf > > OMB is now looking to include label-based security in their metrics. > This directly impacts some of the PG-based systems I run. Ah, very interesting, and good. -- 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, * Bruce Momjian (bruce@momjian.us) wrote: > You are fine. I was just saying that at a time I was one of the few > loud voices on this, and if this is going to happen, it will be because > we have a team that wants to do this, not because I am being loud. I > see the team forming nicely. Not to rain down on the parade too much here, but I have to disagree about a team forming nicely. That's, unfortunately, what it looks like from the 10k-foot level. Indeed, it looks like we're making good headway to get some kind of support into core from that level. The reality is that we've barely started and really have still got quite a ways to go and it would really be useful to bring in additional resources on this. I wouldn't consider myself to be that "additional resource" unless and until I can get funding for dedicated time (either my own or someone else's). I've got a few action items that I'm planning to resolve in the next few weeks, but I've been involved in this for over a year now and it hasn't made much progress, overall, in that time. So, for anyone else who's interested in label-based security happening for PostgreSQL (for whatever reason, masochisim perfectly acceptable), please speak up and offer to help. We could use it. Thanks, Stephen
On Mon, Dec 14, 2009 at 10:21 PM, Stephen Frost <sfrost@snowman.net> wrote: > Bruce, > > * Bruce Momjian (bruce@momjian.us) wrote: >> You are fine. I was just saying that at a time I was one of the few >> loud voices on this, and if this is going to happen, it will be because >> we have a team that wants to do this, not because I am being loud. I >> see the team forming nicely. > > Not to rain down on the parade too much here, but I have to disagree > about a team forming nicely. That's, unfortunately, what it looks like > from the 10k-foot level. Indeed, it looks like we're making good > headway to get some kind of support into core from that level. > > The reality is that we've barely started and really have still got > quite a ways to go and it would really be useful to bring in additional > resources on this. I wouldn't consider myself to be that "additional > resource" unless and until I can get funding for dedicated time (either > my own or someone else's). I've got a few action items that I'm > planning to resolve in the next few weeks, but I've been involved in > this for over a year now and it hasn't made much progress, overall, in > that time. I completely agree. Many people have spent substantial time trying to help KaiGai extract a committable patch from his work, and that effort has not been successful. What I am concerned about is that by continuing to spend time on KaiGai's work, we are wasting a lot of community resources to no good end. It may be the case that even if we had a patch that was technically excellent, the community would decide that the amount of future maintenance that this feature would require is not warranted by the number of users it would attract. Tom is the only really vocal advocate that I'm aware of for that position, but there may well be other people who feel similarly. But these patches are, unfortunately, not technically excellent. There have been multiple reviews of these patches that have produced extensive laundry lists of items to be fixed. In the ordinary course of events, that leads to one of two things happening: either the patch author fixes most or all the problems and comes back with a patch that shows marked improvement, or he or she gives up. This patch is unique in my experience in that it has gone through - I believe - six CommitFests now without either of those things happening. Not that there hasn't been any improvement, but the ratio of reviewing-work to improvement seems to be much higher than what is typical for us. Like Stephen, I believe we need some additional resources who can improve that ratio before we can really make a push to get this done. ...Robert
(2009/12/16 0:03), Robert Haas wrote: > But these patches are, unfortunately, not technically excellent. > There have been multiple reviews of these patches that have produced > extensive laundry lists of items to be fixed. In the ordinary course > of events, that leads to one of two things happening: either the patch > author fixes most or all the problems and comes back with a patch that > shows marked improvement, or he or she gives up. This patch is unique > in my experience in that it has gone through - I believe - six > CommitFests now without either of those things happening. Not that > there hasn't been any improvement, but the ratio of reviewing-work to > improvement seems to be much higher than what is typical for us. Like > Stephen, I believe we need some additional resources who can improve > that ratio before we can really make a push to get this done. I had a talk with Stephen off list to make clear what I wondered. It became apparent that I misunderstood the meaning of "cleanup first". IIUC, he suggested to consolidate permission checks in several places (such as createdb()) into same place to make more suitable for upcoming framework, but the default PG checks are still inlined, not consolidated to backend/security/*. He also concerned our earlier approach has required higher hurdle to join development, because it tried to do something useful feature although a lot of features are separated, so past patch had to touch both of core routines and selinux specific code. So, I agreed with his opinion that we should restart from the pure cleanup of the existing PG checks to make them more suitable for the upcoming security framework. The scope of this effort stay in the pgsql world 100%. I don't think it is an incorrect approach now. In actually, I was suggested similar things at the begining of CF#3 from Itagaki-san, but it was unclear whether we should go through the smaller SE-PgSQL patch first or security framework first at that time. I'll submit a small conceptual patch soon, as a draft. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>