diff for duplicates of <49D1EAE7.8050100@rubix.com> diff --git a/a/1.txt b/N1/1.txt index 4fde138..1006b52 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -178,4 +178,7 @@ KaiGai Kohei wrote: > * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3) > > Thanks, -> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/8207c5eb/attachment.html diff --git a/a/2.bin b/a/2.bin deleted file mode 100644 index 1d90041..0000000 --- a/a/2.bin +++ /dev/null @@ -1,193 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <meta content="text/html;charset=ISO-2022-JP" - http-equiv="Content-Type"> -</head> -<body bgcolor="#ffffff" text="#000000"> -<font face="Arial">looks good to me. <br> -<br> -One minor comment. For the superuser permission, this may be common use -of DBMS's but I believe is not a standard SQL feature. RUBIX has no -such concept, so we would generally ignore that permission. Also, it is -unclear to me what abilities the superuser should have (in the general -sense, not necessarily within sepostgresql). Is this just a permission -to override SQL DAC, or does it also give administrative abilities like -setting audit configurations, or "all the above." I think you said -before that it would not allow MAC override, correct? <br> -<br> -RUBIX currently has four privileged "roles":<br> -Database Administrator: DAC override <br> -Security Administrator: MAC override, to some degree. With SELinux much -of this can be done with discrete rules.<br> -Audit Administrator: administer audit trail and criteria<br> -Database Operator: do the normal day-today administrative DBMS tasks, -like backup.<br> -<br> -I am curious, if the intended use of the db_database superuser -permission would be an encapsulation of our all of our roles, excluding -the Security Administrator. <br> -<br> -As a side note, without knowing too much about the intent of the -superuser permission, I would think the categories of "roles" RUBIX -uses would be general enough for just about any database. Thus, -providing equivalent permissions </font><font face="Arial">might be -useful </font><font face="Arial">(excluding the Security -Administrator, which I am guessing the community would say is not -needed because MAC override mechanisms exist within SELinux already) .<br> -</font><br> -KaiGai Kohei wrote: -<blockquote cite="mid:49D1DA85.1030902@ak.jp.nec.com" type="cite"> - <pre wrap="">As we have discussed for the recent week, I have a plan to rework -some of security policy for SE-PostgreSQL. - -The attached patch adds the significan changes, as follows. -Could you give me any suggestion, approval or opposition? - -New object classes and permissions ----------------------------------- - * db_catalog class - It shows the top level namespace in the database, and has a capability - to store a set of schemas. Some of implementation does not support - catalogs. In this case, we simply ignore this class and any schemas - are placed under the db_database directly. - - It defines the following four permissions and inherited ones: - { search add_object remove_object associate } - - Client should have db_catalog:{search} on the catalog when he refers - any schemas under the catalog, and he should also have - db_catalog:{add_object} and db_catalog:{remove_object} on the catalog - when he tries to add or remove a shema within the catalog. - These permissions are an analogy of dir object class. - - The db_catalog:{associate}, which I've not introduced yet but noticed - its necessity, is also checked when we create or relabel a schema - within the catalog, and the schema should have db_catalog:{associate} - on the catalog. It is an analogy of filesystem:{associate}. - It prevents a schema is labeled unexpectedly. - - * db_schema class - It shows the second level namespace in the database, but it may be - the top level one in some of implementation (like PostgreSQL). - It has a capability to store a set of database objects (tables, - procedures and so on). - - It defines the following four permissions and inherited ones: - { search add_object remove_object associate } - Their meanings are similar to ones in db_catalog class except for - the schema to be replaced by database objects. - - Its security context can be computed with TYPE_TRANSITION between - the client as a subject and the database (or catalog, if availabel) - as a target. - - * db_sequence class - It shows the sequential number generator objects. We can also use - them as a communication channel between two domains, so it is - necessary to apply security policy. - - It inherits common database and defines the following two permissions: - { get_value set_value } - Client should have db_sequence:{get_value} when he fetch a value from - the sequence generator, and db_sequence:{set_value} when he set a - discretionary value. When he fetch a value from the sequence object, - it implicitly increments internal counter, but it is covered by the - get_value permission. - - Its security context can be computed with TYPE_TRANSITION between - the client as a subject and the schema as a target. - -Change definition of object classes ------------------------------------ - * db_database class - The db_database:{get_param set_param} is removed because these two - permissions are nonsense. - The db_database:{superuser} is newly added. It is checked when - client perform as database superuser. Stephen suggested it can - be separated to more finer grained privileges. It makes sense, - but this kind of separation which focuses on PostgreSQL makes - hard to port the concept for other database management systems. - - * db_table/db_column/db_tuple:{use} permission - The db_xxx:{use} permission is integrated into db_xxx:{select} - permission, because it can hide the risk to infer invisible - information easily with well considered WHERE clauses. - -user_sepgsql_xxxx_t types -------------------------- - * Currently, sepgsql_proc_t is assigned to the procedures created - by unprivileged and unprefixed clients, like httpd_t. - But I would like to handle it as a procedure created or relabeled - by database administrator. - Basically, we consider user defined procedures are untrusted, so - it should be checked before it becomes available for all the clients. - So, we don't allow to install them as system internal entities, and - don't allow unconfined domains to execute them directly. - - My preference is the user_sepgsql_xxxx_t is also assigned to - procedures created by unprivileged and unprfixed client. - -A schema for temporary obejcts ------------------------------- - * The sepgsql_schema_t is the default type for schema objects, and - rest of database objects within the schema is labeled with the chain - of TYPE_TRANSITION rules. - We have a characteristic scheme named as "pg_temp_*". Any database - objects within the schema are cleared after the session closed, - so its contents are always session local. We would like to assign - special types on the temporary schema and delivered database objects - withing the schema. In addition, users can create and use these - database objects independently from the sepgsql_enable_users_ddl. - -Booelean behavior: sepgsql_enable_users_ddl -------------------------------------------- - * Because the current design does not care about actions on schema - objects, we need to assign separated label (sepgsql_sysobj_t) on - system informations and apply checks as row-level controls. - But db_schema object class enables to control user's DDLs in - the schema level checks mainly, so now sepgsql_enable_user_ddl - focuses on db_schema class permissions and {create drop setattr} - for any other database objects. - The attached patch allows users to modify tuples with sepgsql_sysobj_t - but not allows columns/tables. It means user can define database - objects with proper way (like CREATE TABLE), but prevents to - manipulate system information by hand. - In addition, this boolean controls only user_sepgsql_xxxx_t. - The unprefixed types are always not allowed to modify its definition - by unprivileges users. - -db_table:{lock} for reader actions ----------------------------------- - * db_table:{lock} is also necessary for reader side actions due to the - implementation reason. - In PostgreSQL, FK constraints are implemented as trigger functions. - It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples, - and run a secondary query to check whether the action satisfies - FK constraints or not. - This query is described as: - SELECT 1 FROM t WHERE k = "$1" FOR SHARE; - - The "FOR SHARE" clause means explicit table lock and requires - db_table:{lock} permission. If we don't allow unpriv clients to - lock read-only tables, it disables to set up FK constraint which - refers read-only tables. - -Miscellaneous changes ---------------------- - * The security context of a new database is decided via type_transition - on the server process's context. It enables to avoid conflicts when - we have multiple DBMSs in a system. - * It allows postgresql_t domain to write out messages to system audit. - * sepgsql_proc_t is aliased to sepgsql_proc_exec_t. - * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t, - because we don't need to run trusted procedure implicitly. - * Most of postgresql_role() are shared with postgresql_unpriv_client(), - except for "role $1 types sepgsql_trusted_proc_t;" - * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3) - -Thanks, - </pre> -</blockquote> -</body> -</html> diff --git a/a/2.hdr b/a/2.hdr deleted file mode 100644 index 4d5ce0e..0000000 --- a/a/2.hdr +++ /dev/null @@ -1,2 +0,0 @@ -Content-Type: text/html; charset=ISO-2022-JP -Content-Transfer-Encoding: 7bit diff --git a/a/content_digest b/N1/content_digest index 5e751dd..2c9916c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,13 +1,9 @@ "ref\049D1DA85.1030902@ak.jp.nec.com\0" - "From\0Andy Warner <warner@rubix.com>\0" - "Subject\0Re: [RFC] Security policy reworks for SE-PostgreSQL\0" + "From\0warner@rubix.com (Andy Warner)\0" + "Subject\0[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL\0" "Date\0Tue, 31 Mar 2009 12:05:27 +0200\0" - "To\0KaiGai Kohei <kaigai@ak.jp.nec.com>\0" - "Cc\0cpebenito@tresys.com" - method@manicmethod.com - selinux@tycho.nsa.gov - " refpolicy@oss.tresys.com\0" - "\01:1\0" + "To\0refpolicy@oss.tresys.com\0" + "\00:1\0" "b\0" "looks good to me.\n" "\n" @@ -189,201 +185,9 @@ "> * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)\n" ">\n" "> Thanks,\n" - > - "\01:2\0" - "b\0" - "<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\n" - "<html>\n" - "<head>\n" - " <meta content=\"text/html;charset=ISO-2022-JP\"\n" - " http-equiv=\"Content-Type\">\n" - "</head>\n" - "<body bgcolor=\"#ffffff\" text=\"#000000\">\n" - "<font face=\"Arial\">looks good to me. <br>\n" - "<br>\n" - "One minor comment. For the superuser permission, this may be common use\n" - "of DBMS's but I believe is not a standard SQL feature. RUBIX has no\n" - "such concept, so we would generally ignore that permission. Also, it is\n" - "unclear to me what abilities the superuser should have (in the general\n" - "sense, not necessarily within sepostgresql). Is this just a permission\n" - "to override SQL DAC, or does it also give administrative abilities like\n" - "setting audit configurations, or \"all the above.\" I think you said\n" - "before that it would not allow MAC override, correct? <br>\n" - "<br>\n" - "RUBIX currently has four privileged \"roles\":<br>\n" - "Database Administrator: DAC override <br>\n" - "Security Administrator: MAC override, to some degree. With SELinux much\n" - "of this can be done with discrete rules.<br>\n" - "Audit Administrator: administer audit trail and criteria<br>\n" - "Database Operator: do the normal day-today administrative DBMS tasks,\n" - "like backup.<br>\n" - "<br>\n" - "I am curious, if the intended use of the db_database superuser\n" - "permission would be an encapsulation of our all of our roles, excluding\n" - "the Security Administrator. <br>\n" - "<br>\n" - "As a side note, without knowing too much about the intent of the\n" - "superuser permission, I would think the categories of \"roles\" RUBIX\n" - "uses would be general enough for just about any database. Thus,\n" - "providing equivalent permissions </font><font face=\"Arial\">might be\n" - "useful </font><font face=\"Arial\">(excluding the Security\n" - "Administrator, which I am guessing the community would say is not\n" - "needed because MAC override mechanisms exist within SELinux already) .<br>\n" - "</font><br>\n" - "KaiGai Kohei wrote:\n" - "<blockquote cite=\"mid:49D1DA85.1030902@ak.jp.nec.com\" type=\"cite\">\n" - " <pre wrap=\"\">As we have discussed for the recent week, I have a plan to rework\n" - "some of security policy for SE-PostgreSQL.\n" - "\n" - "The attached patch adds the significan changes, as follows.\n" - "Could you give me any suggestion, approval or opposition?\n" - "\n" - "New object classes and permissions\n" - "----------------------------------\n" - " * db_catalog class\n" - " It shows the top level namespace in the database, and has a capability\n" - " to store a set of schemas. Some of implementation does not support\n" - " catalogs. In this case, we simply ignore this class and any schemas\n" - " are placed under the db_database directly.\n" - "\n" - " It defines the following four permissions and inherited ones:\n" - " { search add_object remove_object associate }\n" - "\n" - " Client should have db_catalog:{search} on the catalog when he refers\n" - " any schemas under the catalog, and he should also have\n" - " db_catalog:{add_object} and db_catalog:{remove_object} on the catalog\n" - " when he tries to add or remove a shema within the catalog.\n" - " These permissions are an analogy of dir object class.\n" - "\n" - " The db_catalog:{associate}, which I've not introduced yet but noticed\n" - " its necessity, is also checked when we create or relabel a schema\n" - " within the catalog, and the schema should have db_catalog:{associate}\n" - " on the catalog. It is an analogy of filesystem:{associate}.\n" - " It prevents a schema is labeled unexpectedly.\n" - "\n" - " * db_schema class\n" - " It shows the second level namespace in the database, but it may be\n" - " the top level one in some of implementation (like PostgreSQL).\n" - " It has a capability to store a set of database objects (tables,\n" - " procedures and so on).\n" - "\n" - " It defines the following four permissions and inherited ones:\n" - " { search add_object remove_object associate }\n" - " Their meanings are similar to ones in db_catalog class except for\n" - " the schema to be replaced by database objects.\n" - "\n" - " Its security context can be computed with TYPE_TRANSITION between\n" - " the client as a subject and the database (or catalog, if availabel)\n" - " as a target.\n" - "\n" - " * db_sequence class\n" - " It shows the sequential number generator objects. We can also use\n" - " them as a communication channel between two domains, so it is\n" - " necessary to apply security policy.\n" - "\n" - " It inherits common database and defines the following two permissions:\n" - " { get_value set_value }\n" - " Client should have db_sequence:{get_value} when he fetch a value from\n" - " the sequence generator, and db_sequence:{set_value} when he set a\n" - " discretionary value. When he fetch a value from the sequence object,\n" - " it implicitly increments internal counter, but it is covered by the\n" - " get_value permission.\n" - "\n" - " Its security context can be computed with TYPE_TRANSITION between\n" - " the client as a subject and the schema as a target.\n" - "\n" - "Change definition of object classes\n" - "-----------------------------------\n" - " * db_database class\n" - " The db_database:{get_param set_param} is removed because these two\n" - " permissions are nonsense.\n" - " The db_database:{superuser} is newly added. It is checked when\n" - " client perform as database superuser. Stephen suggested it can\n" - " be separated to more finer grained privileges. It makes sense,\n" - " but this kind of separation which focuses on PostgreSQL makes\n" - " hard to port the concept for other database management systems.\n" - "\n" - " * db_table/db_column/db_tuple:{use} permission\n" - " The db_xxx:{use} permission is integrated into db_xxx:{select}\n" - " permission, because it can hide the risk to infer invisible\n" - " information easily with well considered WHERE clauses.\n" - "\n" - "user_sepgsql_xxxx_t types\n" - "-------------------------\n" - " * Currently, sepgsql_proc_t is assigned to the procedures created\n" - " by unprivileged and unprefixed clients, like httpd_t.\n" - " But I would like to handle it as a procedure created or relabeled\n" - " by database administrator.\n" - " Basically, we consider user defined procedures are untrusted, so\n" - " it should be checked before it becomes available for all the clients.\n" - " So, we don't allow to install them as system internal entities, and\n" - " don't allow unconfined domains to execute them directly.\n" - "\n" - " My preference is the user_sepgsql_xxxx_t is also assigned to\n" - " procedures created by unprivileged and unprfixed client.\n" - "\n" - "A schema for temporary obejcts\n" - "------------------------------\n" - " * The sepgsql_schema_t is the default type for schema objects, and\n" - " rest of database objects within the schema is labeled with the chain\n" - " of TYPE_TRANSITION rules.\n" - " We have a characteristic scheme named as \"pg_temp_*\". Any database\n" - " objects within the schema are cleared after the session closed,\n" - " so its contents are always session local. We would like to assign\n" - " special types on the temporary schema and delivered database objects\n" - " withing the schema. In addition, users can create and use these\n" - " database objects independently from the sepgsql_enable_users_ddl.\n" - "\n" - "Booelean behavior: sepgsql_enable_users_ddl\n" - "-------------------------------------------\n" - " * Because the current design does not care about actions on schema\n" - " objects, we need to assign separated label (sepgsql_sysobj_t) on\n" - " system informations and apply checks as row-level controls.\n" - " But db_schema object class enables to control user's DDLs in\n" - " the schema level checks mainly, so now sepgsql_enable_user_ddl\n" - " focuses on db_schema class permissions and {create drop setattr}\n" - " for any other database objects.\n" - " The attached patch allows users to modify tuples with sepgsql_sysobj_t\n" - " but not allows columns/tables. It means user can define database\n" - " objects with proper way (like CREATE TABLE), but prevents to\n" - " manipulate system information by hand.\n" - " In addition, this boolean controls only user_sepgsql_xxxx_t.\n" - " The unprefixed types are always not allowed to modify its definition\n" - " by unprivileges users.\n" - "\n" - "db_table:{lock} for reader actions\n" - "----------------------------------\n" - " * db_table:{lock} is also necessary for reader side actions due to the\n" - " implementation reason.\n" - " In PostgreSQL, FK constraints are implemented as trigger functions.\n" - " It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,\n" - " and run a secondary query to check whether the action satisfies\n" - " FK constraints or not.\n" - " This query is described as:\n" - " SELECT 1 FROM t WHERE k = \"$1\" FOR SHARE;\n" - "\n" - " The \"FOR SHARE\" clause means explicit table lock and requires\n" - " db_table:{lock} permission. If we don't allow unpriv clients to\n" - " lock read-only tables, it disables to set up FK constraint which\n" - " refers read-only tables.\n" - "\n" - "Miscellaneous changes\n" - "---------------------\n" - " * The security context of a new database is decided via type_transition\n" - " on the server process's context. It enables to avoid conflicts when\n" - " we have multiple DBMSs in a system.\n" - " * It allows postgresql_t domain to write out messages to system audit.\n" - " * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.\n" - " * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,\n" - " because we don't need to run trusted procedure implicitly.\n" - " * Most of postgresql_role() are shared with postgresql_unpriv_client(),\n" - " except for \"role $1 types sepgsql_trusted_proc_t;\"\n" - " * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)\n" - "\n" - "Thanks,\n" - " </pre>\n" - "</blockquote>\n" - "</body>\n" - "</html>\n" + "> \n" + "-------------- next part --------------\n" + "An HTML attachment was scrubbed...\n" + URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/8207c5eb/attachment.html -47dc3263ee1a8ccd00c64c35057405b0ef946348b39a7bf6b0f94e5915ddd19b +abf8bcf8f9b82a71e800eaa0a321dc795c68d0805e8c50394331354bd530a263
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.