[RFC] Security policy reworks for SE-PostgreSQL

[RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 7216 bytes --]

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,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-rework.2.patch --]
[-- Type: text/x-patch, Size: 24841 bytes --]

Index: policy/flask/security_classes
===================================================================
--- policy/flask/security_classes	(revision 2936)
+++ policy/flask/security_classes	(working copy)
@@ -119,4 +119,9 @@
 # kernel services that need to override task security, e.g. cachefiles
 class kernel_service 
 
+# More Database stuff
+class db_catalog		# userspace
+class db_schema			# userspace
+class db_sequence		# userspace
+
 # FLASK
Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2936)
+++ policy/flask/access_vectors	(working copy)
@@ -723,14 +723,12 @@
 	access
 	install_module
 	load_module
-	get_param
-	set_param
+	superuser
 }
 
 class db_table
 inherits database
 {
-	use
 	select
 	update
 	insert
@@ -749,7 +747,6 @@
 class db_column
 inherits database
 {
-	use
 	select
 	update
 	insert
@@ -759,7 +756,6 @@
 {
 	relabelfrom
 	relabelto
-	use
 	select
 	update
 	insert
@@ -793,3 +789,29 @@
 	use_as_override
 	create_files_as	
 }
+
+# More database stuff
+class db_catalog
+inherits database
+{
+	search
+	add_object
+	remove_object
+	associate
+}
+
+class db_schema
+inherits database
+{
+	search
+	add_object
+	remove_object
+	associate
+}
+
+class db_sequence
+inherits database
+{
+	get_value
+	set_value
+}
Index: policy/modules/kernel/kernel.if
===================================================================
--- policy/modules/kernel/kernel.if	(revision 2936)
+++ policy/modules/kernel/kernel.if	(working copy)
@@ -2563,18 +2563,22 @@
 	gen_require(`
 		type unlabeled_t;
 		class db_database { setattr relabelfrom };
+		class db_schema { setattr relabelfrom };
 		class db_table { setattr relabelfrom };
 		class db_procedure { setattr relabelfrom };
 		class db_column { setattr relabelfrom };
 		class db_tuple { update relabelfrom };
+		class db_sequence { setattr relabelfrom };
 		class db_blob { setattr relabelfrom };
 	')
 
 	allow $1 unlabeled_t:db_database { setattr relabelfrom };
+	allow $1 unlabeled_t:db_schema { setattr relabelfrom };
 	allow $1 unlabeled_t:db_table { setattr relabelfrom };
 	allow $1 unlabeled_t:db_procedure { setattr relabelfrom };
 	allow $1 unlabeled_t:db_column { setattr relabelfrom };
 	allow $1 unlabeled_t:db_tuple { update relabelfrom };
+	allow $1 unlabeled_t:db_sequence { setattr relabelfrom };
 	allow $1 unlabeled_t:db_blob { setattr relabelfrom };
 ')
 
Index: policy/modules/services/postgresql.if
===================================================================
--- policy/modules/services/postgresql.if	(revision 2936)
+++ policy/modules/services/postgresql.if	(working copy)
@@ -17,57 +17,12 @@
 #
 interface(`postgresql_role',`
 	gen_require(`
-		class db_database all_db_database_perms;
-		class db_table all_db_table_perms;
-		class db_procedure all_db_procedure_perms;
-		class db_column all_db_column_perms;
-		class db_tuple all_db_tuple_perms;
-		class db_blob all_db_blob_perms;
-
-		attribute sepgsql_client_type, sepgsql_database_type;
-		attribute sepgsql_sysobj_table_type;
-
-		type sepgsql_trusted_proc_exec_t, sepgsql_trusted_proc_t;
-		type user_sepgsql_blob_t, user_sepgsql_proc_exec_t;
-		type user_sepgsql_sysobj_t, user_sepgsql_table_t;
+		type sepgsql_trusted_proc_t;
 	')
 
-	########################################
-	#
-	# Declarations
-	#
-
-	typeattribute $2 sepgsql_client_type;
 	role $1 types sepgsql_trusted_proc_t;
 
-	##############################
-	#
-	# Client local policy
-	#
-
-	tunable_policy(`sepgsql_enable_users_ddl',`
-		allow $2 user_sepgsql_table_t:db_table { create drop };
-		type_transition $2 sepgsql_database_type:db_table user_sepgsql_table_t;
-
-		allow $2 user_sepgsql_table_t:db_column { create drop };
-
-		allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
-		type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
-	')
-
-	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete };
-	allow $2 user_sepgsql_table_t:db_column { getattr setattr use select update insert };
-	allow $2 user_sepgsql_table_t:db_tuple	{ use select update insert delete };
-	allow $2 user_sepgsql_sysobj_t:db_tuple	{ use select };
-
-	allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
-	type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
-
-	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
-	type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
-
-	allow $2 sepgsql_trusted_proc_t:process transition;
-	type_transition $2 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
+	postgresql_unpriv_client($2)
 ')
 
 ########################################
@@ -108,6 +63,24 @@
 
 ########################################
 ## <summary>
+##	Marks as a SE-PostgreSQL schema object type
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type marked as a schema object type.
+##	</summary>
+## </param>
+#
+interface(`postgresql_schema_object',`
+	gen_require(`
+		attribute sepgsql_schema_type;
+	')
+
+	typeattribute $1 sepgsql_schema_type;
+')
+
+########################################
+## <summary>
 ##	Marks as a SE-PostgreSQL table/column/tuple object type
 ## </summary>
 ## <param name="type">
@@ -163,6 +136,24 @@
 
 ########################################
 ## <summary>
+##	Marks as a SE-PostgreSQL sequence object type
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type marked as a sequence object type.
+##	</summary>
+## </param>
+#
+interface(`postgresql_sequence_object',`
+	gen_require(`
+		attribute sepgsql_sequence_type;
+	')
+
+	typeattribute $1 sepgsql_sequence_type;
+')
+
+########################################
+## <summary>
 ##	Marks as a SE-PostgreSQL binary large object type
 ## </summary>
 ## <param name="type">
@@ -181,6 +172,24 @@
 
 ########################################
 ## <summary>
+##	Marks as a SE-PostgreSQL object type stored within temporary schema
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type marked as a temporary database object type.
+##	</summary>
+## </param>
+#
+interface(`postgresql_temporary_object',`
+	gen_require(`
+		attribute sepgsql_temporary_type;
+	')
+
+	typeattribute $1 sepgsql_temporary_type;
+')
+
+########################################
+## <summary>
 ##	Allow the specified domain to search postgresql's database directory.
 ## </summary>
 ## <param name="domain">
@@ -313,22 +322,46 @@
 #
 interface(`postgresql_unpriv_client',`
 	gen_require(`
+		class db_database all_db_database_perms;
+		class db_schema all_db_schema_perms;
 		class db_table all_db_table_perms;
 		class db_procedure all_db_procedure_perms;
+		class db_column all_db_column_perms;
+		class db_tuple all_db_tuple_perms;
+		class db_sequence all_db_sequence_perms;
 		class db_blob all_db_blob_perms;
 
-		attribute sepgsql_client_type;
+		attribute sepgsql_client_type, sepgsql_database_type;
 
-		type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_t, sepgsql_blob_t;
+		type sepgsql_schema_t, sepgsql_temp_schema_t;
+		type user_sepgsql_table_t, user_sepgsql_proc_exec_t;
+		type user_sepgsql_sequence_t, user_sepgsql_blob_t;
+		type sepgsql_temp_table_t, sepgsql_temp_proc_exec_t, sepgsql_temp_sequence_t;
 		type sepgsql_trusted_proc_t, sepgsql_trusted_proc_exec_t;
 	')
 
+	########################################
+	#
+	# Declarations
+	#
+
 	typeattribute $1 sepgsql_client_type;
 
-	type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
-	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_t;
-	type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
+	##############################
+	#
+	# Type transitions
+	#
+	type_transition $1 sepgsql_schema_t:db_table user_sepgsql_table_t;
+	type_transition $1 sepgsql_schema_t:db_procedure user_sepgsql_proc_exec_t;
+	type_transition $1 sepgsql_schema_t:db_sequence user_sepgsql_sequence_t;
 
+	type_transition $1 sepgsql_temp_schema_t:db_table sepgsql_temp_table_t;
+	type_transition $1 sepgsql_temp_schema_t:db_procedure sepgsql_temp_proc_exec_t;
+	type_transition $1 sepgsql_temp_schema_t:db_sequence sepgsql_temp_sequence_t;
+
+	type_transition $1 sepgsql_database_type:db_blob user_sepgsql_blob_t;
+
+	# Trusted procedure invocation
 	type_transition $1 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
 	allow $1 sepgsql_trusted_proc_t:process transition;
 ')
@@ -346,8 +379,31 @@
 #
 interface(`postgresql_unconfined',`
 	gen_require(`
+		class db_database {superuser};
+
 		attribute sepgsql_unconfined_type;
 	')
 
 	typeattribute $1 sepgsql_unconfined_type;
+
+	allow $1 $1 : db_database {superuser};
 ')
+
+########################################
+## <summary>
+##	Allow the specified domain unconfined accesses to any database objects
+##	managed by SE-PostgreSQL, without db_database:{superuser} privilege.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`postgresql_unconfined_without_superuser',`
+	gen_require(`
+		attribute sepgsql_unconfined_type;
+	')
+
+	typeattribute $1 sepgsql_unconfined_type;
+')
Index: policy/modules/services/postgresql.te
===================================================================
--- policy/modules/services/postgresql.te	(revision 2936)
+++ policy/modules/services/postgresql.te	(working copy)
@@ -1,12 +1,14 @@
 
-policy_module(postgresql, 1.8.3)
+policy_module(postgresql, 1.9.1)
 
 gen_require(`
 	class db_database all_db_database_perms;
+	class db_schema all_db_schema_perms;
 	class db_table all_db_table_perms;
 	class db_procedure all_db_procedure_perms;
 	class db_column all_db_column_perms;
 	class db_tuple all_db_tuple_perms;
+	class db_sequence all_db_sequence_perms;
 	class db_blob all_db_blob_perms;
 ')
 
@@ -50,10 +52,13 @@
 
 # database objects attribute
 attribute sepgsql_database_type;
+attribute sepgsql_schema_type;
 attribute sepgsql_table_type;
 attribute sepgsql_sysobj_table_type;
 attribute sepgsql_procedure_type;
 attribute sepgsql_blob_type;
+attribute sepgsql_sequence_type;
+attribute sepgsql_temporary_type;
 attribute sepgsql_module_type;
 
 # database object types
@@ -66,8 +71,9 @@
 type sepgsql_fixed_table_t;
 postgresql_table_object(sepgsql_fixed_table_t)
 
-type sepgsql_proc_t;
-postgresql_procedure_object(sepgsql_proc_t)
+type sepgsql_proc_exec_t;
+typealias sepgsql_proc_exec_t alias { sepgsql_proc_t };
+postgresql_procedure_object(sepgsql_proc_exec_t)
 
 type sepgsql_ro_blob_t;
 postgresql_blob_object(sepgsql_ro_blob_t)
@@ -75,25 +81,46 @@
 type sepgsql_ro_table_t;
 postgresql_table_object(sepgsql_ro_table_t)
 
+type sepgsql_schema_t;
+postgresql_schema_object(sepgsql_schema_t)
+
 type sepgsql_secret_blob_t;
 postgresql_blob_object(sepgsql_secret_blob_t)
 
 type sepgsql_secret_table_t;
 postgresql_table_object(sepgsql_secret_table_t)
 
+type sepgsql_sequence_t;
+postgresql_sequence_object(sepgsql_sequence_t)
+
 type sepgsql_sysobj_t;
 postgresql_system_table_object(sepgsql_sysobj_t)
 
 type sepgsql_table_t;
 postgresql_table_object(sepgsql_table_t)
 
+type sepgsql_temp_proc_exec_t;
+postgresql_procedure_object(sepgsql_temp_proc_exec_t)
+postgresql_temporary_object(sepgsql_temp_proc_exec_t)
+
+type sepgsql_temp_schema_t;
+postgresql_schema_object(sepgsql_temp_schema_t)
+
+type sepgsql_temp_sequence_t;
+postgresql_sequence_object(sepgsql_temp_sequence_t)
+postgresql_temporary_object(sepgsql_temp_sequence_t)
+
+type sepgsql_temp_table_t;
+postgresql_table_object(sepgsql_temp_table_t)
+postgresql_temporary_object(sepgsql_temp_table_t)
+
 type sepgsql_trusted_proc_exec_t;
 postgresql_procedure_object(sepgsql_trusted_proc_exec_t)
 
 # Trusted Procedure Domain
 type sepgsql_trusted_proc_t;
 domain_type(sepgsql_trusted_proc_t)
-postgresql_unconfined(sepgsql_trusted_proc_t)
+postgresql_unconfined_without_superuser(sepgsql_trusted_proc_t)
 role system_r types sepgsql_trusted_proc_t;
 
 type user_sepgsql_blob_t;
@@ -106,6 +133,10 @@
 typealias user_sepgsql_proc_exec_t alias { auditadm_sepgsql_proc_exec_t secadm_sepgsql_proc_exec_t };
 postgresql_procedure_object(user_sepgsql_proc_exec_t)
 
+type user_sepgsql_sequence_t;
+typealias user_sepgsql_sequence_t alias { staff_sepgsql_sequence_t sysadm_sepgsql_sequence_t };
+typealias user_sepgsql_sequence_t alias { auditadm_sepgsql_sequence_t secadm_sepgsql_sequence_t };
+
 type user_sepgsql_sysobj_t;
 typealias user_sepgsql_sysobj_t alias { staff_sepgsql_sysobj_t sysadm_sepgsql_sysobj_t };
 typealias user_sepgsql_sysobj_t alias { auditadm_sepgsql_sysobj_t secadm_sepgsql_sysobj_t };
@@ -116,11 +147,17 @@
 typealias user_sepgsql_table_t alias { auditadm_sepgsql_table_t secadm_sepgsql_table_t };
 postgresql_table_object(user_sepgsql_table_t)
 
+# Relationship between schema and database objects
+allow { sepgsql_table_type     - sepgsql_temporary_type } sepgsql_schema_t : db_schema { associate };
+allow { sepgsql_procedure_type - sepgsql_temporary_type } sepgsql_schema_t : db_schema { associate };
+allow { sepgsql_sequence_type  - sepgsql_temporary_type } sepgsql_schema_t : db_schema { associate };
+allow { sepgsql_temporary_type } sepgsql_temp_schema_t : db_schema { associate };
+
 ########################################
 #
 # postgresql Local policy
 #
-allow postgresql_t self:capability { kill dac_override dac_read_search chown fowner fsetid setuid setgid sys_nice sys_tty_config sys_admin };
+allow postgresql_t self:capability { kill dac_override dac_read_search chown fowner fsetid setuid setgid sys_nice sys_tty_config sys_admin audit_write };
 dontaudit postgresql_t self:capability { sys_tty_config sys_admin };
 allow postgresql_t self:process signal_perms;
 allow postgresql_t self:fifo_file rw_fifo_file_perms;
@@ -130,6 +167,7 @@
 allow postgresql_t self:udp_socket create_stream_socket_perms;
 allow postgresql_t self:unix_dgram_socket create_socket_perms;
 allow postgresql_t self:unix_stream_socket create_stream_socket_perms;
+allow postgresql_t self:netlink_audit_socket create_socket_perms;
 allow postgresql_t self:netlink_selinux_socket create_socket_perms;
 
 allow postgresql_t sepgsql_database_type:db_database *;
@@ -139,11 +177,14 @@
 # Database/Loadable module
 allow sepgsql_database_type sepgsql_module_type:db_database load_module;
 
+allow postgresql_t sepgsql_schema_type:db_schema *;
+type_transition postgresql_t sepgsql_schema_type:db_schema sepgsql_schema_t;
+
 allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
-type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t;
+type_transition postgresql_t sepgsql_schema_type:db_table sepgsql_sysobj_t;
 
 allow postgresql_t sepgsql_procedure_type:db_procedure *;
-type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition postgresql_t sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
 
 allow postgresql_t sepgsql_blob_type:db_blob *;
 type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
@@ -281,35 +322,56 @@
 # Rules common to all clients
 #
 
-allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
-type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
+allow sepgsql_client_type sepgsql_db_t:db_database { getattr access };
+type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;
 
-allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert };
-allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr use select insert };
-allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { use select insert };
+allow sepgsql_client_type sepgsql_schema_t:db_schema { search };
+allow sepgsql_client_type sepgsql_temp_schema_t:db_schema { search add_object remove_object };
 
-allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete };
-allow sepgsql_client_type sepgsql_table_t:db_column { getattr use select update insert };
-allow sepgsql_client_type sepgsql_table_t:db_tuple { use select update insert delete };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr select insert lock };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { select insert };
 
-allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select };
-allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr use select };
-allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { use select };
+allow sepgsql_client_type sepgsql_table_t:db_table { getattr select update insert delete lock };
+allow sepgsql_client_type sepgsql_table_t:db_column { getattr select update insert };
+allow sepgsql_client_type sepgsql_table_t:db_tuple { select update insert delete };
 
+allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr select lock };
+allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { select };
+
 allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
 allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
 
-allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select };
-allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr use select };
-allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr select lock };
+allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { select update insert delete };
 
 allow sepgsql_client_type sepgsql_proc_t:db_procedure { getattr execute install };
 allow sepgsql_client_type sepgsql_trusted_proc_t:db_procedure { getattr execute entrypoint };
 
+allow sepgsql_client_type sepgsql_sequence_t:db_sequence { getattr get_value };
+
 allow sepgsql_client_type sepgsql_blob_t:db_blob { create drop getattr setattr read write };
 allow sepgsql_client_type sepgsql_ro_blob_t:db_blob { getattr read };
 allow sepgsql_client_type sepgsql_secret_blob_t:db_blob getattr;
 
+allow sepgsql_client_type sepgsql_temp_table_t:db_table { create drop getattr setattr select update insert delete lock };
+allow sepgsql_client_type sepgsql_temp_table_t:db_column { create drop getattr setattr select update insert };
+allow sepgsql_client_type sepgsql_temp_table_t:db_tuple { select update insert delete };
+
+allow sepgsql_client_type sepgsql_temp_proc_exec_t:db_procedure { create drop getattr setattr execute };
+
+allow sepgsql_client_type sepgsql_temp_sequence_t:db_sequence { create drop getattr setattr get_value set_value };
+
+allow sepgsql_client_type user_sepgsql_table_t:db_table { getattr select update insert delete lock };
+allow sepgsql_client_type user_sepgsql_table_t:db_column { getattr select update insert };
+allow sepgsql_client_type user_sepgsql_table_t:db_tuple { select update insert delete };
+
+allow sepgsql_client_type user_sepgsql_proc_exec_t:db_procedure { getattr execute };
+
+allow sepgsql_client_type user_sepgsql_sequence_t:db_sequence { getattr get_value set_value };
+
 # The purpose of the dontaudit rule in row-level access control is to prevent a flood of logs.
 # If a client tries to SELECT a table including violated tuples, these are filtered from
 # the result set as if not exist, but its access denied longs can be recorded within log files.
@@ -321,12 +383,14 @@
 # to access classified tuples and can make a audit record.
 #
 # Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.
-dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { use select update insert delete };
+dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { select update insert delete };
 
 tunable_policy(`sepgsql_enable_users_ddl',`
-	allow sepgsql_client_type sepgsql_table_t:db_table { create drop setattr };
-	allow sepgsql_client_type sepgsql_table_t:db_column { create drop setattr };
-	allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update insert delete };
+	allow sepgsql_client_type sepgsql_schema_t:db_schema { add_object remove_object };
+	allow sepgsql_client_type user_sepgsql_table_t:db_table { create drop setattr };
+	allow sepgsql_client_type user_sepgsql_table_t:db_column { create drop setattr };
+	allow sepgsql_client_type user_sepgsql_proc_exec_t:db_procedure { create drop setattr };
+	allow sepgsql_client_type user_sepgsql_sequence_t:db_sequence { create drop setattr };
 ')
 
 ########################################
@@ -334,20 +398,33 @@
 # Unconfined access to this module
 #
 
-allow sepgsql_unconfined_type sepgsql_database_type:db_database *;
-type_transition sepgsql_unconfined_type sepgsql_unconfined_type:db_database sepgsql_db_t;
+allow sepgsql_unconfined_type sepgsql_database_type:db_database ~{superuser};
+type_transition sepgsql_unconfined_type postgresql_t:db_database sepgsql_db_t;
 
-type_transition sepgsql_unconfined_type sepgsql_database_type:db_table sepgsql_table_t;
-type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_t;
+allow sepgsql_unconfined_type sepgsql_schema_type:db_schema *;
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_schema_t;
+
+type_transition sepgsql_unconfined_type sepgsql_schema_t:db_table sepgsql_table_t;
+type_transition sepgsql_unconfined_type sepgsql_schema_t:db_procedure sepgsql_proc_exec_t;
+type_transition sepgsql_unconfined_type sepgsql_schema_t:db_sequence sepgsql_sequence_t;
+
+type_transition sepgsql_unconfined_type sepgsql_temp_schema_t:db_table sepgsql_temp_table_t;
+type_transition sepgsql_unconfined_type sepgsql_temp_schema_t:db_procedure sepgsql_temp_proc_exec_t;
+type_transition sepgsql_unconfined_type sepgsql_temp_schema_t:db_sequence sepgsql_temp_sequence_t;
+
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_blob sepgsql_blob_t;
 
 allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;
 
 # unconfined domain is not allowed to invoke user defined procedure directly.
 # They have to confirm and relabel it at first.
-allow sepgsql_unconfined_type { sepgsql_proc_t sepgsql_trusted_proc_t }:db_procedure *;
-allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto };
+# In addition, trusted procedure is not allowed to install.
+allow sepgsql_unconfined_type sepgsql_proc_t:db_procedure *;
+allow sepgsql_unconfined_type sepgsql_trusted_proc_t:db_procedure ~{ install };
+allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure ~{ execute install };
 
+allow sepgsql_unconfined_type sepgsql_sequence_type:db_sequence *;
+
 allow sepgsql_unconfined_type sepgsql_blob_type:db_blob *;
 
 allow sepgsql_unconfined_type sepgsql_module_type:db_database install_module;
Index: config/appconfig-mls/db_contexts
===================================================================
--- config/appconfig-mls/db_contexts	(revision 0)
+++ config/appconfig-mls/db_contexts	(revision 0)
@@ -0,0 +1,16 @@
+#
+# Config file for SE-PostgreSQL extension
+#
+
+#
+# db_database object
+# ------------------
+database	*		system_u:object_r:sepgsql_db_t:s0
+
+#
+# db_schema object
+# ----------------
+schema		pg_temp_*	system_u:object_r:sepgsql_temp_schema_t:s0
+
+# NOTE: all the database objects stored in pg_temp_* namespace is
+#       released at end of the session.
Index: config/appconfig-standard/db_contexts
===================================================================
--- config/appconfig-standard/db_contexts	(revision 0)
+++ config/appconfig-standard/db_contexts	(revision 0)
@@ -0,0 +1,16 @@
+#
+# Config file for SE-PostgreSQL extension
+#
+
+#
+# db_database object
+# ------------------
+database	*		system_u:object_r:sepgsql_db_t
+
+#
+# db_schema object
+# ----------------
+schema		pg_temp_*	system_u:object_r:sepgsql_temp_schema_t
+
+# NOTE: all the database objects stored in pg_temp_* namespace is
+#       released at end of the session.
Index: config/appconfig-mcs/db_contexts
===================================================================
--- config/appconfig-mcs/db_contexts	(revision 0)
+++ config/appconfig-mcs/db_contexts	(revision 0)
@@ -0,0 +1,16 @@
+#
+# Config file for SE-PostgreSQL extension
+#
+
+#
+# db_database object
+# ------------------
+database	*		system_u:object_r:sepgsql_db_t:s0
+
+#
+# db_schema object
+# ----------------
+schema		pg_temp_*	system_u:object_r:sepgsql_temp_schema_t:s0
+
+# NOTE: all the database objects stored in pg_temp_* namespace is
+#       released at end of the session.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

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,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-rework.2.patch
Type: text/x-patch
Size: 24841 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/9d0579be/attachment-0001.bin 

Re: [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

[-- Attachment #1: Type: text/plain, Size: 8914 bytes --]

looks good to me.

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?

RUBIX currently has four privileged "roles":
Database Administrator: DAC override
Security Administrator: MAC override, to some degree. With SELinux much
of this can be done with discrete rules.
Audit Administrator: administer audit trail and criteria
Database Operator: do the normal day-today administrative DBMS tasks,
like backup.

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.

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 might be useful (excluding the Security
Administrator, which I am guessing the community would say is not needed
because MAC override mechanisms exist within SELinux already) .

KaiGai Kohei wrote:
> 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,
>   

[-- Attachment #2: Type: text/html, Size: 9093 bytes --]

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

looks good to me.

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?

RUBIX currently has four privileged "roles":
Database Administrator: DAC override
Security Administrator: MAC override, to some degree. With SELinux much
of this can be done with discrete rules.
Audit Administrator: administer audit trail and criteria
Database Operator: do the normal day-today administrative DBMS tasks,
like backup.

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.

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 might be useful (excluding the Security
Administrator, which I am guessing the community would say is not needed
because MAC override mechanisms exist within SELinux already) .

KaiGai Kohei wrote:
> 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,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/8207c5eb/attachment.html 

Re: [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Andy Warner wrote:
> looks good to me.
> 
> 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).

It is a request from the pgsql-hackers.

In addition, the permission is well symmetrical with root capability
on operating system.
In PostgreSQL, database users with superuser privilege are allowed
various kind of operating, such as ignoring DAC policy, ignoring
ownership of database objects, installing shared libraries and so on.
The db_database:{superuser} enables to control these capabilities.

> 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?

SELinux does not allow anyone to override MAC.
The unconfined domain is allowed anything in the result of access controls.

> RUBIX currently has four privileged "roles":
> Database Administrator: DAC override
> Security Administrator: MAC override, to some degree. With SELinux much 
> of this can be done with discrete rules.
> Audit Administrator: administer audit trail and criteria
> Database Operator: do the normal day-today administrative DBMS tasks, 
> like backup.
> 
> 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.

My preference is to adopt common design *as far as possible*.
If you need finer-grained privileges, please propose it as a characteristic
part for Trusted RUBIX, as if we did on db_catalog class.
Anyway, I cannot believe the pgsql-hackers accepts its design changes due
to the RUBIX's design.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Andy Warner wrote:
> looks good to me.
> 
> 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).

It is a request from the pgsql-hackers.

In addition, the permission is well symmetrical with root capability
on operating system.
In PostgreSQL, database users with superuser privilege are allowed
various kind of operating, such as ignoring DAC policy, ignoring
ownership of database objects, installing shared libraries and so on.
The db_database:{superuser} enables to control these capabilities.

> 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?

SELinux does not allow anyone to override MAC.
The unconfined domain is allowed anything in the result of access controls.

> RUBIX currently has four privileged "roles":
> Database Administrator: DAC override
> Security Administrator: MAC override, to some degree. With SELinux much 
> of this can be done with discrete rules.
> Audit Administrator: administer audit trail and criteria
> Database Operator: do the normal day-today administrative DBMS tasks, 
> like backup.
> 
> 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.

My preference is to adopt common design *as far as possible*.
If you need finer-grained privileges, please propose it as a characteristic
part for Trusted RUBIX, as if we did on db_catalog class.
Anyway, I cannot believe the pgsql-hackers accepts its design changes due
to the RUBIX's design.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Re: [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]



KaiGai Kohei wrote:
> Andy Warner wrote:
>   
>> looks good to me.
>>
>> 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).
>>     
>
> It is a request from the pgsql-hackers.
>
> In addition, the permission is well symmetrical with root capability
> on operating system.
> In PostgreSQL, database users with superuser privilege are allowed
> various kind of operating, such as ignoring DAC policy, ignoring
> ownership of database objects, installing shared libraries and so on.
> The db_database:{superuser} enables to control these capabilities.
>
>   
Sounds like our DBA role. Basically, its just a different name. I agree
that the superuser is a common concept in OS's, but note that its use is
often discouraged. I'm note sure introducing it for databases is a great
idea. But, as I said before, we would just ignore it as primarily its
there to satisfy postgresql.
>> 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?
>>     
>
> SELinux does not allow anyone to override MAC.
> The unconfined domain is allowed anything in the result of access controls.
>   
I am referring to things like:

mlsconstrain { db_tuple } { use select }
(( l1 dom l2 ) or
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsdbread ) or
( t2 == mlstrustedobject ));

where t1 == mlsdbread seems to imply an object is trusted to read
strictly dominating objects. Unless I am missing the meaning here, I
would call this a MAC override. I realize there is no concept of a TE
override, but MLS is part of MAC, no? And, this violates B&L rules. This
is something we would control with a Security Administrator "role". Or,
is this mlsdbread something that is impossible to give to a domain in a
DBMS policy?
>   
>> RUBIX currently has four privileged "roles":
>> Database Administrator: DAC override
>> Security Administrator: MAC override, to some degree. With SELinux much 
>> of this can be done with discrete rules.
>> Audit Administrator: administer audit trail and criteria
>> Database Operator: do the normal day-today administrative DBMS tasks, 
>> like backup.
>>
>> 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.
>>     
>
> My preference is to adopt common design *as far as possible*.
> If you need finer-grained privileges, please propose it as a characteristic
> part for Trusted RUBIX, as if we did on db_catalog class.
> Anyway, I cannot believe the pgsql-hackers accepts its design changes due
> to the RUBIX's design.
>   
> Thanks,
>   

[-- Attachment #2: Type: text/html, Size: 3981 bytes --]

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

KaiGai Kohei wrote:
> Andy Warner wrote:
>   
>> looks good to me.
>>
>> 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).
>>     
>
> It is a request from the pgsql-hackers.
>
> In addition, the permission is well symmetrical with root capability
> on operating system.
> In PostgreSQL, database users with superuser privilege are allowed
> various kind of operating, such as ignoring DAC policy, ignoring
> ownership of database objects, installing shared libraries and so on.
> The db_database:{superuser} enables to control these capabilities.
>
>   
Sounds like our DBA role. Basically, its just a different name. I agree
that the superuser is a common concept in OS's, but note that its use is
often discouraged. I'm note sure introducing it for databases is a great
idea. But, as I said before, we would just ignore it as primarily its
there to satisfy postgresql.
>> 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?
>>     
>
> SELinux does not allow anyone to override MAC.
> The unconfined domain is allowed anything in the result of access controls.
>   
I am referring to things like:

mlsconstrain { db_tuple } { use select }
(( l1 dom l2 ) or
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsdbread ) or
( t2 == mlstrustedobject ));

where t1 == mlsdbread seems to imply an object is trusted to read
strictly dominating objects. Unless I am missing the meaning here, I
would call this a MAC override. I realize there is no concept of a TE
override, but MLS is part of MAC, no? And, this violates B&L rules. This
is something we would control with a Security Administrator "role". Or,
is this mlsdbread something that is impossible to give to a domain in a
DBMS policy?
>   
>> RUBIX currently has four privileged "roles":
>> Database Administrator: DAC override
>> Security Administrator: MAC override, to some degree. With SELinux much 
>> of this can be done with discrete rules.
>> Audit Administrator: administer audit trail and criteria
>> Database Operator: do the normal day-today administrative DBMS tasks, 
>> like backup.
>>
>> 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.
>>     
>
> My preference is to adopt common design *as far as possible*.
> If you need finer-grained privileges, please propose it as a characteristic
> part for Trusted RUBIX, as if we did on db_catalog class.
> Anyway, I cannot believe the pgsql-hackers accepts its design changes due
> to the RUBIX's design.
>   
> Thanks,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/25855cfc/attachment.html 

Re: [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

> I am referring to things like:
> 
> mlsconstrain { db_tuple } { use select }
>     (( l1 dom l2 ) or
>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>      ( t1 == mlsdbread ) or
>      ( t2 == mlstrustedobject ));

I noticed the db_xxx:{use} permission remained here. :-)

> where t1 == mlsdbread seems to imply an object is trusted to read 
> strictly dominating objects. Unless I am missing the meaning here, I 
> would call this a MAC override. I realize there is no concept of a TE 
> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
> is something we would control with a Security Administrator "role". Or, 
> is this mlsdbread something that is impossible to give to a domain in a 
> DBMS policy?

It is different from my usage of terms.
Some of domains are allowed to access the tuple, and others are
disallowed as the result of access controls using the security
policy.

I understood the term of "MAC override" to express what actions
are allowed without any checks based on security policy, as if
root stuff can ignore DAC checks.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

> I am referring to things like:
> 
> mlsconstrain { db_tuple } { use select }
>     (( l1 dom l2 ) or
>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>      ( t1 == mlsdbread ) or
>      ( t2 == mlstrustedobject ));

I noticed the db_xxx:{use} permission remained here. :-)

> where t1 == mlsdbread seems to imply an object is trusted to read 
> strictly dominating objects. Unless I am missing the meaning here, I 
> would call this a MAC override. I realize there is no concept of a TE 
> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
> is something we would control with a Security Administrator "role". Or, 
> is this mlsdbread something that is impossible to give to a domain in a 
> DBMS policy?

It is different from my usage of terms.
Some of domains are allowed to access the tuple, and others are
disallowed as the result of access controls using the security
policy.

I understood the term of "MAC override" to express what actions
are allowed without any checks based on security policy, as if
root stuff can ignore DAC checks.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Re: [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]



KaiGai Kohei wrote:
>> I am referring to things like:
>>
>> mlsconstrain { db_tuple } { use select }
>>     (( l1 dom l2 ) or
>>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>>      ( t1 == mlsdbread ) or
>>      ( t2 == mlstrustedobject ));
>>     
>
> I noticed the db_xxx:{use} permission remained here. :-)
>   
The example I used above is from an older version of the reference policy.
>   
>> where t1 == mlsdbread seems to imply an object is trusted to read 
>> strictly dominating objects. Unless I am missing the meaning here, I 
>> would call this a MAC override. I realize there is no concept of a TE 
>> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
>> is something we would control with a Security Administrator "role". Or, 
>> is this mlsdbread something that is impossible to give to a domain in a 
>> DBMS policy?
>>     
>
> It is different from my usage of terms.
> Some of domains are allowed to access the tuple, and others are
> disallowed as the result of access controls using the security
> policy.
>
> I understood the term of "MAC override" to express what actions
> are allowed without any checks based on security policy, as if
> root stuff can ignore DAC checks.
>   
Ya, definitions, definitions :-) Coming from an MLS world, MAC override
meant superseding the B&L policy. In a general sense we use special
authorizations for that (our Security Admin role), while SELinux has a
built in mechanism (mlsdbread)
> Thanks,
>   

[-- Attachment #2: Type: text/html, Size: 2126 bytes --]

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

KaiGai Kohei wrote:
>> I am referring to things like:
>>
>> mlsconstrain { db_tuple } { use select }
>>     (( l1 dom l2 ) or
>>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>>      ( t1 == mlsdbread ) or
>>      ( t2 == mlstrustedobject ));
>>     
>
> I noticed the db_xxx:{use} permission remained here. :-)
>   
The example I used above is from an older version of the reference policy.
>   
>> where t1 == mlsdbread seems to imply an object is trusted to read 
>> strictly dominating objects. Unless I am missing the meaning here, I 
>> would call this a MAC override. I realize there is no concept of a TE 
>> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
>> is something we would control with a Security Administrator "role". Or, 
>> is this mlsdbread something that is impossible to give to a domain in a 
>> DBMS policy?
>>     
>
> It is different from my usage of terms.
> Some of domains are allowed to access the tuple, and others are
> disallowed as the result of access controls using the security
> policy.
>
> I understood the term of "MAC override" to express what actions
> are allowed without any checks based on security policy, as if
> root stuff can ignore DAC checks.
>   
Ya, definitions, definitions :-) Coming from an MLS world, MAC override
meant superseding the B&L policy. In a general sense we use special
authorizations for that (our Security Admin role), while SELinux has a
built in mechanism (mlsdbread)
> Thanks,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/1bdb4cb0/attachment.html 

Re: [RFC] Security policy reworks for SE-PostgreSQL

[Joshua Brindle]

Andy Warner wrote:
> 
> 
> KaiGai Kohei wrote:
>>> I am referring to things like:
>>>
>>> mlsconstrain { db_tuple } { use select }
>>>     (( l1 dom l2 ) or
>>>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>>>      ( t1 == mlsdbread ) or
>>>      ( t2 == mlstrustedobject ));
>>>     
>>
>> I noticed the db_xxx:{use} permission remained here. :-)
>>   
> The example I used above is from an older version of the reference policy.
>>   
>>> where t1 == mlsdbread seems to imply an object is trusted to read 
>>> strictly dominating objects. Unless I am missing the meaning here, I 
>>> would call this a MAC override. I realize there is no concept of a TE 
>>> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
>>> is something we would control with a Security Administrator "role". Or, 
>>> is this mlsdbread something that is impossible to give to a domain in a 
>>> DBMS policy?
>>>     
>>
>> It is different from my usage of terms.
>> Some of domains are allowed to access the tuple, and others are
>> disallowed as the result of access controls using the security
>> policy.
>>
>> I understood the term of "MAC override" to express what actions
>> are allowed without any checks based on security policy, as if
>> root stuff can ignore DAC checks.
>>   
> Ya, definitions, definitions :-) Coming from an MLS world, MAC override 
> meant superseding the B&L policy. In a general sense we use special 
> authorizations for that (our Security Admin role), while SELinux has a 
> built in mechanism (mlsdbread)

SELinux doesn't have a built in mechanism, mlsdbread is an attribute that you
give to domains that can violate this particular MLS constraint. Rather than
having a generic MAC_OVERRIDE like other MLS implementations we went with finer
grained overrides, you can see them all in kernel/mls.te.

there are also interfaces in mls.if to do the various overrides (rather than
adding the attribute yourself), for example if you wanted foo_t to be able to
read files of all levels you could call:

mls_file_read_all_levels(foo_t)

http://oss.tresys.com/docs/refpolicy/api/kernel_mls.html

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

[-- Attachment #1: Type: text/plain, Size: 3568 bytes --]



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>>> I am referring to things like:
>>>>
>>>> mlsconstrain { db_tuple } { use select }
>>>>     (( l1 dom l2 ) or
>>>>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>>>>      ( t1 == mlsdbread ) or
>>>>      ( t2 == mlstrustedobject ));
>>>>     
>>>>         
>>> I noticed the db_xxx:{use} permission remained here. :-)
>>>   
>>>       
>> The example I used above is from an older version of the reference policy.
>>     
>>>   
>>>       
>>>> where t1 == mlsdbread seems to imply an object is trusted to read 
>>>> strictly dominating objects. Unless I am missing the meaning here, I 
>>>> would call this a MAC override. I realize there is no concept of a TE 
>>>> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
>>>> is something we would control with a Security Administrator "role". Or, 
>>>> is this mlsdbread something that is impossible to give to a domain in a 
>>>> DBMS policy?
>>>>     
>>>>         
>>> It is different from my usage of terms.
>>> Some of domains are allowed to access the tuple, and others are
>>> disallowed as the result of access controls using the security
>>> policy.
>>>
>>> I understood the term of "MAC override" to express what actions
>>> are allowed without any checks based on security policy, as if
>>> root stuff can ignore DAC checks.
>>>   
>>>       
>> Ya, definitions, definitions :-) Coming from an MLS world, MAC override 
>> meant superseding the B&L policy. In a general sense we use special 
>> authorizations for that (our Security Admin role), while SELinux has a 
>> built in mechanism (mlsdbread)
>>     
>
> SELinux doesn't have a built in mechanism, 

By built in mechanism I meant exactly what you describe below. Maybe it
wasn't the best choice of words. The SELinux policy (the MLS policy)
provides a mechanism for the policy writer to assign the ability to
violate B&L information flow. Thus, it would be redundant for the
db_database object to have a permissions for something like "read-up",
etc. If I were to compare that with the Trusted Solaris type policy
mechanism, there was no such mechanism. Our DB would have to perform the
dominance check for an operation, then decide ourselves if the user had
sufficient authorizations to violate B&L. With the current SELinux MLS
policy, all of that is done with one access check. The mac override type
privilege you would see in TSol 8, etc would allow a process to perform
some operation while ignoring the mac policy. This does not help our DB
make a policy decision on a subject as they access a DBMS object.
> mlsdbread is an attribute that you
> give to domains that can violate this particular MLS constraint. Rather than
> having a generic MAC_OVERRIDE like other MLS implementations we went with finer
> grained overrides, you can see them all in kernel/mls.te.
>   
Yep, thats where i got the example above. Our past approach was to
disallow any mac override directly and let them change their session
level. We would then restrict them to read or read/write depending on
their authorizations. The selinux mechanism is better as, by its nature,
it may target specific objects, specific subjects, and specific overrides.
> there are also interfaces in mls.if to do the various overrides (rather than
> adding the attribute yourself), for example if you wanted foo_t to be able to
> read files of all levels you could call:
>
> mls_file_read_all_levels(foo_t)
>
> http://oss.tresys.com/docs/refpolicy/api/kernel_mls.html
>
>   

[-- Attachment #2: Type: text/html, Size: 4501 bytes --]

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Andy Warner]

Joshua Brindle wrote:
> Andy Warner wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>>> I am referring to things like:
>>>>
>>>> mlsconstrain { db_tuple } { use select }
>>>>     (( l1 dom l2 ) or
>>>>      (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>>>>      ( t1 == mlsdbread ) or
>>>>      ( t2 == mlstrustedobject ));
>>>>     
>>>>         
>>> I noticed the db_xxx:{use} permission remained here. :-)
>>>   
>>>       
>> The example I used above is from an older version of the reference policy.
>>     
>>>   
>>>       
>>>> where t1 == mlsdbread seems to imply an object is trusted to read 
>>>> strictly dominating objects. Unless I am missing the meaning here, I 
>>>> would call this a MAC override. I realize there is no concept of a TE 
>>>> override, but MLS is part of MAC, no? And, this violates B&L rules. This 
>>>> is something we would control with a Security Administrator "role". Or, 
>>>> is this mlsdbread something that is impossible to give to a domain in a 
>>>> DBMS policy?
>>>>     
>>>>         
>>> It is different from my usage of terms.
>>> Some of domains are allowed to access the tuple, and others are
>>> disallowed as the result of access controls using the security
>>> policy.
>>>
>>> I understood the term of "MAC override" to express what actions
>>> are allowed without any checks based on security policy, as if
>>> root stuff can ignore DAC checks.
>>>   
>>>       
>> Ya, definitions, definitions :-) Coming from an MLS world, MAC override 
>> meant superseding the B&L policy. In a general sense we use special 
>> authorizations for that (our Security Admin role), while SELinux has a 
>> built in mechanism (mlsdbread)
>>     
>
> SELinux doesn't have a built in mechanism, 

By built in mechanism I meant exactly what you describe below. Maybe it
wasn't the best choice of words. The SELinux policy (the MLS policy)
provides a mechanism for the policy writer to assign the ability to
violate B&L information flow. Thus, it would be redundant for the
db_database object to have a permissions for something like "read-up",
etc. If I were to compare that with the Trusted Solaris type policy
mechanism, there was no such mechanism. Our DB would have to perform the
dominance check for an operation, then decide ourselves if the user had
sufficient authorizations to violate B&L. With the current SELinux MLS
policy, all of that is done with one access check. The mac override type
privilege you would see in TSol 8, etc would allow a process to perform
some operation while ignoring the mac policy. This does not help our DB
make a policy decision on a subject as they access a DBMS object.
> mlsdbread is an attribute that you
> give to domains that can violate this particular MLS constraint. Rather than
> having a generic MAC_OVERRIDE like other MLS implementations we went with finer
> grained overrides, you can see them all in kernel/mls.te.
>   
Yep, thats where i got the example above. Our past approach was to
disallow any mac override directly and let them change their session
level. We would then restrict them to read or read/write depending on
their authorizations. The selinux mechanism is better as, by its nature,
it may target specific objects, specific subjects, and specific overrides.
> there are also interfaces in mls.if to do the various overrides (rather than
> adding the attribute yourself), for example if you wanted foo_t to be able to
> read files of all levels you could call:
>
> mls_file_read_all_levels(foo_t)
>
> http://oss.tresys.com/docs/refpolicy/api/kernel_mls.html
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/46c8b960/attachment.html 

Re: [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 8095 bytes --]

Chris,

The attached patch also reworks and fixes a few bugs in MLS/MCS policy
for SE-PostgreSQL. Could you check it please?

List of updates:
 * db_catalog, db_schema, db_sequence classes are newly constrained.
 * Removed permissions (db_database:{get_param set_param} and
   db_xxx:{use}) have gone away.
 * bugfix: MCS didn't constrain db_xxx:{getattr} permission.
 * bugfix: MCS didn't constrain db_procedure:{ drop getattr
           setattr relabelfrom } permission.
 * bugfix: MLS didn't constrain writer permission in db_procedure class.

Thanks,

KaiGai Kohei wrote:
> 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,
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-mls-fixes.patch --]
[-- Type: text/x-patch, Size: 7575 bytes --]

Index: policy/mcs
===================================================================
--- policy/mcs	(revision 2937)
+++ policy/mcs	(working copy)
@@ -104,29 +104,38 @@
 
 # Any database object must be dominated by the relabeling subject
 # clearance, also the objects are single-level.
-mlsconstrain { db_database db_table db_procedure db_column db_blob } { create relabelto }
+mlsconstrain { db_database db_catalog db_schema db_table db_procedure db_column db_sequence db_blob } { create relabelto }
 	(( h1 dom h2 ) and ( l2 eq h2 ));
 
 mlsconstrain { db_tuple } { insert relabelto }
 	(( h1 dom h2 ) and ( l2 eq h2 ));
 
 # Access control for any database objects based on MCS rules.
-mlsconstrain db_database { drop setattr relabelfrom access install_module load_module get_param set_param }
+mlsconstrain db_database { drop getattr setattr relabelfrom access install_module load_module }
 	( h1 dom h2 );
 
-mlsconstrain db_table { drop setattr relabelfrom select update insert delete use }
+mlsconstrain db_catalog { drop getattr setattr relabelfrom search add_object remove_object }
 	( h1 dom h2 );
 
-mlsconstrain db_column { drop setattr relabelfrom select update insert use }
+mlsconstrain db_schema { drop getattr setattr relabelfrom search add_object remove_object }
 	( h1 dom h2 );
 
-mlsconstrain db_tuple { relabelfrom select update delete use }
+mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete }
 	( h1 dom h2 );
 
-mlsconstrain db_procedure { execute install }
+mlsconstrain db_column { drop getattr setattr relabelfrom select update insert }
 	( h1 dom h2 );
 
-mlsconstrain db_blob { drop setattr relabelfrom read write }
+mlsconstrain db_tuple { relabelfrom select update delete }
 	( h1 dom h2 );
 
+mlsconstrain db_procedure { drop getattr setattr relabelfrom execute install }
+	( h1 dom h2 );
+
+mlsconstrain db_sequence { drop getattr setattr relabelfrom get_value set_value }
+	( h1 dom h2 );
+
+mlsconstrain db_blob { drop getattr setattr relabelfrom read write }
+	( h1 dom h2 );
+
 ') dnl end enable_mcs
Index: policy/mls
===================================================================
--- policy/mls	(revision 2937)
+++ policy/mls	(working copy)
@@ -693,69 +693,87 @@
 #
 
 # make sure these database classes are "single level"
-mlsconstrain { db_database db_table db_procedure db_column db_blob } { create relabelto }
+mlsconstrain { db_database db_catalog db_schema db_table db_column db_procedure db_sequence db_blob } { create relabelto }
 	( l2 eq h2 );
 mlsconstrain { db_tuple } { insert relabelto }
 	( l2 eq h2 );
 
 # new database labels must be dominated by the relabeling subjects clearance
-mlsconstrain { db_database db_table db_procedure db_column db_tuple db_blob } { relabelto }
+mlsconstrain { db_database db_catalog db_schema db_table db_column db_tuple db_procedure db_sequence db_blob } { relabelto }
 	( h1 dom h2 );
 
 # the database "read" ops (note the check is dominance of the low level)
-mlsconstrain { db_database } { getattr access get_param }
+mlsconstrain { db_database } { getattr access }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_table db_column } { getattr use select }
+mlsconstrain { db_catalog db_schema } { getattr search }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_table } { getattr select lock }
+	(( l1 dom l2 ) or
+	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsdbread ) or
+	 ( t2 == mlstrustedobject ));
+
+mlsconstrain { db_column } { getattr select }
+	(( l1 dom l2 ) or
+	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsdbread ) or
+	 ( t2 == mlstrustedobject ));
+
+mlsconstrain { db_tuple } { select }
+	(( l1 dom l2 ) or
+	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsdbread ) or
+	 ( t2 == mlstrustedobject ));
+
 mlsconstrain { db_procedure } { getattr execute install }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_blob } { getattr read }
+mlsconstrain { db_sequence } { getattr get_value }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_tuple } { use select }
+mlsconstrain { db_blob } { getattr read }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
 # the "single level" file "write" ops
-mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module set_param }
+mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete lock }
+mlsconstrain { db_catalog db_schema } { create drop setattr relabelfrom add_object remove_object }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_column } { create drop setattr relabelfrom update insert }
+mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_blob } { create drop setattr relabelfrom write import export }
+mlsconstrain { db_column } { create drop setattr relabelfrom update insert }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
@@ -769,8 +787,29 @@
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_procedure } { create drop setattr relabelfrom }
+	(( l1 eq l2 ) or
+	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
+	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
+	 ( t1 == mlsdbwrite ) or
+	 ( t2 == mlstrustedobject ));
+
+mlsconstrain { db_sequence } { create drop setattr relabelfrom set_value }
+	(( l1 eq l2 ) or
+	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
+	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
+	 ( t1 == mlsdbwrite ) or
+	 ( t2 == mlstrustedobject ));
+
+mlsconstrain { db_blob } { create drop setattr relabelfrom write import export }
+	(( l1 eq l2 ) or
+	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
+	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
+	 ( t1 == mlsdbwrite ) or
+	 ( t2 == mlstrustedobject ));
+
 # the database upgrade/downgrade rule
-mlsvalidatetrans { db_database db_table db_procedure db_column db_tuple db_blob }
+mlsvalidatetrans { db_database db_catalog db_schema db_table db_column db_tuple db_procedure db_sequence db_blob }
 	((( l1 eq l2 ) or
 	  (( t3 == mlsdbupgrade ) and ( l1 domby l2 )) or
 	  (( t3 == mlsdbdowngrade ) and ( l1 dom l2 )) or

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Chris,

The attached patch also reworks and fixes a few bugs in MLS/MCS policy
for SE-PostgreSQL. Could you check it please?

List of updates:
 * db_catalog, db_schema, db_sequence classes are newly constrained.
 * Removed permissions (db_database:{get_param set_param} and
   db_xxx:{use}) have gone away.
 * bugfix: MCS didn't constrain db_xxx:{getattr} permission.
 * bugfix: MCS didn't constrain db_procedure:{ drop getattr
           setattr relabelfrom } permission.
 * bugfix: MLS didn't constrain writer permission in db_procedure class.

Thanks,

KaiGai Kohei wrote:
> 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,
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-mls-fixes.patch
Type: text/x-patch
Size: 7575 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090401/c475e053/attachment-0001.bin 

Re: [RFC] Security policy reworks for SE-PostgreSQL

[Joshua Brindle]

Andy Warner wrote:
> 
> 
> Joshua Brindle wrote:
>>
>> SELinux doesn't have a built in mechanism, 
> 
> By built in mechanism I meant exactly what you describe below. Maybe it 
> wasn't the best choice of words. The SELinux policy (the MLS policy) 
> provides a mechanism for the policy writer to assign the ability to 
> violate B&L information flow. Thus, it would be redundant for the 
> db_database object to have  a permissions for something like "read-up", 
> etc. If I were to compare that with the Trusted Solaris type policy 
> mechanism, there was no such mechanism. Our DB would have to perform the 
> dominance check for an operation, then decide ourselves if the user had 
> sufficient authorizations to violate B&L. With the current SELinux MLS 
> policy, all of that is done with one access check. The mac override type 
> privilege you would see in TSol 8, etc would allow a process to perform 
> some operation while ignoring the mac policy. This does not help our DB 
> make a policy decision on a subject as they access a DBMS  object.

This is absolutely correct, we want to use policy to specify mls exceptions
rather than having the policy spread through several object managers, this makes
it possible to do an analysis on the policy and actually see the information
flow through all object managers.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Chris,

What is your opinion about this reworks?
If its scale is too large to commit at once, I can separate it
into several pieces.

Thanks,

KaiGai Kohei wrote:
> 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,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy@oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Chris,

What is your opinion about this reworks?
If its scale is too large to commit at once, I can separate it
into several pieces.

Thanks,

KaiGai Kohei wrote:
> 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,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Joshua Brindle]

KaiGai Kohei wrote:
> Chris,
> 
> What is your opinion about this reworks?
> If its scale is too large to commit at once, I can separate it
> into several pieces.
> 

I don't think it is a good idea to merge the object class changes at this point.
The object classes and permissions are likely to change with sepostgresql going
forward, as that community determines what they like and don't like
access-control wise.

Additionally there is another object manager (RUBIX) that is now going to be
reliant on these object classes so it would be nice for them to work out some of
their implementation just to be sure these are sufficient and finally merging
these object class changes is going to break the sepostgres that is in fedora
right now.

I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
with upstream postgresql with the policies available in Fedora (and upstream
refpolicy) but I don't think we can just start breaking things now, upstream
refpolicy shouldn't be treated as a playground.

> Thanks,
> 
> KaiGai Kohei wrote:
>> 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,
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy@oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
> KaiGai Kohei wrote:
> > Chris,
> > 
> > What is your opinion about this reworks?
> > If its scale is too large to commit at once, I can separate it
> > into several pieces.
> > 
> 
> I don't think it is a good idea to merge the object class changes at this point.
> The object classes and permissions are likely to change with sepostgresql going
> forward, as that community determines what they like and don't like
> access-control wise.
> 
> Additionally there is another object manager (RUBIX) that is now going to be
> reliant on these object classes so it would be nice for them to work out some of
> their implementation just to be sure these are sufficient and finally merging
> these object class changes is going to break the sepostgres that is in fedora
> right now.

Agreed.  I don't want to merge any object class changes until they have
settled down.  I'd prefer that the patches to the object manager be on a
path for upstream acceptance in both databases, if not already committed
to their trees, before moving forward on the object class changes in the
policy.

> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
> with upstream postgresql with the policies available in Fedora (and upstream
> refpolicy) but I don't think we can just start breaking things now, upstream
> refpolicy shouldn't be treated as a playground.

Permissions shouldn't be deleted, as it causes compatibility issues.
The permissions that are deprecated should be marked as such in
access_vectors, so that at some point in the future we can reclaim them,
if needed.


> > KaiGai Kohei wrote:
> >> 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,
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy@oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> > 
> > 
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
> KaiGai Kohei wrote:
> > Chris,
> > 
> > What is your opinion about this reworks?
> > If its scale is too large to commit at once, I can separate it
> > into several pieces.
> > 
> 
> I don't think it is a good idea to merge the object class changes at this point.
> The object classes and permissions are likely to change with sepostgresql going
> forward, as that community determines what they like and don't like
> access-control wise.
> 
> Additionally there is another object manager (RUBIX) that is now going to be
> reliant on these object classes so it would be nice for them to work out some of
> their implementation just to be sure these are sufficient and finally merging
> these object class changes is going to break the sepostgres that is in fedora
> right now.

Agreed.  I don't want to merge any object class changes until they have
settled down.  I'd prefer that the patches to the object manager be on a
path for upstream acceptance in both databases, if not already committed
to their trees, before moving forward on the object class changes in the
policy.

> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
> with upstream postgresql with the policies available in Fedora (and upstream
> refpolicy) but I don't think we can just start breaking things now, upstream
> refpolicy shouldn't be treated as a playground.

Permissions shouldn't be deleted, as it causes compatibility issues.
The permissions that are deprecated should be marked as such in
access_vectors, so that at some point in the future we can reclaim them,
if needed.


> > KaiGai Kohei wrote:
> >> 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,
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy at oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> > 
> > 
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> Chris,
>>
>> What is your opinion about this reworks?
>> If its scale is too large to commit at once, I can separate it
>> into several pieces.
>>
> 
> I don't think it is a good idea to merge the object class changes at this point.
> The object classes and permissions are likely to change with sepostgresql going
> forward, as that community determines what they like and don't like
> access-control wise.
> 
> Additionally there is another object manager (RUBIX) that is now going to be
> reliant on these object classes so it would be nice for them to work out some of
> their implementation just to be sure these are sufficient and finally merging
> these object class changes is going to break the sepostgres that is in fedora
> right now.
> 
> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
> with upstream postgresql with the policies available in Fedora (and upstream
> refpolicy) but I don't think we can just start breaking things now, upstream
> refpolicy shouldn't be treated as a playground.

It is a deadlock for me... :(

I plan SE-PostgreSQL adopts the new object classes and permissions
(and some of enhancements on libselinux) in the upcoming Fedora 11,
but I'll also continue to maintain the current design on Fedora 10
or 9 already released.

The upstream PostgreSQL is going to have the next major version up
very soon, and it does not undertake the disk format compatibility
across the major versions. It means users need to migrate their
database files for the new versions.
It is a good chance to switch to the new security design without
breaking the current database.

During the efforts to upstream SE-PostgreSQL, I don't think pgsql
hackers can modify or replace the security policy, so it needs to
continue the proposition on the current design, but it also means
we have to change the design at some future point.

I really really would like to get it merged in this timing.

Thanks,

>> Thanks,
>>
>> KaiGai Kohei wrote:
>>> 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,
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy@oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
> 
> 
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> Chris,
>>
>> What is your opinion about this reworks?
>> If its scale is too large to commit at once, I can separate it
>> into several pieces.
>>
> 
> I don't think it is a good idea to merge the object class changes at this point.
> The object classes and permissions are likely to change with sepostgresql going
> forward, as that community determines what they like and don't like
> access-control wise.
> 
> Additionally there is another object manager (RUBIX) that is now going to be
> reliant on these object classes so it would be nice for them to work out some of
> their implementation just to be sure these are sufficient and finally merging
> these object class changes is going to break the sepostgres that is in fedora
> right now.
> 
> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
> with upstream postgresql with the policies available in Fedora (and upstream
> refpolicy) but I don't think we can just start breaking things now, upstream
> refpolicy shouldn't be treated as a playground.

It is a deadlock for me... :(

I plan SE-PostgreSQL adopts the new object classes and permissions
(and some of enhancements on libselinux) in the upcoming Fedora 11,
but I'll also continue to maintain the current design on Fedora 10
or 9 already released.

The upstream PostgreSQL is going to have the next major version up
very soon, and it does not undertake the disk format compatibility
across the major versions. It means users need to migrate their
database files for the new versions.
It is a good chance to switch to the new security design without
breaking the current database.

During the efforts to upstream SE-PostgreSQL, I don't think pgsql
hackers can modify or replace the security policy, so it needs to
continue the proposition on the current design, but it also means
we have to change the design at some future point.

I really really would like to get it merged in this timing.

Thanks,

>> Thanks,
>>
>> KaiGai Kohei wrote:
>>> 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,
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
> 
> 
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
>> KaiGai Kohei wrote:
>>> Chris,
>>>
>>> What is your opinion about this reworks?
>>> If its scale is too large to commit at once, I can separate it
>>> into several pieces.
>>>
>> I don't think it is a good idea to merge the object class changes at this point.
>> The object classes and permissions are likely to change with sepostgresql going
>> forward, as that community determines what they like and don't like
>> access-control wise.
>>
>> Additionally there is another object manager (RUBIX) that is now going to be
>> reliant on these object classes so it would be nice for them to work out some of
>> their implementation just to be sure these are sufficient and finally merging
>> these object class changes is going to break the sepostgres that is in fedora
>> right now.
> 
> Agreed.  I don't want to merge any object class changes until they have
> settled down.  I'd prefer that the patches to the object manager be on a
> path for upstream acceptance in both databases, if not already committed
> to their trees, before moving forward on the object class changes in the
> policy.

As I noted in the previous message, it give me a deadlock. :(

I don't think it is a realistic assumption that pgsql-hackers are
well motivated to modify or replace the default security policy to
review and test the proposed features. I guess it gives us negative
effect to upstream the SE-PostgreSQL feature in the v8.5 release.

At least, these new object classes don't have any strange behavior.
The vanilla PostgreSQL also has similar permissions, so it convinces
me they can accept these permissions, more than nothing for them.

Again, I would like to get the reworks merged in this timing.
(In addition, it also makes RUBIX happy on Fedora 11 or later.)

>> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
>> with upstream postgresql with the policies available in Fedora (and upstream
>> refpolicy) but I don't think we can just start breaking things now, upstream
>> refpolicy shouldn't be treated as a playground.
> 
> Permissions shouldn't be deleted, as it causes compatibility issues.
> The permissions that are deprecated should be marked as such in
> access_vectors, so that at some point in the future we can reclaim them,
> if needed.

Something like ... ?

class db_table
inherits database
{
	use		# deprecated
	select
	update
	  :

Do you intend it to be handled as a hint for the script to generate
the <class>_all_perms?

Thanks,

>>> KaiGai Kohei wrote:
>>>> 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,
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy@oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
>> KaiGai Kohei wrote:
>>> Chris,
>>>
>>> What is your opinion about this reworks?
>>> If its scale is too large to commit at once, I can separate it
>>> into several pieces.
>>>
>> I don't think it is a good idea to merge the object class changes at this point.
>> The object classes and permissions are likely to change with sepostgresql going
>> forward, as that community determines what they like and don't like
>> access-control wise.
>>
>> Additionally there is another object manager (RUBIX) that is now going to be
>> reliant on these object classes so it would be nice for them to work out some of
>> their implementation just to be sure these are sufficient and finally merging
>> these object class changes is going to break the sepostgres that is in fedora
>> right now.
> 
> Agreed.  I don't want to merge any object class changes until they have
> settled down.  I'd prefer that the patches to the object manager be on a
> path for upstream acceptance in both databases, if not already committed
> to their trees, before moving forward on the object class changes in the
> policy.

As I noted in the previous message, it give me a deadlock. :(

I don't think it is a realistic assumption that pgsql-hackers are
well motivated to modify or replace the default security policy to
review and test the proposed features. I guess it gives us negative
effect to upstream the SE-PostgreSQL feature in the v8.5 release.

At least, these new object classes don't have any strange behavior.
The vanilla PostgreSQL also has similar permissions, so it convinces
me they can accept these permissions, more than nothing for them.

Again, I would like to get the reworks merged in this timing.
(In addition, it also makes RUBIX happy on Fedora 11 or later.)

>> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
>> with upstream postgresql with the policies available in Fedora (and upstream
>> refpolicy) but I don't think we can just start breaking things now, upstream
>> refpolicy shouldn't be treated as a playground.
> 
> Permissions shouldn't be deleted, as it causes compatibility issues.
> The permissions that are deprecated should be marked as such in
> access_vectors, so that at some point in the future we can reclaim them,
> if needed.

Something like ... ?

class db_table
inherits database
{
	use		# deprecated
	select
	update
	  :

Do you intend it to be handled as a hint for the script to generate
the <class>_all_perms?

Thanks,

>>> KaiGai Kohei wrote:
>>>> 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,
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Joshua Brindle]

KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
>> On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
>>> KaiGai Kohei wrote:
>>>> Chris,
>>>>
>>>> What is your opinion about this reworks?
>>>> If its scale is too large to commit at once, I can separate it
>>>> into several pieces.
>>>>
>>> I don't think it is a good idea to merge the object class changes at this point.
>>> The object classes and permissions are likely to change with sepostgresql going
>>> forward, as that community determines what they like and don't like
>>> access-control wise.
>>>
>>> Additionally there is another object manager (RUBIX) that is now going to be
>>> reliant on these object classes so it would be nice for them to work out some of
>>> their implementation just to be sure these are sufficient and finally merging
>>> these object class changes is going to break the sepostgres that is in fedora
>>> right now.
>> Agreed.  I don't want to merge any object class changes until they have
>> settled down.  I'd prefer that the patches to the object manager be on a
>> path for upstream acceptance in both databases, if not already committed
>> to their trees, before moving forward on the object class changes in the
>> policy.
> 
> As I noted in the previous message, it give me a deadlock. :(
> 
> I don't think it is a realistic assumption that pgsql-hackers are
> well motivated to modify or replace the default security policy to
> review and test the proposed features. I guess it gives us negative
> effect to upstream the SE-PostgreSQL feature in the v8.5 release.
> 

They will have to do some policy updates to test the functionality no matter
what. I don't think it is *that* unreasonable for them to update the base policy
(from their perspective it shouldn't be any different anyway)

> At least, these new object classes don't have any strange behavior.
> The vanilla PostgreSQL also has similar permissions, so it convinces
> me they can accept these permissions, more than nothing for them.
> 

Except you were removing permissions in the patch, which would break the
sepostgres that is in the Fedora tree.

> Again, I would like to get the reworks merged in this timing.
> (In addition, it also makes RUBIX happy on Fedora 11 or later.)
> 

Fedora 11 is already frozen, new object classes shouldn't be working their way
in to that, so we have a release cycle to adjust the permissions to match the
implementation, both on the upstream sepostgres side and the RUBIX side before
pushing those in to refpolicy.

Once some implementation starts and the security model settles it may be a
different story, I just don't think it is appropriate to merge them at this
point. (In particular I want to see if the new proposed object classes and perms
will really work for RUBIX, and I want to see how much of the patch the upstream
postgres project will take for the next release).

As it stands we are going to have 3 selinux aware databases floating around
using slightly different object classes and permissions, which is not ideal.
Having all those in upstream refpolicy means it is harder to change them and the
unused permissions are going to sit there causing confusion (even worse, they'll
be unused by 2 of the 3 systems but still in use by the previous version of
sepostgres).

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Joshua Brindle wrote:
>> Again, I would like to get the reworks merged in this timing.
>> (In addition, it also makes RUBIX happy on Fedora 11 or later.)
>>
> 
> Fedora 11 is already frozen, new object classes shouldn't be working their way
> in to that, so we have a release cycle to adjust the permissions to match the
> implementation, both on the upstream sepostgres side and the RUBIX side before
> pushing those in to refpolicy.

Hmm... It would seem that I need to provide a development purpose
security policy package in the meanwhile.

The next development cycle in PostgreSQL will be open soon:
  http://wiki.postgresql.org/wiki/CommitFest_2009-First

I'll propose the newer design for the commit fest, but also continue
to maintain the current design on Fedora as far as the security policy
keeps existing object classes and permissions.

I believe the current design should be switched to the newer one
at some point in the future. In my hope, it should be done on
Fedora 12.

> Once some implementation starts and the security model settles it may be a
> different story, I just don't think it is appropriate to merge them at this
> point. (In particular I want to see if the new proposed object classes and perms
> will really work for RUBIX, and I want to see how much of the patch the upstream
> postgres project will take for the next release).

I also would like Andy to report whether the RUBIX with newer design and
security policy performs well, or not.
The development purpose security policy which contains newer object classes
and permissions will be available soon.

> As it stands we are going to have 3 selinux aware databases floating around
> using slightly different object classes and permissions, which is not ideal.

Agreed.

> Having all those in upstream refpolicy means it is harder to change them and the
> unused permissions are going to sit there causing confusion (even worse, they'll
> be unused by 2 of the 3 systems but still in use by the previous version of
> sepostgres).

I think the current design should be deprecated in the lifespan of distribution
if the upstream refpolicy once gets newer design.
In finally, I believe only 2 of the system can share the design.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Joshua Brindle wrote:
>> Again, I would like to get the reworks merged in this timing.
>> (In addition, it also makes RUBIX happy on Fedora 11 or later.)
>>
> 
> Fedora 11 is already frozen, new object classes shouldn't be working their way
> in to that, so we have a release cycle to adjust the permissions to match the
> implementation, both on the upstream sepostgres side and the RUBIX side before
> pushing those in to refpolicy.

Hmm... It would seem that I need to provide a development purpose
security policy package in the meanwhile.

The next development cycle in PostgreSQL will be open soon:
  http://wiki.postgresql.org/wiki/CommitFest_2009-First

I'll propose the newer design for the commit fest, but also continue
to maintain the current design on Fedora as far as the security policy
keeps existing object classes and permissions.

I believe the current design should be switched to the newer one
at some point in the future. In my hope, it should be done on
Fedora 12.

> Once some implementation starts and the security model settles it may be a
> different story, I just don't think it is appropriate to merge them at this
> point. (In particular I want to see if the new proposed object classes and perms
> will really work for RUBIX, and I want to see how much of the patch the upstream
> postgres project will take for the next release).

I also would like Andy to report whether the RUBIX with newer design and
security policy performs well, or not.
The development purpose security policy which contains newer object classes
and permissions will be available soon.

> As it stands we are going to have 3 selinux aware databases floating around
> using slightly different object classes and permissions, which is not ideal.

Agreed.

> Having all those in upstream refpolicy means it is harder to change them and the
> unused permissions are going to sit there causing confusion (even worse, they'll
> be unused by 2 of the 3 systems but still in use by the previous version of
> sepostgres).

I think the current design should be deprecated in the lifespan of distribution
if the upstream refpolicy once gets newer design.
In finally, I believe only 2 of the system can share the design.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

The attached patch provides some of reworks and bugfuxes
except for new object classes and permissions.

- rework: Add a comment of "not currently in use" for deprecated
  permissions, but its definitions are not removed.

- bugfix: MCS policy did not constrain the following permissions.
    db_database:{getattr}
    db_table:{getattr lock}
    db_column:{getattr}
    db_procedure:{drop getattr setattr}
    db_blob:{getattr import export}

- rework: All the newly created database objects by unprivileged
  clients are prefixed with "user_", and these are controled via
  sepgsql_enable_users_ddl.
  The current policy allows httpd_t to created a function labeled
  as sepgsql_proc_t which is also allowed to be installed as a
  system internal entity (db_procedure:{install}).
  It is a potentially risk for trojan horse.

- rework: postgresql_role() shares most part of postgresql_unpriv_client().

- bugfix: some of permissions in db_procedure class are allowed
  on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
  It should allow them on sepgsql_trusted_proc_exec_t.
  I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
  such kind of confusion, as Chris suggested before.

- rework: we should not allow db_procedure:{install} on the
  sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
  procedure implicitly.

- rework: db_table:{lock} is moved to reader side, because it makes
  impossible to refer read-only table with foreign-key constraint.
  (FK checks internally acquire explicit locks.)

- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
  but it is required whrn the largeobject is refered.

- bugfix: MLS policy didn't constrain the db_procedure class.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-rework.3.patch --]
[-- Type: text/x-patch, Size: 14309 bytes --]

Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2942)
+++ policy/flask/access_vectors	(working copy)
@@ -723,14 +723,14 @@
 	access
 	install_module
 	load_module
-	get_param
-	set_param
+	get_param	# not currently in use
+	set_param	# not currently in use
 }
 
 class db_table
 inherits database
 {
-	use
+	use		# not currently in use
 	select
 	update
 	insert
@@ -749,7 +749,7 @@
 class db_column
 inherits database
 {
-	use
+	use		# not currently in use
 	select
 	update
 	insert
@@ -759,7 +759,7 @@
 {
 	relabelfrom
 	relabelto
-	use
+	use		# not currently in use
 	select
 	update
 	insert
Index: policy/mcs
===================================================================
--- policy/mcs	(revision 2942)
+++ policy/mcs	(working copy)
@@ -111,22 +111,22 @@
 	(( h1 dom h2 ) and ( l2 eq h2 ));
 
 # Access control for any database objects based on MCS rules.
-mlsconstrain db_database { drop setattr relabelfrom access install_module load_module get_param set_param }
+mlsconstrain db_database { drop getattr setattr relabelfrom access install_module load_module get_param set_param }
 	( h1 dom h2 );
 
-mlsconstrain db_table { drop setattr relabelfrom select update insert delete use }
+mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete use lock }
 	( h1 dom h2 );
 
-mlsconstrain db_column { drop setattr relabelfrom select update insert use }
+mlsconstrain db_column { drop getattr setattr relabelfrom select update insert use }
 	( h1 dom h2 );
 
 mlsconstrain db_tuple { relabelfrom select update delete use }
 	( h1 dom h2 );
 
-mlsconstrain db_procedure { execute install }
+mlsconstrain db_procedure { drop getattr setattr execute install }
 	( h1 dom h2 );
 
-mlsconstrain db_blob { drop setattr relabelfrom read write }
+mlsconstrain db_blob { drop getattr setattr relabelfrom read write import export }
 	( h1 dom h2 );
 
 ') dnl end enable_mcs
Index: policy/modules/services/postgresql.if
===================================================================
--- policy/modules/services/postgresql.if	(revision 2942)
+++ policy/modules/services/postgresql.if	(working copy)
@@ -17,57 +17,11 @@
 #
 interface(`postgresql_role',`
 	gen_require(`
-		class db_database all_db_database_perms;
-		class db_table all_db_table_perms;
-		class db_procedure all_db_procedure_perms;
-		class db_column all_db_column_perms;
-		class db_tuple all_db_tuple_perms;
-		class db_blob all_db_blob_perms;
-
-		attribute sepgsql_client_type, sepgsql_database_type;
-		attribute sepgsql_sysobj_table_type;
-
-		type sepgsql_trusted_proc_exec_t, sepgsql_trusted_proc_t;
-		type user_sepgsql_blob_t, user_sepgsql_proc_exec_t;
-		type user_sepgsql_sysobj_t, user_sepgsql_table_t;
+		type sepgsql_trusted_proc_t;
 	')
 
-	########################################
-	#
-	# Declarations
-	#
-
-	typeattribute $2 sepgsql_client_type;
+	postgresql_unpriv_client($2)
 	role $1 types sepgsql_trusted_proc_t;
-
-	##############################
-	#
-	# Client local policy
-	#
-
-	tunable_policy(`sepgsql_enable_users_ddl',`
-		allow $2 user_sepgsql_table_t:db_table { create drop };
-		type_transition $2 sepgsql_database_type:db_table user_sepgsql_table_t;
-
-		allow $2 user_sepgsql_table_t:db_column { create drop };
-
-		allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
-		type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
-	')
-
-	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete };
-	allow $2 user_sepgsql_table_t:db_column { getattr setattr use select update insert };
-	allow $2 user_sepgsql_table_t:db_tuple	{ use select update insert delete };
-	allow $2 user_sepgsql_sysobj_t:db_tuple	{ use select };
-
-	allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
-	type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
-
-	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
-	type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
-
-	allow $2 sepgsql_trusted_proc_t:process transition;
-	type_transition $2 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
 ')
 
 ########################################
@@ -313,22 +267,62 @@
 #
 interface(`postgresql_unpriv_client',`
 	gen_require(`
+		class db_database all_db_database_perms;
 		class db_table all_db_table_perms;
 		class db_procedure all_db_procedure_perms;
+		class db_column all_db_column_perms;
+		class db_tuple all_db_tuple_perms;
 		class db_blob all_db_blob_perms;
 
 		attribute sepgsql_client_type;
+		attribute sepgsql_database_type;
+		attribute sepgsql_sysobj_table_type;
 
-		type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_t, sepgsql_blob_t;
-		type sepgsql_trusted_proc_t, sepgsql_trusted_proc_exec_t;
-	')
+		type user_sepgsql_table_t;
+		type user_sepgsql_sysobj_t;
+		type user_sepgsql_proc_exec_t;
+		type user_sepgsql_blob_t;
 
+		type sepgsql_trusted_proc_t;
+		type sepgsql_trusted_proc_exec_t;
+	')
+	########################################
+	#
+	# Declarations
+	#
 	typeattribute $1 sepgsql_client_type;
 
-	type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
-	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_t;
-	type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
+	##############################
+	#
+	# Client local policy
+	#
+	type_transition $1 sepgsql_database_type:db_table user_sepgsql_table_t;
+	allow $1 user_sepgsql_table_t:db_table { getattr use select update insert delete lock };
+	allow $1 user_sepgsql_table_t:db_column { getattr use select update insert };
+	allow $1 user_sepgsql_table_t:db_tuple { use select update insert delete };
 
+	type_transition $1 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
+	allow $1 user_sepgsql_sysobj_t:db_tuple { use select };
+
+	type_transition $1 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
+	allow $1 user_sepgsql_proc_exec_t:db_procedure { getattr execute };
+
+	tunable_policy(`sepgsql_enable_users_ddl',`
+		allow $1 user_sepgsql_table_t:db_table { create drop setattr };
+		allow $1 user_sepgsql_table_t:db_column { create drop setattr };
+
+		allow $1 user_sepgsql_sysobj_t:db_tuple { insert update delete };
+
+		allow $1 user_sepgsql_proc_exec_t:db_procedure { create drop setattr };
+	')
+
+	type_transition $1 sepgsql_database_type:db_blob user_sepgsql_blob_t;
+	allow $1 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
+
+	##############################
+	#
+	# Trusted procedure
+	#
 	type_transition $1 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
 	allow $1 sepgsql_trusted_proc_t:process transition;
 ')
Index: policy/modules/services/postgresql.te
===================================================================
--- policy/modules/services/postgresql.te	(revision 2942)
+++ policy/modules/services/postgresql.te	(working copy)
@@ -66,8 +66,9 @@
 type sepgsql_fixed_table_t;
 postgresql_table_object(sepgsql_fixed_table_t)
 
-type sepgsql_proc_t;
-postgresql_procedure_object(sepgsql_proc_t)
+type sepgsql_proc_exec_t;
+typealias sepgsql_proc_exec_t alias { sepgsql_proc_t };
+postgresql_procedure_object(sepgsql_proc_exec_t)
 
 type sepgsql_ro_blob_t;
 postgresql_blob_object(sepgsql_ro_blob_t)
@@ -143,7 +144,7 @@
 type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t;
 
 allow postgresql_t sepgsql_procedure_type:db_procedure *;
-type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_exec_t;
 
 allow postgresql_t sepgsql_blob_type:db_blob *;
 type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
@@ -284,27 +285,27 @@
 allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
 type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
 
-allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert lock };
 allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr use select insert };
 allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { use select insert };
 
-allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete };
+allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete lock };
 allow sepgsql_client_type sepgsql_table_t:db_column { getattr use select update insert };
 allow sepgsql_client_type sepgsql_table_t:db_tuple { use select update insert delete };
 
-allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select lock };
 allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr use select };
 allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { use select };
 
 allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
 allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
 
-allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select lock };
 allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr use select };
 allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
 
-allow sepgsql_client_type sepgsql_proc_t:db_procedure { getattr execute install };
-allow sepgsql_client_type sepgsql_trusted_proc_t:db_procedure { getattr execute entrypoint };
+allow sepgsql_client_type sepgsql_proc_exec_t:db_procedure { getattr execute install };
+allow sepgsql_client_type sepgsql_trusted_proc_exec_t:db_procedure { getattr execute entrypoint };
 
 allow sepgsql_client_type sepgsql_blob_t:db_blob { create drop getattr setattr read write };
 allow sepgsql_client_type sepgsql_ro_blob_t:db_blob { getattr read };
@@ -323,12 +324,6 @@
 # Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.
 dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { use select update insert delete };
 
-tunable_policy(`sepgsql_enable_users_ddl',`
-	allow sepgsql_client_type sepgsql_table_t:db_table { create drop setattr };
-	allow sepgsql_client_type sepgsql_table_t:db_column { create drop setattr };
-	allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update insert delete };
-')
-
 ########################################
 #
 # Unconfined access to this module
@@ -338,15 +333,16 @@
 type_transition sepgsql_unconfined_type sepgsql_unconfined_type:db_database sepgsql_db_t;
 
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_table sepgsql_table_t;
-type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_exec_t;
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_blob sepgsql_blob_t;
 
 allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;
 
 # unconfined domain is not allowed to invoke user defined procedure directly.
 # They have to confirm and relabel it at first.
-allow sepgsql_unconfined_type { sepgsql_proc_t sepgsql_trusted_proc_t }:db_procedure *;
-allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto };
+allow sepgsql_unconfined_type sepgsql_proc_exec_t:db_procedure *;
+allow sepgsql_unconfined_type sepgsql_trusted_proc_exec_t:db_procedure ~{ install };
+allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure ~{ execute install };
 
 allow sepgsql_unconfined_type sepgsql_blob_type:db_blob *;
 
Index: policy/mls
===================================================================
--- policy/mls	(revision 2942)
+++ policy/mls	(working copy)
@@ -709,19 +709,25 @@
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_table db_column } { getattr use select }
+mlsconstrain { db_table } { getattr use select lock }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_column } { getattr use select }
+	(( l1 dom l2 ) or
+	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsdbread ) or
+	 ( t2 == mlstrustedobject ));
+
 mlsconstrain { db_procedure } { getattr execute install }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_blob } { getattr read }
+mlsconstrain { db_blob } { getattr read export }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
@@ -741,7 +747,7 @@
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete lock }
+mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
@@ -755,13 +761,20 @@
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_blob } { create drop setattr relabelfrom write import export }
+mlsconstrain { db_procedure } { create drop setattr relabelfrom }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_blob } { create drop setattr relabelfrom write import }
+	(( l1 eq l2 ) or
+	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
+	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
+	 ( t1 == mlsdbwrite ) or
+	 ( t2 == mlstrustedobject ));
+
 mlsconstrain { db_tuple } { relabelfrom update insert delete }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

The attached patch provides some of reworks and bugfuxes
except for new object classes and permissions.

- rework: Add a comment of "not currently in use" for deprecated
  permissions, but its definitions are not removed.

- bugfix: MCS policy did not constrain the following permissions.
    db_database:{getattr}
    db_table:{getattr lock}
    db_column:{getattr}
    db_procedure:{drop getattr setattr}
    db_blob:{getattr import export}

- rework: All the newly created database objects by unprivileged
  clients are prefixed with "user_", and these are controled via
  sepgsql_enable_users_ddl.
  The current policy allows httpd_t to created a function labeled
  as sepgsql_proc_t which is also allowed to be installed as a
  system internal entity (db_procedure:{install}).
  It is a potentially risk for trojan horse.

- rework: postgresql_role() shares most part of postgresql_unpriv_client().

- bugfix: some of permissions in db_procedure class are allowed
  on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
  It should allow them on sepgsql_trusted_proc_exec_t.
  I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
  such kind of confusion, as Chris suggested before.

- rework: we should not allow db_procedure:{install} on the
  sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
  procedure implicitly.

- rework: db_table:{lock} is moved to reader side, because it makes
  impossible to refer read-only table with foreign-key constraint.
  (FK checks internally acquire explicit locks.)

- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
  but it is required whrn the largeobject is refered.

- bugfix: MLS policy didn't constrain the db_procedure class.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-rework.3.patch
Type: text/x-patch
Size: 14309 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090406/e8464137/attachment.bin 

SELinux packages version (svn2950)...

[Hasan Rezaul-CHR010]

Hi All,

I work on a product that uses Linux Kernel 2.6.21.  As such, I am
currently using the following SELinux libs and related package versions:

audit            1.5.3
checkpolicy      1.33.1
libselinux       2.0.13
libsemanage      2.0.1
libsepol         2.0.3
libsetrans       0.1.18
policycoreutils  2.0.16



We are considering moving upto Linux Kernel 2.6.27, and as such we would
automatically get upgraded to the following package versions:

audit            1.7.2
checkpolicy      svn2950
libselinux       svn2950
libsemanage      svn2950
libsepol         svn2950
libsetrans       N/A
policycoreutils  svn2950


** My questions are:

1. Do all the packages of version (svn2950) play nicely together ?
2. What are the major advantages of upgrading to svn2950 ?
3. Are there any disadvantages, or any changes that I should be aware or
cencerned about ?
4. Why is the version number so drastically different ? Is this a result
of a totally new effort ?
5. Please feel free to share any thoughts / suggestions / advice as far
as upgrading to this newer version...

Thanks in advance for all your help.




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux packages version (svn2950)...

[Joshua Brindle]

Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I work on a product that uses Linux Kernel 2.6.21.  As such, I am
> currently using the following SELinux libs and related package versions:
> 
> audit            1.5.3
> checkpolicy      1.33.1
> libselinux       2.0.13
> libsemanage      2.0.1
> libsepol         2.0.3
> libsetrans       0.1.18
> policycoreutils  2.0.16
> 
> 
> 
> We are considering moving upto Linux Kernel 2.6.27, and as such we would
> automatically get upgraded to the following package versions:
> 
> audit            1.7.2
> checkpolicy      svn2950
> libselinux       svn2950
> libsemanage      svn2950
> libsepol         svn2950
> libsetrans       N/A
> policycoreutils  svn2950
> 
> 
> ** My questions are:
> 
> 1. Do all the packages of version (svn2950) play nicely together ?
> 2. What are the major advantages of upgrading to svn2950 ?
> 3. Are there any disadvantages, or any changes that I should be aware or
> cencerned about ?
> 4. Why is the version number so drastically different ? Is this a result
> of a totally new effort ?
> 5. Please feel free to share any thoughts / suggestions / advice as far
> as upgrading to this newer version...
> 
> Thanks in advance for all your help.
> 

There is no subversion repository anymore, all the subversion repos should be 
down at this point, where did you find that revision?

The packages are now in git at http://userspace.selinuxproject.org/ and a 
release was just made at http://userspace.selinuxproject.org/trac/wiki/Releases .

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: SELinux packages version (svn2950)...

[Hasan Rezaul-CHR010]

We get our Linux OS and filesystem packaged from a third-party company.
These are the versions of the SELinux packages included in the bundle.
The version number looked a bit strange to me, so I wanted to check with
the selinux community...

So are you saying this  "svn2950" version doesn't officially exist
anymore, and its *NOT* a stable and tested version ?

Thanks,

- Rezaul.


-----Original Message-----
From: Joshua Brindle [mailto:method@manicmethod.com] 
Sent: Monday, April 06, 2009 2:19 PM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; selinux@tycho.nsa.gov
Subject: Re: SELinux packages version (svn2950)...

Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I work on a product that uses Linux Kernel 2.6.21.  As such, I am 
> currently using the following SELinux libs and related package
versions:
> 
> audit            1.5.3
> checkpolicy      1.33.1
> libselinux       2.0.13
> libsemanage      2.0.1
> libsepol         2.0.3
> libsetrans       0.1.18
> policycoreutils  2.0.16
> 
> 
> 
> We are considering moving upto Linux Kernel 2.6.27, and as such we 
> would automatically get upgraded to the following package versions:
> 
> audit            1.7.2
> checkpolicy      svn2950
> libselinux       svn2950
> libsemanage      svn2950
> libsepol         svn2950
> libsetrans       N/A
> policycoreutils  svn2950
> 
> 
> ** My questions are:
> 
> 1. Do all the packages of version (svn2950) play nicely together ?
> 2. What are the major advantages of upgrading to svn2950 ?
> 3. Are there any disadvantages, or any changes that I should be aware 
> or cencerned about ?
> 4. Why is the version number so drastically different ? Is this a 
> result of a totally new effort ?
> 5. Please feel free to share any thoughts / suggestions / advice as 
> far as upgrading to this newer version...
> 
> Thanks in advance for all your help.
> 

There is no subversion repository anymore, all the subversion repos
should be down at this point, where did you find that revision?

The packages are now in git at http://userspace.selinuxproject.org/ and
a release was just made at
http://userspace.selinuxproject.org/trac/wiki/Releases .


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux packages version (svn2950)...

[Joshua Brindle]

Hasan Rezaul-CHR010 wrote:
> We get our Linux OS and filesystem packaged from a third-party company.
> These are the versions of the SELinux packages included in the bundle.
> The version number looked a bit strange to me, so I wanted to check with
> the selinux community...
> 
> So are you saying this  "svn2950" version doesn't officially exist
> anymore, and its *NOT* a stable and tested version ?
> 

svn 2950 was the last revision we had in the subversion tree on sourceforge. We 
have since moved to git on userspace.selinuxproject.org. There was never a 
release rolled from that revision in subversion as far as I know. Therefore yes, 
it does not officially exist, except as the first checkin to our git tree, and 
was not released as stable.

> Thanks,
> 
> - Rezaul.
> 
> 
> -----Original Message-----
> From: Joshua Brindle [mailto:method@manicmethod.com] 
> Sent: Monday, April 06, 2009 2:19 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; selinux@tycho.nsa.gov
> Subject: Re: SELinux packages version (svn2950)...
> 
> Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I work on a product that uses Linux Kernel 2.6.21.  As such, I am 
>> currently using the following SELinux libs and related package
> versions:
>> audit            1.5.3
>> checkpolicy      1.33.1
>> libselinux       2.0.13
>> libsemanage      2.0.1
>> libsepol         2.0.3
>> libsetrans       0.1.18
>> policycoreutils  2.0.16
>>
>>
>>
>> We are considering moving upto Linux Kernel 2.6.27, and as such we 
>> would automatically get upgraded to the following package versions:
>>
>> audit            1.7.2
>> checkpolicy      svn2950
>> libselinux       svn2950
>> libsemanage      svn2950
>> libsepol         svn2950
>> libsetrans       N/A
>> policycoreutils  svn2950
>>
>>
>> ** My questions are:
>>
>> 1. Do all the packages of version (svn2950) play nicely together ?
>> 2. What are the major advantages of upgrading to svn2950 ?
>> 3. Are there any disadvantages, or any changes that I should be aware 
>> or cencerned about ?
>> 4. Why is the version number so drastically different ? Is this a 
>> result of a totally new effort ?
>> 5. Please feel free to share any thoughts / suggestions / advice as 
>> far as upgrading to this newer version...
>>
>> Thanks in advance for all your help.
>>
> 
> There is no subversion repository anymore, all the subversion repos
> should be down at this point, where did you find that revision?
> 
> The packages are now in git at http://userspace.selinuxproject.org/ and
> a release was just made at
> http://userspace.selinuxproject.org/trac/wiki/Releases .
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: SELinux packages version (svn2950)...

[Hasan Rezaul-CHR010]

Thanks so much  :-)

So the versions below are the latest and greatest, and officially stable
and tested ?

checkpolicy-2.0.19 
libselinux-2.0.79 
libsemanage-2.0.31 
libsepol-2.0.36 
policycoreutils-2.0.62 
sepolgen-1.0.16 

- Rezaul.



-----Original Message-----
From: Hasan Rezaul-CHR010 
Sent: Monday, April 06, 2009 2:49 PM
To: 'Joshua Brindle'
Cc: Stephen Smalley; selinux@tycho.nsa.gov; Cheng Heilung-HCHENG1
Subject: RE: SELinux packages version (svn2950)...

We get our Linux OS and filesystem packaged from a third-party company.
These are the versions of the SELinux packages included in the bundle.
The version number looked a bit strange to me, so I wanted to check with
the selinux community...

So are you saying this  "svn2950" version doesn't officially exist
anymore, and its *NOT* a stable and tested version ?

Thanks,

- Rezaul.


-----Original Message-----
From: Joshua Brindle [mailto:method@manicmethod.com]
Sent: Monday, April 06, 2009 2:19 PM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; selinux@tycho.nsa.gov
Subject: Re: SELinux packages version (svn2950)...

Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I work on a product that uses Linux Kernel 2.6.21.  As such, I am 
> currently using the following SELinux libs and related package
versions:
> 
> audit            1.5.3
> checkpolicy      1.33.1
> libselinux       2.0.13
> libsemanage      2.0.1
> libsepol         2.0.3
> libsetrans       0.1.18
> policycoreutils  2.0.16
> 
> 
> 
> We are considering moving upto Linux Kernel 2.6.27, and as such we 
> would automatically get upgraded to the following package versions:
> 
> audit            1.7.2
> checkpolicy      svn2950
> libselinux       svn2950
> libsemanage      svn2950
> libsepol         svn2950
> libsetrans       N/A
> policycoreutils  svn2950
> 
> 
> ** My questions are:
> 
> 1. Do all the packages of version (svn2950) play nicely together ?
> 2. What are the major advantages of upgrading to svn2950 ?
> 3. Are there any disadvantages, or any changes that I should be aware 
> or cencerned about ?
> 4. Why is the version number so drastically different ? Is this a 
> result of a totally new effort ?
> 5. Please feel free to share any thoughts / suggestions / advice as 
> far as upgrading to this newer version...
> 
> Thanks in advance for all your help.
> 

There is no subversion repository anymore, all the subversion repos
should be down at this point, where did you find that revision?

The packages are now in git at http://userspace.selinuxproject.org/ and
a release was just made at
http://userspace.selinuxproject.org/trac/wiki/Releases .


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux packages version (svn2950)...

[Joshua Brindle]

Hasan Rezaul-CHR010 wrote:
> Thanks so much  :-)
> 
> So the versions below are the latest and greatest, and officially stable
> and tested ?
> 
> checkpolicy-2.0.19 
> libselinux-2.0.79 
> libsemanage-2.0.31 
> libsepol-2.0.36 
> policycoreutils-2.0.62 
> sepolgen-1.0.16 
> 
> - Rezaul.
> 

They are official releases from the upstream project and are the latest and 
greatest.  The testing upstream has unit tests and some integration tests but 
most of our testing comes from rawhide users after Dan Walsh has pulled the 
packages in to rawhide (which he has).

> 
> -----Original Message-----
> From: Hasan Rezaul-CHR010 
> Sent: Monday, April 06, 2009 2:49 PM
> To: 'Joshua Brindle'
> Cc: Stephen Smalley; selinux@tycho.nsa.gov; Cheng Heilung-HCHENG1
> Subject: RE: SELinux packages version (svn2950)...
> 
> We get our Linux OS and filesystem packaged from a third-party company.
> These are the versions of the SELinux packages included in the bundle.
> The version number looked a bit strange to me, so I wanted to check with
> the selinux community...
> 
> So are you saying this  "svn2950" version doesn't officially exist
> anymore, and its *NOT* a stable and tested version ?
> 
> Thanks,
> 
> - Rezaul.
> 
> 
> -----Original Message-----
> From: Joshua Brindle [mailto:method@manicmethod.com]
> Sent: Monday, April 06, 2009 2:19 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; selinux@tycho.nsa.gov
> Subject: Re: SELinux packages version (svn2950)...
> 
> Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I work on a product that uses Linux Kernel 2.6.21.  As such, I am 
>> currently using the following SELinux libs and related package
> versions:
>> audit            1.5.3
>> checkpolicy      1.33.1
>> libselinux       2.0.13
>> libsemanage      2.0.1
>> libsepol         2.0.3
>> libsetrans       0.1.18
>> policycoreutils  2.0.16
>>
>>
>>
>> We are considering moving upto Linux Kernel 2.6.27, and as such we 
>> would automatically get upgraded to the following package versions:
>>
>> audit            1.7.2
>> checkpolicy      svn2950
>> libselinux       svn2950
>> libsemanage      svn2950
>> libsepol         svn2950
>> libsetrans       N/A
>> policycoreutils  svn2950
>>
>>
>> ** My questions are:
>>
>> 1. Do all the packages of version (svn2950) play nicely together ?
>> 2. What are the major advantages of upgrading to svn2950 ?
>> 3. Are there any disadvantages, or any changes that I should be aware 
>> or cencerned about ?
>> 4. Why is the version number so drastically different ? Is this a 
>> result of a totally new effort ?
>> 5. Please feel free to share any thoughts / suggestions / advice as 
>> far as upgrading to this newer version...
>>
>> Thanks in advance for all your help.
>>
> 
> There is no subversion repository anymore, all the subversion repos
> should be down at this point, where did you find that revision?
> 
> The packages are now in git at http://userspace.selinuxproject.org/ and
> a release was just made at
> http://userspace.selinuxproject.org/trac/wiki/Releases .
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Chris,

what is your opinion for the reworks and bugfixes?

KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
> 
> - rework: Add a comment of "not currently in use" for deprecated
>   permissions, but its definitions are not removed.
> 
> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}
> 
> - rework: All the newly created database objects by unprivileged
>   clients are prefixed with "user_", and these are controled via
>   sepgsql_enable_users_ddl.
>   The current policy allows httpd_t to created a function labeled
>   as sepgsql_proc_t which is also allowed to be installed as a
>   system internal entity (db_procedure:{install}).
>   It is a potentially risk for trojan horse.
> 
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> 
> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> 
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> 
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> 
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> 
> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> Thanks,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy@oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Chris,

what is your opinion for the reworks and bugfixes?

KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
> 
> - rework: Add a comment of "not currently in use" for deprecated
>   permissions, but its definitions are not removed.
> 
> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}
> 
> - rework: All the newly created database objects by unprivileged
>   clients are prefixed with "user_", and these are controled via
>   sepgsql_enable_users_ddl.
>   The current policy allows httpd_t to created a function labeled
>   as sepgsql_proc_t which is also allowed to be installed as a
>   system internal entity (db_procedure:{install}).
>   It is a potentially risk for trojan horse.
> 
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> 
> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> 
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> 
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> 
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> 
> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> Thanks,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
> 
> - rework: Add a comment of "not currently in use" for deprecated
>   permissions, but its definitions are not removed.

"deprecated" should be sufficient.

> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}

Looks ok to me.

> - rework: All the newly created database objects by unprivileged
>   clients are prefixed with "user_", and these are controled via
>   sepgsql_enable_users_ddl.

I don't think we should be mixing user content with other unpriv
clients.

>   The current policy allows httpd_t to created a function labeled
>   as sepgsql_proc_t which is also allowed to be installed as a
>   system internal entity (db_procedure:{install}).
>   It is a potentially risk for trojan horse.
> 
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().

See above comment.

> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> 
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> 
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> 
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> 
> - bugfix: MLS policy didn't constrain the db_procedure class.

Seems ok.

It would be helpful to break up the patch into a set to make it easier
to review in the future.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
> 
> - rework: Add a comment of "not currently in use" for deprecated
>   permissions, but its definitions are not removed.

"deprecated" should be sufficient.

> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}

Looks ok to me.

> - rework: All the newly created database objects by unprivileged
>   clients are prefixed with "user_", and these are controled via
>   sepgsql_enable_users_ddl.

I don't think we should be mixing user content with other unpriv
clients.

>   The current policy allows httpd_t to created a function labeled
>   as sepgsql_proc_t which is also allowed to be installed as a
>   system internal entity (db_procedure:{install}).
>   It is a potentially risk for trojan horse.
> 
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().

See above comment.

> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> 
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> 
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> 
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> 
> - bugfix: MLS policy didn't constrain the db_procedure class.

Seems ok.

It would be helpful to break up the patch into a set to make it easier
to review in the future.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
>> The attached patch provides some of reworks and bugfuxes
>> except for new object classes and permissions.
>>
>> - rework: Add a comment of "not currently in use" for deprecated
>>   permissions, but its definitions are not removed.
> 
> "deprecated" should be sufficient.

OK

>> - rework: All the newly created database objects by unprivileged
>>   clients are prefixed with "user_", and these are controled via
>>   sepgsql_enable_users_ddl.
> 
> I don't think we should be mixing user content with other unpriv
> clients.

I would like to discriminate between a procedure declared by unpriv
client and by administrative client, because the policy allows the
unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
component, but it is undesirable to install unpriv-user defined
procedures as is.

If the "user_" prefix is unpreferable, how do you think other prefixes
something like "anon_", "unpriv_" and so on?

>>   The current policy allows httpd_t to created a function labeled
>>   as sepgsql_proc_t which is also allowed to be installed as a
>>   system internal entity (db_procedure:{install}).
>>   It is a potentially risk for trojan horse.
>>
>> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> 
> See above comment.
> 
>> - bugfix: some of permissions in db_procedure class are allowed
>>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>>   It should allow them on sepgsql_trusted_proc_exec_t.
>>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>>   such kind of confusion, as Chris suggested before.
>>
>> - rework: we should not allow db_procedure:{install} on the
>>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>>   procedure implicitly.
>>
>> - rework: db_table:{lock} is moved to reader side, because it makes
>>   impossible to refer read-only table with foreign-key constraint.
>>   (FK checks internally acquire explicit locks.)
>>
>> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>>   but it is required whrn the largeobject is refered.
>>
>> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> Seems ok.
> 
> It would be helpful to break up the patch into a set to make it easier
> to review in the future.

OK,

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
>> The attached patch provides some of reworks and bugfuxes
>> except for new object classes and permissions.
>>
>> - rework: Add a comment of "not currently in use" for deprecated
>>   permissions, but its definitions are not removed.
> 
> "deprecated" should be sufficient.

OK

>> - rework: All the newly created database objects by unprivileged
>>   clients are prefixed with "user_", and these are controled via
>>   sepgsql_enable_users_ddl.
> 
> I don't think we should be mixing user content with other unpriv
> clients.

I would like to discriminate between a procedure declared by unpriv
client and by administrative client, because the policy allows the
unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
component, but it is undesirable to install unpriv-user defined
procedures as is.

If the "user_" prefix is unpreferable, how do you think other prefixes
something like "anon_", "unpriv_" and so on?

>>   The current policy allows httpd_t to created a function labeled
>>   as sepgsql_proc_t which is also allowed to be installed as a
>>   system internal entity (db_procedure:{install}).
>>   It is a potentially risk for trojan horse.
>>
>> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> 
> See above comment.
> 
>> - bugfix: some of permissions in db_procedure class are allowed
>>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>>   It should allow them on sepgsql_trusted_proc_exec_t.
>>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>>   such kind of confusion, as Chris suggested before.
>>
>> - rework: we should not allow db_procedure:{install} on the
>>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>>   procedure implicitly.
>>
>> - rework: db_table:{lock} is moved to reader side, because it makes
>>   impossible to refer read-only table with foreign-key constraint.
>>   (FK checks internally acquire explicit locks.)
>>
>> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>>   but it is required whrn the largeobject is refered.
>>
>> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> Seems ok.
> 
> It would be helpful to break up the patch into a set to make it easier
> to review in the future.

OK,

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

Chris, the attached patch is the part you already OK'ed.

- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
    db_database:{getattr}
    db_table:{getattr lock}
    db_column:{getattr}
    db_procedure:{drop getattr setattr}
    db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
  impossible to refer read-only table with foreign-key constraint.
  (FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
  on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
  It should allow them on sepgsql_trusted_proc_exec_t.
  I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
  such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
  sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
  procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
  but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.

I'll send the rest of patches after we determine what prefix is preferable
for unprivileged domains.

Thanks,

Christopher J. PeBenito wrote:
> On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
>> The attached patch provides some of reworks and bugfuxes
>> except for new object classes and permissions.
>>
>> - rework: Add a comment of "not currently in use" for deprecated
>>   permissions, but its definitions are not removed.
> 
> "deprecated" should be sufficient.
> 
>> - bugfix: MCS policy did not constrain the following permissions.
>>     db_database:{getattr}
>>     db_table:{getattr lock}
>>     db_column:{getattr}
>>     db_procedure:{drop getattr setattr}
>>     db_blob:{getattr import export}
> 
> Looks ok to me.
> 
>> - rework: All the newly created database objects by unprivileged
>>   clients are prefixed with "user_", and these are controled via
>>   sepgsql_enable_users_ddl.
> 
> I don't think we should be mixing user content with other unpriv
> clients.
> 
>>   The current policy allows httpd_t to created a function labeled
>>   as sepgsql_proc_t which is also allowed to be installed as a
>>   system internal entity (db_procedure:{install}).
>>   It is a potentially risk for trojan horse.
>>
>> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> 
> See above comment.
> 
>> - bugfix: some of permissions in db_procedure class are allowed
>>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>>   It should allow them on sepgsql_trusted_proc_exec_t.
>>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>>   such kind of confusion, as Chris suggested before.
>>
>> - rework: we should not allow db_procedure:{install} on the
>>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>>   procedure implicitly.
>>
>> - rework: db_table:{lock} is moved to reader side, because it makes
>>   impossible to refer read-only table with foreign-key constraint.
>>   (FK checks internally acquire explicit locks.)
>>
>> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>>   but it is required whrn the largeobject is refered.
>>
>> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> Seems ok.
> 
> It would be helpful to break up the patch into a set to make it easier
> to review in the future.
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-bugfixes.4.patch --]
[-- Type: text/x-patch, Size: 10216 bytes --]

Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2963)
+++ policy/flask/access_vectors	(working copy)
@@ -723,14 +723,14 @@
 	access
 	install_module
 	load_module
-	get_param
-	set_param
+	get_param	# deprecated
+	set_param	# deprecated
 }
 
 class db_table
 inherits database
 {
-	use
+	use		# deprecated
 	select
 	update
 	insert
@@ -749,7 +749,7 @@
 class db_column
 inherits database
 {
-	use
+	use		# deprecated
 	select
 	update
 	insert
@@ -759,7 +759,7 @@
 {
 	relabelfrom
 	relabelto
-	use
+	use		# deprecated
 	select
 	update
 	insert
Index: policy/mcs
===================================================================
--- policy/mcs	(revision 2963)
+++ policy/mcs	(working copy)
@@ -111,22 +111,22 @@
 	(( h1 dom h2 ) and ( l2 eq h2 ));
 
 # Access control for any database objects based on MCS rules.
-mlsconstrain db_database { drop setattr relabelfrom access install_module load_module get_param set_param }
+mlsconstrain db_database { drop getattr setattr relabelfrom access install_module load_module get_param set_param }
 	( h1 dom h2 );
 
-mlsconstrain db_table { drop setattr relabelfrom select update insert delete use }
+mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete use lock }
 	( h1 dom h2 );
 
-mlsconstrain db_column { drop setattr relabelfrom select update insert use }
+mlsconstrain db_column { drop getattr setattr relabelfrom select update insert use }
 	( h1 dom h2 );
 
 mlsconstrain db_tuple { relabelfrom select update delete use }
 	( h1 dom h2 );
 
-mlsconstrain db_procedure { execute install }
+mlsconstrain db_procedure { drop getattr setattr execute install }
 	( h1 dom h2 );
 
-mlsconstrain db_blob { drop setattr relabelfrom read write }
+mlsconstrain db_blob { drop getattr setattr relabelfrom read write import export }
 	( h1 dom h2 );
 
 ') dnl end enable_mcs
Index: policy/modules/services/postgresql.if
===================================================================
--- policy/modules/services/postgresql.if	(revision 2963)
+++ policy/modules/services/postgresql.if	(working copy)
@@ -55,7 +55,7 @@
 		type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
 	')
 
-	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete };
+	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete lock };
 	allow $2 user_sepgsql_table_t:db_column { getattr setattr use select update insert };
 	allow $2 user_sepgsql_table_t:db_tuple	{ use select update insert delete };
 	allow $2 user_sepgsql_sysobj_t:db_tuple	{ use select };
@@ -319,14 +319,14 @@
 
 		attribute sepgsql_client_type;
 
-		type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_t, sepgsql_blob_t;
+		type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_exec_t, sepgsql_blob_t;
 		type sepgsql_trusted_proc_t, sepgsql_trusted_proc_exec_t;
 	')
 
 	typeattribute $1 sepgsql_client_type;
 
 	type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
-	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_t;
+	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_exec_t;
 	type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
 
 	type_transition $1 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
Index: policy/modules/services/postgresql.te
===================================================================
--- policy/modules/services/postgresql.te	(revision 2963)
+++ policy/modules/services/postgresql.te	(working copy)
@@ -66,8 +66,9 @@
 type sepgsql_fixed_table_t;
 postgresql_table_object(sepgsql_fixed_table_t)
 
-type sepgsql_proc_t;
-postgresql_procedure_object(sepgsql_proc_t)
+type sepgsql_proc_exec_t;
+typealias sepgsql_proc_exec_t alias { sepgsql_proc_t };
+postgresql_procedure_object(sepgsql_proc_exec_t)
 
 type sepgsql_ro_blob_t;
 postgresql_blob_object(sepgsql_ro_blob_t)
@@ -143,7 +144,7 @@
 type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t;
 
 allow postgresql_t sepgsql_procedure_type:db_procedure *;
-type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_exec_t;
 
 allow postgresql_t sepgsql_blob_type:db_blob *;
 type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
@@ -284,27 +285,27 @@
 allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
 type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
 
-allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert lock };
 allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr use select insert };
 allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { use select insert };
 
-allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete };
+allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete lock };
 allow sepgsql_client_type sepgsql_table_t:db_column { getattr use select update insert };
 allow sepgsql_client_type sepgsql_table_t:db_tuple { use select update insert delete };
 
-allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select lock };
 allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr use select };
 allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { use select };
 
 allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
 allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
 
-allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select lock };
 allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr use select };
 allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
 
-allow sepgsql_client_type sepgsql_proc_t:db_procedure { getattr execute install };
-allow sepgsql_client_type sepgsql_trusted_proc_t:db_procedure { getattr execute entrypoint };
+allow sepgsql_client_type sepgsql_proc_exec_t:db_procedure { getattr execute install };
+allow sepgsql_client_type sepgsql_trusted_proc_exec_t:db_procedure { getattr execute entrypoint };
 
 allow sepgsql_client_type sepgsql_blob_t:db_blob { create drop getattr setattr read write };
 allow sepgsql_client_type sepgsql_ro_blob_t:db_blob { getattr read };
@@ -338,15 +339,16 @@
 type_transition sepgsql_unconfined_type sepgsql_unconfined_type:db_database sepgsql_db_t;
 
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_table sepgsql_table_t;
-type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_exec_t;
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_blob sepgsql_blob_t;
 
 allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;
 
 # unconfined domain is not allowed to invoke user defined procedure directly.
 # They have to confirm and relabel it at first.
-allow sepgsql_unconfined_type { sepgsql_proc_t sepgsql_trusted_proc_t }:db_procedure *;
-allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto };
+allow sepgsql_unconfined_type sepgsql_proc_exec_t:db_procedure *;
+allow sepgsql_unconfined_type sepgsql_trusted_proc_exec_t:db_procedure ~{ install };
+allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure ~{ execute install };
 
 allow sepgsql_unconfined_type sepgsql_blob_type:db_blob *;
 
Index: policy/mls
===================================================================
--- policy/mls	(revision 2963)
+++ policy/mls	(working copy)
@@ -709,19 +709,25 @@
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_table db_column } { getattr use select }
+mlsconstrain { db_table } { getattr use select lock }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_column } { getattr use select }
+	(( l1 dom l2 ) or
+	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsdbread ) or
+	 ( t2 == mlstrustedobject ));
+
 mlsconstrain { db_procedure } { getattr execute install }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_blob } { getattr read }
+mlsconstrain { db_blob } { getattr read export }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsdbread ) or
@@ -741,7 +747,7 @@
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete lock }
+mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
@@ -755,13 +761,20 @@
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
-mlsconstrain { db_blob } { create drop setattr relabelfrom write import export }
+mlsconstrain { db_procedure } { create drop setattr relabelfrom }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_blob } { create drop setattr relabelfrom write import }
+	(( l1 eq l2 ) or
+	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
+	 (( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
+	 ( t1 == mlsdbwrite ) or
+	 ( t2 == mlstrustedobject ));
+
 mlsconstrain { db_tuple } { relabelfrom update insert delete }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

Chris, the attached patch is the part you already OK'ed.

- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
    db_database:{getattr}
    db_table:{getattr lock}
    db_column:{getattr}
    db_procedure:{drop getattr setattr}
    db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
  impossible to refer read-only table with foreign-key constraint.
  (FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
  on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
  It should allow them on sepgsql_trusted_proc_exec_t.
  I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
  such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
  sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
  procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
  but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.

I'll send the rest of patches after we determine what prefix is preferable
for unprivileged domains.

Thanks,

Christopher J. PeBenito wrote:
> On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
>> The attached patch provides some of reworks and bugfuxes
>> except for new object classes and permissions.
>>
>> - rework: Add a comment of "not currently in use" for deprecated
>>   permissions, but its definitions are not removed.
> 
> "deprecated" should be sufficient.
> 
>> - bugfix: MCS policy did not constrain the following permissions.
>>     db_database:{getattr}
>>     db_table:{getattr lock}
>>     db_column:{getattr}
>>     db_procedure:{drop getattr setattr}
>>     db_blob:{getattr import export}
> 
> Looks ok to me.
> 
>> - rework: All the newly created database objects by unprivileged
>>   clients are prefixed with "user_", and these are controled via
>>   sepgsql_enable_users_ddl.
> 
> I don't think we should be mixing user content with other unpriv
> clients.
> 
>>   The current policy allows httpd_t to created a function labeled
>>   as sepgsql_proc_t which is also allowed to be installed as a
>>   system internal entity (db_procedure:{install}).
>>   It is a potentially risk for trojan horse.
>>
>> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> 
> See above comment.
> 
>> - bugfix: some of permissions in db_procedure class are allowed
>>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>>   It should allow them on sepgsql_trusted_proc_exec_t.
>>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>>   such kind of confusion, as Chris suggested before.
>>
>> - rework: we should not allow db_procedure:{install} on the
>>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>>   procedure implicitly.
>>
>> - rework: db_table:{lock} is moved to reader side, because it makes
>>   impossible to refer read-only table with foreign-key constraint.
>>   (FK checks internally acquire explicit locks.)
>>
>> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>>   but it is required whrn the largeobject is refered.
>>
>> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> Seems ok.
> 
> It would be helpful to break up the patch into a set to make it easier
> to review in the future.
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-bugfixes.4.patch
Type: text/x-patch
Size: 10216 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090421/88754dc6/attachment-0001.bin 

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Tue, 2009-04-21 at 08:27 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> >> The attached patch provides some of reworks and bugfuxes
> >> except for new object classes and permissions.
> >>

> >> - rework: All the newly created database objects by unprivileged
> >>   clients are prefixed with "user_", and these are controled via
> >>   sepgsql_enable_users_ddl.
> > 
> > I don't think we should be mixing user content with other unpriv
> > clients.
> 
> I would like to discriminate between a procedure declared by unpriv
> client and by administrative client, because the policy allows the
> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
> component, but it is undesirable to install unpriv-user defined
> procedures as is.
> 
> If the "user_" prefix is unpreferable, how do you think other prefixes
> something like "anon_", "unpriv_" and so on?

I think we should go with unpriv_ for now.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Tue, 2009-04-21 at 08:27 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> >> The attached patch provides some of reworks and bugfuxes
> >> except for new object classes and permissions.
> >>

> >> - rework: All the newly created database objects by unprivileged
> >>   clients are prefixed with "user_", and these are controled via
> >>   sepgsql_enable_users_ddl.
> > 
> > I don't think we should be mixing user content with other unpriv
> > clients.
> 
> I would like to discriminate between a procedure declared by unpriv
> client and by administrative client, because the policy allows the
> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
> component, but it is undesirable to install unpriv-user defined
> procedures as is.
> 
> If the "user_" prefix is unpreferable, how do you think other prefixes
> something like "anon_", "unpriv_" and so on?

I think we should go with unpriv_ for now.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Tue, 2009-04-21 at 11:51 +0900, KaiGai Kohei wrote:
> Chris, the attached patch is the part you already OK'ed.
> 
> - rework: Add a comment of "deprecated" for deprecated permissions.
> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> I'll send the rest of patches after we determine what prefix is preferable
> for unprivileged domains.

Merged.

> Christopher J. PeBenito wrote:
> > On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> >> The attached patch provides some of reworks and bugfuxes
> >> except for new object classes and permissions.
> >>
> >> - rework: Add a comment of "not currently in use" for deprecated
> >>   permissions, but its definitions are not removed.
> > 
> > "deprecated" should be sufficient.
> > 
> >> - bugfix: MCS policy did not constrain the following permissions.
> >>     db_database:{getattr}
> >>     db_table:{getattr lock}
> >>     db_column:{getattr}
> >>     db_procedure:{drop getattr setattr}
> >>     db_blob:{getattr import export}
> > 
> > Looks ok to me.
> > 
> >> - rework: All the newly created database objects by unprivileged
> >>   clients are prefixed with "user_", and these are controled via
> >>   sepgsql_enable_users_ddl.
> > 
> > I don't think we should be mixing user content with other unpriv
> > clients.
> > 
> >>   The current policy allows httpd_t to created a function labeled
> >>   as sepgsql_proc_t which is also allowed to be installed as a
> >>   system internal entity (db_procedure:{install}).
> >>   It is a potentially risk for trojan horse.
> >>
> >> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> > 
> > See above comment.
> > 
> >> - bugfix: some of permissions in db_procedure class are allowed
> >>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
> >>   It should allow them on sepgsql_trusted_proc_exec_t.
> >>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
> >>   such kind of confusion, as Chris suggested before.
> >>
> >> - rework: we should not allow db_procedure:{install} on the
> >>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
> >>   procedure implicitly.
> >>
> >> - rework: db_table:{lock} is moved to reader side, because it makes
> >>   impossible to refer read-only table with foreign-key constraint.
> >>   (FK checks internally acquire explicit locks.)
> >>
> >> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
> >>   but it is required whrn the largeobject is refered.
> >>
> >> - bugfix: MLS policy didn't constrain the db_procedure class.
> > 
> > Seems ok.
> > 
> > It would be helpful to break up the patch into a set to make it easier
> > to review in the future.
> > 
> 
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Tue, 2009-04-21 at 11:51 +0900, KaiGai Kohei wrote:
> Chris, the attached patch is the part you already OK'ed.
> 
> - rework: Add a comment of "deprecated" for deprecated permissions.
> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> - bugfix: MLS policy didn't constrain the db_procedure class.
> 
> I'll send the rest of patches after we determine what prefix is preferable
> for unprivileged domains.

Merged.

> Christopher J. PeBenito wrote:
> > On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> >> The attached patch provides some of reworks and bugfuxes
> >> except for new object classes and permissions.
> >>
> >> - rework: Add a comment of "not currently in use" for deprecated
> >>   permissions, but its definitions are not removed.
> > 
> > "deprecated" should be sufficient.
> > 
> >> - bugfix: MCS policy did not constrain the following permissions.
> >>     db_database:{getattr}
> >>     db_table:{getattr lock}
> >>     db_column:{getattr}
> >>     db_procedure:{drop getattr setattr}
> >>     db_blob:{getattr import export}
> > 
> > Looks ok to me.
> > 
> >> - rework: All the newly created database objects by unprivileged
> >>   clients are prefixed with "user_", and these are controled via
> >>   sepgsql_enable_users_ddl.
> > 
> > I don't think we should be mixing user content with other unpriv
> > clients.
> > 
> >>   The current policy allows httpd_t to created a function labeled
> >>   as sepgsql_proc_t which is also allowed to be installed as a
> >>   system internal entity (db_procedure:{install}).
> >>   It is a potentially risk for trojan horse.
> >>
> >> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> > 
> > See above comment.
> > 
> >> - bugfix: some of permissions in db_procedure class are allowed
> >>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
> >>   It should allow them on sepgsql_trusted_proc_exec_t.
> >>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
> >>   such kind of confusion, as Chris suggested before.
> >>
> >> - rework: we should not allow db_procedure:{install} on the
> >>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
> >>   procedure implicitly.
> >>
> >> - rework: db_table:{lock} is moved to reader side, because it makes
> >>   impossible to refer read-only table with foreign-key constraint.
> >>   (FK checks internally acquire explicit locks.)
> >>
> >> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
> >>   but it is required whrn the largeobject is refered.
> >>
> >> - bugfix: MLS policy didn't constrain the db_procedure class.
> > 
> > Seems ok.
> > 
> > It would be helpful to break up the patch into a set to make it easier
> > to review in the future.
> > 
> 
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

>>>> - rework: All the newly created database objects by unprivileged
>>>>   clients are prefixed with "user_", and these are controled via
>>>>   sepgsql_enable_users_ddl.
>>> I don't think we should be mixing user content with other unpriv
>>> clients.
>> I would like to discriminate between a procedure declared by unpriv
>> client and by administrative client, because the policy allows the
>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>> component, but it is undesirable to install unpriv-user defined
>> procedures as is.
>>
>> If the "user_" prefix is unpreferable, how do you think other prefixes
>> something like "anon_", "unpriv_" and so on?
> 
> I think we should go with unpriv_ for now.

OK, the attached patch adds the following types for unprivileged clients.
 - unpriv_sepgsql_table_t
 - unpriv_sepgsql_sysobj_t
 - unpriv_sepgsql_proc_exec_t
 - unpriv_sepgsql_blob_t

These types are the default for unprivileged and unprefixed domains,
such as httpd_t and others.

In addition, TYPE_TRANSITION rules are moved to outside of tunable
of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
tunable because UBAC domains (user_t and so on) were allowed to
create sepgsql_table_t, and its default was pointed to this type
when sepgsql_enable_users_ddl is disabled.
However, it has different meanings now, so the TYPE_TRANSITION rules
should be unconditional.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-1-unpriv-types.patch --]
[-- Type: text/x-patch, Size: 4557 bytes --]

Index: policy/modules/services/postgresql.if
===================================================================
--- policy/modules/services/postgresql.if	(revision 2982)
+++ policy/modules/services/postgresql.if	(working copy)
@@ -47,18 +47,17 @@
 
 	tunable_policy(`sepgsql_enable_users_ddl',`
 		allow $2 user_sepgsql_table_t:db_table { create drop };
-		type_transition $2 sepgsql_database_type:db_table user_sepgsql_table_t;
-
 		allow $2 user_sepgsql_table_t:db_column { create drop };
-
 		allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
-		type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
 	')
 
 	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete lock };
 	allow $2 user_sepgsql_table_t:db_column { getattr setattr use select update insert };
 	allow $2 user_sepgsql_table_t:db_tuple	{ use select update insert delete };
+	type_transition $2 sepgsql_database_type:db_table user_sepgsql_table_t;
+
 	allow $2 user_sepgsql_sysobj_t:db_tuple	{ use select };
+	type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
 
 	allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
 	type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
@@ -313,24 +312,55 @@
 #
 interface(`postgresql_unpriv_client',`
 	gen_require(`
+		class db_database all_db_database_perms;
 		class db_table all_db_table_perms;
 		class db_procedure all_db_procedure_perms;
+		class db_column all_db_column_perms;
+		class db_tuple all_db_tuple_perms;
 		class db_blob all_db_blob_perms;
 
 		attribute sepgsql_client_type;
+		attribute sepgsql_database_type, sepgsql_sysobj_table_type;
 
-		type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_exec_t, sepgsql_blob_t;
 		type sepgsql_trusted_proc_t, sepgsql_trusted_proc_exec_t;
+		type unpriv_sepgsql_blob_t, unpriv_sepgsql_proc_exec_t;
+		type unpriv_sepgsql_sysobj_t, unpriv_sepgsql_table_t;
 	')
 
+	########################################
+	#
+	# Declarations
+	#
+
 	typeattribute $1 sepgsql_client_type;
 
-	type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
-	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_exec_t;
-	type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
+	########################################
+	#
+	# Client local policy
+	#
 
 	type_transition $1 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
 	allow $1 sepgsql_trusted_proc_t:process transition;
+
+	tunable_policy(`sepgsql_enable_users_ddl',`
+		allow $1 unpriv_sepgsql_table_t:db_table { create drop setattr };
+		allow $1 unpriv_sepgsql_table_t:db_column { create drop setattr };
+		allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update insert delete };
+	')
+
+	allow $1 unpriv_sepgsql_table_t:db_table { getattr use select update insert delete lock };
+	allow $1 unpriv_sepgsql_table_t:db_column { getattr use select update insert };
+	allow $1 unpriv_sepgsql_table_t:db_tuple { use select update insert delete };
+	type_transition $1 sepgsql_database_type:db_table unpriv_sepgsql_table_t;
+
+	allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
+	type_transition $1 sepgsql_sysobj_table_type:db_tuple unpriv_sepgsql_sysobj_t;
+
+	allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
+	type_transition $1 sepgsql_database_type:db_procedure unpriv_sepgsql_proc_exec_t;
+
+	allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
+	type_transition $1 sepgsql_database_type:db_blob unpriv_sepgsql_blob_t;
 ')
 
 ########################################
Index: policy/modules/services/postgresql.te
===================================================================
--- policy/modules/services/postgresql.te	(revision 2982)
+++ policy/modules/services/postgresql.te	(working copy)
@@ -97,6 +97,20 @@
 postgresql_unconfined(sepgsql_trusted_proc_t)
 role system_r types sepgsql_trusted_proc_t;
 
+# Types for unprivileged client
+type unpriv_sepgsql_blob_t;
+postgresql_blob_object(unpriv_sepgsql_blob_t)
+
+type unpriv_sepgsql_proc_exec_t;
+postgresql_procedure_object(unpriv_sepgsql_proc_exec_t)
+
+type unpriv_sepgsql_sysobj_t;
+postgresql_system_table_object(unpriv_sepgsql_sysobj_t)
+
+type unpriv_sepgsql_table_t;
+postgresql_table_object(unpriv_sepgsql_table_t)
+
+# Types for UBAC
 type user_sepgsql_blob_t;
 typealias user_sepgsql_blob_t alias { staff_sepgsql_blob_t sysadm_sepgsql_blob_t };
 typealias user_sepgsql_blob_t alias { auditadm_sepgsql_blob_t secadm_sepgsql_blob_t };

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

>>>> - rework: All the newly created database objects by unprivileged
>>>>   clients are prefixed with "user_", and these are controled via
>>>>   sepgsql_enable_users_ddl.
>>> I don't think we should be mixing user content with other unpriv
>>> clients.
>> I would like to discriminate between a procedure declared by unpriv
>> client and by administrative client, because the policy allows the
>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>> component, but it is undesirable to install unpriv-user defined
>> procedures as is.
>>
>> If the "user_" prefix is unpreferable, how do you think other prefixes
>> something like "anon_", "unpriv_" and so on?
> 
> I think we should go with unpriv_ for now.

OK, the attached patch adds the following types for unprivileged clients.
 - unpriv_sepgsql_table_t
 - unpriv_sepgsql_sysobj_t
 - unpriv_sepgsql_proc_exec_t
 - unpriv_sepgsql_blob_t

These types are the default for unprivileged and unprefixed domains,
such as httpd_t and others.

In addition, TYPE_TRANSITION rules are moved to outside of tunable
of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
tunable because UBAC domains (user_t and so on) were allowed to
create sepgsql_table_t, and its default was pointed to this type
when sepgsql_enable_users_ddl is disabled.
However, it has different meanings now, so the TYPE_TRANSITION rules
should be unconditional.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-1-unpriv-types.patch
Type: text/x-patch
Size: 4557 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/9306855a/attachment.bin 

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

The attached patch fixes incorrect behavior in sepgsql_enable_users_ddl.

The current policy allows users/unprivs to run ALTER TABLE statement
unconditionally, because db_table/db_column:{setattr} is allowed outside
of the boolean. It should be moved to conditional section.

In addition, they are also allowed to db_procedure:{create drop setattr}
for xxxx_sepgsql_proc_exec_t, but it means we allows them to create, drop
or alter definition of the functions unconditionally. So, it also should
be moved to conditional section.

The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
it should not be allowed.

Thanks,

KaiGai Kohei wrote:
>>>>> - rework: All the newly created database objects by unprivileged
>>>>>   clients are prefixed with "user_", and these are controled via
>>>>>   sepgsql_enable_users_ddl.
>>>> I don't think we should be mixing user content with other unpriv
>>>> clients.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
> 
> Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch --]
[-- Type: text/x-patch, Size: 3331 bytes --]

--- policy/modules/services/postgresql.if	2009-05-08 12:32:51.000000000 +0900
+++ policy/modules/services/postgresql.if.2	2009-05-08 11:58:46.000000000 +0900
@@ -46,20 +46,21 @@
 	#
 
 	tunable_policy(`sepgsql_enable_users_ddl',`
-		allow $2 user_sepgsql_table_t:db_table { create drop };
-		allow $2 user_sepgsql_table_t:db_column { create drop };
+		allow $2 user_sepgsql_table_t:db_table { create drop setattr };
+		allow $2 user_sepgsql_table_t:db_column { create drop setattr };
 		allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
+		allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop setattr };
 	')
 
-	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete lock };
-	allow $2 user_sepgsql_table_t:db_column { getattr setattr use select update insert };
+	allow $2 user_sepgsql_table_t:db_table  { setattr use select update insert delete lock };
+	allow $2 user_sepgsql_table_t:db_column { setattr use select update insert };
 	allow $2 user_sepgsql_table_t:db_tuple	{ use select update insert delete };
 	type_transition $2 sepgsql_database_type:db_table user_sepgsql_table_t;
 
 	allow $2 user_sepgsql_sysobj_t:db_tuple	{ use select };
 	type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
 
-	allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
+	allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr execute };
 	type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
 
 	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
@@ -346,6 +347,7 @@
 		allow $1 unpriv_sepgsql_table_t:db_table { create drop setattr };
 		allow $1 unpriv_sepgsql_table_t:db_column { create drop setattr };
 		allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update insert delete };
+		allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop setattr };
 	')
 
 	allow $1 unpriv_sepgsql_table_t:db_table { getattr use select update insert delete lock };
@@ -356,7 +358,7 @@
 	allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
 	type_transition $1 sepgsql_sysobj_table_type:db_tuple unpriv_sepgsql_sysobj_t;
 
-	allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
+	allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr execute };
 	type_transition $1 sepgsql_database_type:db_procedure unpriv_sepgsql_proc_exec_t;
 
 	allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
--- policy/modules/services/postgresql.te	2009-05-08 12:38:30.000000000 +0900
+++ policy/modules/services/postgresql.te.2	2009-05-08 12:39:10.000000000 +0900
@@ -338,12 +338,6 @@
 # Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.
 dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { use select update insert delete };
 
-tunable_policy(`sepgsql_enable_users_ddl',`
-	allow sepgsql_client_type sepgsql_table_t:db_table { create drop setattr };
-	allow sepgsql_client_type sepgsql_table_t:db_column { create drop setattr };
-	allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update insert delete };
-')
-
 ########################################
 #
 # Unconfined access to this module

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

The attached patch fixes incorrect behavior in sepgsql_enable_users_ddl.

The current policy allows users/unprivs to run ALTER TABLE statement
unconditionally, because db_table/db_column:{setattr} is allowed outside
of the boolean. It should be moved to conditional section.

In addition, they are also allowed to db_procedure:{create drop setattr}
for xxxx_sepgsql_proc_exec_t, but it means we allows them to create, drop
or alter definition of the functions unconditionally. So, it also should
be moved to conditional section.

The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
it should not be allowed.

Thanks,

KaiGai Kohei wrote:
>>>>> - rework: All the newly created database objects by unprivileged
>>>>>   clients are prefixed with "user_", and these are controled via
>>>>>   sepgsql_enable_users_ddl.
>>>> I don't think we should be mixing user content with other unpriv
>>>> clients.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
> 
> Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch
Type: text/x-patch
Size: 3331 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/440c820d/attachment.bin 

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

The attached patch allows unprivileged clients to export from or import
to the largeobject owned by themselves.

The current security policy does not allow them to import/export any
largeobjects without any clear reason.

NOTE: Export of the largeobject means that it dumps whole of the
largeobject into a local file, so SE-PostgreSQL checks both of
db_blob:{read export} on the largeobject and file:{write} on the
local file. Import is a reversal behavior.

Thanks,

KaiGai Kohei wrote:
>>>>> - rework: All the newly created database objects by unprivileged
>>>>>   clients are prefixed with "user_", and these are controled via
>>>>>   sepgsql_enable_users_ddl.
>>>> I don't think we should be mixing user content with other unpriv
>>>> clients.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
> 
> Thanks,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy@oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-3-db_blob-import-export.patch --]
[-- Type: text/x-patch, Size: 1082 bytes --]

--- policy/modules/services/postgresql.if.2	2009-05-08 11:58:46.000000000 +0900
+++ policy/modules/services/postgresql.if.3	2009-05-08 11:59:28.000000000 +0900
@@ -63,7 +63,7 @@
 	allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr execute };
 	type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
 
-	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
+	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
 	type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
 
 	allow $2 sepgsql_trusted_proc_t:process transition;
@@ -361,7 +361,7 @@
 	allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr execute };
 	type_transition $1 sepgsql_database_type:db_procedure unpriv_sepgsql_proc_exec_t;
 
-	allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
+	allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
 	type_transition $1 sepgsql_database_type:db_blob unpriv_sepgsql_blob_t;
 ')
 

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[KaiGai Kohei]

The attached patch allows unprivileged clients to export from or import
to the largeobject owned by themselves.

The current security policy does not allow them to import/export any
largeobjects without any clear reason.

NOTE: Export of the largeobject means that it dumps whole of the
largeobject into a local file, so SE-PostgreSQL checks both of
db_blob:{read export} on the largeobject and file:{write} on the
local file. Import is a reversal behavior.

Thanks,

KaiGai Kohei wrote:
>>>>> - rework: All the newly created database objects by unprivileged
>>>>>   clients are prefixed with "user_", and these are controled via
>>>>>   sepgsql_enable_users_ddl.
>>>> I don't think we should be mixing user content with other unpriv
>>>> clients.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
> 
> Thanks,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-3-db_blob-import-export.patch
Type: text/x-patch
Size: 1082 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/a3d74af0/attachment.bin 

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Fri, 2009-05-08 at 12:56 +0900, KaiGai Kohei wrote:
> >>>> - rework: All the newly created database objects by unprivileged
> >>>>   clients are prefixed with "user_", and these are controled via
> >>>>   sepgsql_enable_users_ddl.
> >>> I don't think we should be mixing user content with other unpriv
> >>> clients.
> >> I would like to discriminate between a procedure declared by unpriv
> >> client and by administrative client, because the policy allows the
> >> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >> component, but it is undesirable to install unpriv-user defined
> >> procedures as is.
> >>
> >> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >> something like "anon_", "unpriv_" and so on?
> > 
> > I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged
> clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.

Merged.

> 
> Index: policy/modules/services/postgresql.if
> ===================================================================
> --- policy/modules/services/postgresql.if       (revision 2982)
> +++ policy/modules/services/postgresql.if       (working copy)
> @@ -47,18 +47,17 @@
>  
>         tunable_policy(`sepgsql_enable_users_ddl',`
>                 allow $2 user_sepgsql_table_t:db_table { create
> drop };
> -               type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
> -
>                 allow $2 user_sepgsql_table_t:db_column { create
> drop };
> -
>                 allow $2 user_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> -               type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>         ')
>  
>         allow $2 user_sepgsql_table_t:db_table  { getattr setattr use
> select update insert delete lock };
>         allow $2 user_sepgsql_table_t:db_column { getattr setattr use
> select update insert };
>         allow $2 user_sepgsql_table_t:db_tuple  { use select update
> insert delete };
> +       type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
> +
>         allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
> +       type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>  
>         allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
>         type_transition $2 sepgsql_database_type:db_procedure
> user_sepgsql_proc_exec_t;
> @@ -313,24 +312,55 @@
>  #
>  interface(`postgresql_unpriv_client',`
>         gen_require(`
> +               class db_database all_db_database_perms;
>                 class db_table all_db_table_perms;
>                 class db_procedure all_db_procedure_perms;
> +               class db_column all_db_column_perms;
> +               class db_tuple all_db_tuple_perms;
>                 class db_blob all_db_blob_perms;
>  
>                 attribute sepgsql_client_type;
> +               attribute sepgsql_database_type,
> sepgsql_sysobj_table_type;
>  
> -               type sepgsql_db_t, sepgsql_table_t,
> sepgsql_proc_exec_t, sepgsql_blob_t;
>                 type sepgsql_trusted_proc_t,
> sepgsql_trusted_proc_exec_t;
> +               type unpriv_sepgsql_blob_t,
> unpriv_sepgsql_proc_exec_t;
> +               type unpriv_sepgsql_sysobj_t, unpriv_sepgsql_table_t;
>         ')
>  
> +       ########################################
> +       #
> +       # Declarations
> +       #
> +
>         typeattribute $1 sepgsql_client_type;
>  
> -       type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
> -       type_transition $1 sepgsql_db_t:db_procedure
> sepgsql_proc_exec_t;
> -       type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
> +       ########################################
> +       #
> +       # Client local policy
> +       #
>  
>         type_transition $1 sepgsql_trusted_proc_exec_t:process
> sepgsql_trusted_proc_t;
>         allow $1 sepgsql_trusted_proc_t:process transition;
> +
> +       tunable_policy(`sepgsql_enable_users_ddl',`
> +               allow $1 unpriv_sepgsql_table_t:db_table { create drop
> setattr };
> +               allow $1 unpriv_sepgsql_table_t:db_column { create
> drop setattr };
> +               allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> +       ')
> +
> +       allow $1 unpriv_sepgsql_table_t:db_table { getattr use select
> update insert delete lock };
> +       allow $1 unpriv_sepgsql_table_t:db_column { getattr use select
> update insert };
> +       allow $1 unpriv_sepgsql_table_t:db_tuple { use select update
> insert delete };
> +       type_transition $1 sepgsql_database_type:db_table
> unpriv_sepgsql_table_t;
> +
> +       allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
> +       type_transition $1 sepgsql_sysobj_table_type:db_tuple
> unpriv_sepgsql_sysobj_t;
> +
> +       allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> +       type_transition $1 sepgsql_database_type:db_procedure
> unpriv_sepgsql_proc_exec_t;
> +
> +       allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> +       type_transition $1 sepgsql_database_type:db_blob
> unpriv_sepgsql_blob_t;
>  ')
>  
>  ########################################
> Index: policy/modules/services/postgresql.te
> ===================================================================
> --- policy/modules/services/postgresql.te       (revision 2982)
> +++ policy/modules/services/postgresql.te       (working copy)
> @@ -97,6 +97,20 @@
>  postgresql_unconfined(sepgsql_trusted_proc_t)
>  role system_r types sepgsql_trusted_proc_t;
>  
> +# Types for unprivileged client
> +type unpriv_sepgsql_blob_t;
> +postgresql_blob_object(unpriv_sepgsql_blob_t)
> +
> +type unpriv_sepgsql_proc_exec_t;
> +postgresql_procedure_object(unpriv_sepgsql_proc_exec_t)
> +
> +type unpriv_sepgsql_sysobj_t;
> +postgresql_system_table_object(unpriv_sepgsql_sysobj_t)
> +
> +type unpriv_sepgsql_table_t;
> +postgresql_table_object(unpriv_sepgsql_table_t)
> +
> +# Types for UBAC
>  type user_sepgsql_blob_t;
>  typealias user_sepgsql_blob_t alias { staff_sepgsql_blob_t
> sysadm_sepgsql_blob_t };
>  typealias user_sepgsql_blob_t alias { auditadm_sepgsql_blob_t
> secadm_sepgsql_blob_t };
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Fri, 2009-05-08 at 12:56 +0900, KaiGai Kohei wrote:
> >>>> - rework: All the newly created database objects by unprivileged
> >>>>   clients are prefixed with "user_", and these are controled via
> >>>>   sepgsql_enable_users_ddl.
> >>> I don't think we should be mixing user content with other unpriv
> >>> clients.
> >> I would like to discriminate between a procedure declared by unpriv
> >> client and by administrative client, because the policy allows the
> >> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >> component, but it is undesirable to install unpriv-user defined
> >> procedures as is.
> >>
> >> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >> something like "anon_", "unpriv_" and so on?
> > 
> > I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged
> clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.

Merged.

> 
> Index: policy/modules/services/postgresql.if
> ===================================================================
> --- policy/modules/services/postgresql.if       (revision 2982)
> +++ policy/modules/services/postgresql.if       (working copy)
> @@ -47,18 +47,17 @@
>  
>         tunable_policy(`sepgsql_enable_users_ddl',`
>                 allow $2 user_sepgsql_table_t:db_table { create
> drop };
> -               type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
> -
>                 allow $2 user_sepgsql_table_t:db_column { create
> drop };
> -
>                 allow $2 user_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> -               type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>         ')
>  
>         allow $2 user_sepgsql_table_t:db_table  { getattr setattr use
> select update insert delete lock };
>         allow $2 user_sepgsql_table_t:db_column { getattr setattr use
> select update insert };
>         allow $2 user_sepgsql_table_t:db_tuple  { use select update
> insert delete };
> +       type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
> +
>         allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
> +       type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>  
>         allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
>         type_transition $2 sepgsql_database_type:db_procedure
> user_sepgsql_proc_exec_t;
> @@ -313,24 +312,55 @@
>  #
>  interface(`postgresql_unpriv_client',`
>         gen_require(`
> +               class db_database all_db_database_perms;
>                 class db_table all_db_table_perms;
>                 class db_procedure all_db_procedure_perms;
> +               class db_column all_db_column_perms;
> +               class db_tuple all_db_tuple_perms;
>                 class db_blob all_db_blob_perms;
>  
>                 attribute sepgsql_client_type;
> +               attribute sepgsql_database_type,
> sepgsql_sysobj_table_type;
>  
> -               type sepgsql_db_t, sepgsql_table_t,
> sepgsql_proc_exec_t, sepgsql_blob_t;
>                 type sepgsql_trusted_proc_t,
> sepgsql_trusted_proc_exec_t;
> +               type unpriv_sepgsql_blob_t,
> unpriv_sepgsql_proc_exec_t;
> +               type unpriv_sepgsql_sysobj_t, unpriv_sepgsql_table_t;
>         ')
>  
> +       ########################################
> +       #
> +       # Declarations
> +       #
> +
>         typeattribute $1 sepgsql_client_type;
>  
> -       type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
> -       type_transition $1 sepgsql_db_t:db_procedure
> sepgsql_proc_exec_t;
> -       type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
> +       ########################################
> +       #
> +       # Client local policy
> +       #
>  
>         type_transition $1 sepgsql_trusted_proc_exec_t:process
> sepgsql_trusted_proc_t;
>         allow $1 sepgsql_trusted_proc_t:process transition;
> +
> +       tunable_policy(`sepgsql_enable_users_ddl',`
> +               allow $1 unpriv_sepgsql_table_t:db_table { create drop
> setattr };
> +               allow $1 unpriv_sepgsql_table_t:db_column { create
> drop setattr };
> +               allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> +       ')
> +
> +       allow $1 unpriv_sepgsql_table_t:db_table { getattr use select
> update insert delete lock };
> +       allow $1 unpriv_sepgsql_table_t:db_column { getattr use select
> update insert };
> +       allow $1 unpriv_sepgsql_table_t:db_tuple { use select update
> insert delete };
> +       type_transition $1 sepgsql_database_type:db_table
> unpriv_sepgsql_table_t;
> +
> +       allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
> +       type_transition $1 sepgsql_sysobj_table_type:db_tuple
> unpriv_sepgsql_sysobj_t;
> +
> +       allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> +       type_transition $1 sepgsql_database_type:db_procedure
> unpriv_sepgsql_proc_exec_t;
> +
> +       allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> +       type_transition $1 sepgsql_database_type:db_blob
> unpriv_sepgsql_blob_t;
>  ')
>  
>  ########################################
> Index: policy/modules/services/postgresql.te
> ===================================================================
> --- policy/modules/services/postgresql.te       (revision 2982)
> +++ policy/modules/services/postgresql.te       (working copy)
> @@ -97,6 +97,20 @@
>  postgresql_unconfined(sepgsql_trusted_proc_t)
>  role system_r types sepgsql_trusted_proc_t;
>  
> +# Types for unprivileged client
> +type unpriv_sepgsql_blob_t;
> +postgresql_blob_object(unpriv_sepgsql_blob_t)
> +
> +type unpriv_sepgsql_proc_exec_t;
> +postgresql_procedure_object(unpriv_sepgsql_proc_exec_t)
> +
> +type unpriv_sepgsql_sysobj_t;
> +postgresql_system_table_object(unpriv_sepgsql_sysobj_t)
> +
> +type unpriv_sepgsql_table_t;
> +postgresql_table_object(unpriv_sepgsql_table_t)
> +
> +# Types for UBAC
>  type user_sepgsql_blob_t;
>  typealias user_sepgsql_blob_t alias { staff_sepgsql_blob_t
> sysadm_sepgsql_blob_t };
>  typealias user_sepgsql_blob_t alias { auditadm_sepgsql_blob_t
> secadm_sepgsql_blob_t };
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Fri, 2009-05-08 at 13:05 +0900, KaiGai Kohei wrote:
> The attached patch fixes incorrect behavior in
> sepgsql_enable_users_ddl.
> 
> The current policy allows users/unprivs to run ALTER TABLE statement
> unconditionally, because db_table/db_column:{setattr} is allowed
> outside
> of the boolean. It should be moved to conditional section.
> 
> In addition, they are also allowed to db_procedure:{create drop
> setattr}
> for xxxx_sepgsql_proc_exec_t, but it means we allows them to create,
> drop
> or alter definition of the functions unconditionally. So, it also
> should
> be moved to conditional section.
> 
> The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
> and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
> it should not be allowed.

Merged.  I fixed the user section which removed the unconditional
getattr instead of the unconditional setattr.

> KaiGai Kohei wrote:
> >>>>> - rework: All the newly created database objects by unprivileged
> >>>>>   clients are prefixed with "user_", and these are controled via
> >>>>>   sepgsql_enable_users_ddl.
> >>>> I don't think we should be mixing user content with other unpriv
> >>>> clients.
> >>> I would like to discriminate between a procedure declared by
> unpriv
> >>> client and by administrative client, because the policy allows the
> >>> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >>> component, but it is undesirable to install unpriv-user defined
> >>> procedures as is.
> >>>
> >>> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >>> something like "anon_", "unpriv_" and so on?
> >> I think we should go with unpriv_ for now.
> > 
> > OK, the attached patch adds the following types for unprivileged
> clients.
> >  - unpriv_sepgsql_table_t
> >  - unpriv_sepgsql_sysobj_t
> >  - unpriv_sepgsql_proc_exec_t
> >  - unpriv_sepgsql_blob_t
> > 
> > These types are the default for unprivileged and unprefixed domains,
> > such as httpd_t and others.
> > 
> > In addition, TYPE_TRANSITION rules are moved to outside of tunable
> > of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> > tunable because UBAC domains (user_t and so on) were allowed to
> > create sepgsql_table_t, and its default was pointed to this type
> > when sepgsql_enable_users_ddl is disabled.
> > However, it has different meanings now, so the TYPE_TRANSITION rules
> > should be unconditional.
> > 
> > Thanks,
> -- 
> OSS Platform Development Division, NEC
> KaiGai Kohei <kaigai@ak.jp.nec.com>
> 
> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch)
> 
> --- policy/modules/services/postgresql.if       2009-05-08
> 12:32:51.000000000 +0900
> +++ policy/modules/services/postgresql.if.2     2009-05-08
> 11:58:46.000000000 +0900
> @@ -46,20 +46,21 @@
>         #
>  
>         tunable_policy(`sepgsql_enable_users_ddl',`
> -               allow $2 user_sepgsql_table_t:db_table { create
> drop };
> -               allow $2 user_sepgsql_table_t:db_column { create
> drop };
> +               allow $2 user_sepgsql_table_t:db_table { create drop
> setattr };
> +               allow $2 user_sepgsql_table_t:db_column { create drop
> setattr };
>                 allow $2 user_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> +               allow $2 user_sepgsql_proc_exec_t:db_procedure
> { create drop setattr };
>         ')
>  
> -       allow $2 user_sepgsql_table_t:db_table  { getattr setattr use
> select update insert delete lock };
> -       allow $2 user_sepgsql_table_t:db_column { getattr setattr use
> select update insert };
> +       allow $2 user_sepgsql_table_t:db_table  { setattr use select
> update insert delete lock };
> +       allow $2 user_sepgsql_table_t:db_column { setattr use select
> update insert };
>         allow $2 user_sepgsql_table_t:db_tuple  { use select update
> insert delete };
>         type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
>  
>         allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
>         type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>  
> -       allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> +       allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr
> execute };
>         type_transition $2 sepgsql_database_type:db_procedure
> user_sepgsql_proc_exec_t;
>  
>         allow $2 user_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> @@ -346,6 +347,7 @@
>                 allow $1 unpriv_sepgsql_table_t:db_table { create drop
> setattr };
>                 allow $1 unpriv_sepgsql_table_t:db_column { create
> drop setattr };
>                 allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> +               allow $1 unpriv_sepgsql_proc_exec_t:db_procedure
> { create drop setattr };
>         ')
>  
>         allow $1 unpriv_sepgsql_table_t:db_table { getattr use select
> update insert delete lock };
> @@ -356,7 +358,7 @@
>         allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
>         type_transition $1 sepgsql_sysobj_table_type:db_tuple
> unpriv_sepgsql_sysobj_t;
>  
> -       allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> +       allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr
> execute };
>         type_transition $1 sepgsql_database_type:db_procedure
> unpriv_sepgsql_proc_exec_t;
>  
>         allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> --- policy/modules/services/postgresql.te       2009-05-08
> 12:38:30.000000000 +0900
> +++ policy/modules/services/postgresql.te.2     2009-05-08
> 12:39:10.000000000 +0900
> @@ -338,12 +338,6 @@
>  # Therefore, the following rule is applied for any domains which can
> connect SE-PostgreSQL.
>  dontaudit { postgresql_t sepgsql_client_type
> sepgsql_unconfined_type } { sepgsql_table_type
> -sepgsql_sysobj_table_type }:db_tuple { use select update insert
> delete };
>  
> -tunable_policy(`sepgsql_enable_users_ddl',`
> -       allow sepgsql_client_type sepgsql_table_t:db_table { create
> drop setattr };
> -       allow sepgsql_client_type sepgsql_table_t:db_column { create
> drop setattr };
> -       allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update
> insert delete };
> -')
> -
>  ########################################
>  #
>  # Unconfined access to this module
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Fri, 2009-05-08 at 13:05 +0900, KaiGai Kohei wrote:
> The attached patch fixes incorrect behavior in
> sepgsql_enable_users_ddl.
> 
> The current policy allows users/unprivs to run ALTER TABLE statement
> unconditionally, because db_table/db_column:{setattr} is allowed
> outside
> of the boolean. It should be moved to conditional section.
> 
> In addition, they are also allowed to db_procedure:{create drop
> setattr}
> for xxxx_sepgsql_proc_exec_t, but it means we allows them to create,
> drop
> or alter definition of the functions unconditionally. So, it also
> should
> be moved to conditional section.
> 
> The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
> and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
> it should not be allowed.

Merged.  I fixed the user section which removed the unconditional
getattr instead of the unconditional setattr.

> KaiGai Kohei wrote:
> >>>>> - rework: All the newly created database objects by unprivileged
> >>>>>   clients are prefixed with "user_", and these are controled via
> >>>>>   sepgsql_enable_users_ddl.
> >>>> I don't think we should be mixing user content with other unpriv
> >>>> clients.
> >>> I would like to discriminate between a procedure declared by
> unpriv
> >>> client and by administrative client, because the policy allows the
> >>> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >>> component, but it is undesirable to install unpriv-user defined
> >>> procedures as is.
> >>>
> >>> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >>> something like "anon_", "unpriv_" and so on?
> >> I think we should go with unpriv_ for now.
> > 
> > OK, the attached patch adds the following types for unprivileged
> clients.
> >  - unpriv_sepgsql_table_t
> >  - unpriv_sepgsql_sysobj_t
> >  - unpriv_sepgsql_proc_exec_t
> >  - unpriv_sepgsql_blob_t
> > 
> > These types are the default for unprivileged and unprefixed domains,
> > such as httpd_t and others.
> > 
> > In addition, TYPE_TRANSITION rules are moved to outside of tunable
> > of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> > tunable because UBAC domains (user_t and so on) were allowed to
> > create sepgsql_table_t, and its default was pointed to this type
> > when sepgsql_enable_users_ddl is disabled.
> > However, it has different meanings now, so the TYPE_TRANSITION rules
> > should be unconditional.
> > 
> > Thanks,
> -- 
> OSS Platform Development Division, NEC
> KaiGai Kohei <kaigai@ak.jp.nec.com>
> 
> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch)
> 
> --- policy/modules/services/postgresql.if       2009-05-08
> 12:32:51.000000000 +0900
> +++ policy/modules/services/postgresql.if.2     2009-05-08
> 11:58:46.000000000 +0900
> @@ -46,20 +46,21 @@
>         #
>  
>         tunable_policy(`sepgsql_enable_users_ddl',`
> -               allow $2 user_sepgsql_table_t:db_table { create
> drop };
> -               allow $2 user_sepgsql_table_t:db_column { create
> drop };
> +               allow $2 user_sepgsql_table_t:db_table { create drop
> setattr };
> +               allow $2 user_sepgsql_table_t:db_column { create drop
> setattr };
>                 allow $2 user_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> +               allow $2 user_sepgsql_proc_exec_t:db_procedure
> { create drop setattr };
>         ')
>  
> -       allow $2 user_sepgsql_table_t:db_table  { getattr setattr use
> select update insert delete lock };
> -       allow $2 user_sepgsql_table_t:db_column { getattr setattr use
> select update insert };
> +       allow $2 user_sepgsql_table_t:db_table  { setattr use select
> update insert delete lock };
> +       allow $2 user_sepgsql_table_t:db_column { setattr use select
> update insert };
>         allow $2 user_sepgsql_table_t:db_tuple  { use select update
> insert delete };
>         type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
>  
>         allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
>         type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>  
> -       allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> +       allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr
> execute };
>         type_transition $2 sepgsql_database_type:db_procedure
> user_sepgsql_proc_exec_t;
>  
>         allow $2 user_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> @@ -346,6 +347,7 @@
>                 allow $1 unpriv_sepgsql_table_t:db_table { create drop
> setattr };
>                 allow $1 unpriv_sepgsql_table_t:db_column { create
> drop setattr };
>                 allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> +               allow $1 unpriv_sepgsql_proc_exec_t:db_procedure
> { create drop setattr };
>         ')
>  
>         allow $1 unpriv_sepgsql_table_t:db_table { getattr use select
> update insert delete lock };
> @@ -356,7 +358,7 @@
>         allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
>         type_transition $1 sepgsql_sysobj_table_type:db_tuple
> unpriv_sepgsql_sysobj_t;
>  
> -       allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> +       allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr
> execute };
>         type_transition $1 sepgsql_database_type:db_procedure
> unpriv_sepgsql_proc_exec_t;
>  
>         allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> --- policy/modules/services/postgresql.te       2009-05-08
> 12:38:30.000000000 +0900
> +++ policy/modules/services/postgresql.te.2     2009-05-08
> 12:39:10.000000000 +0900
> @@ -338,12 +338,6 @@
>  # Therefore, the following rule is applied for any domains which can
> connect SE-PostgreSQL.
>  dontaudit { postgresql_t sepgsql_client_type
> sepgsql_unconfined_type } { sepgsql_table_type
> -sepgsql_sysobj_table_type }:db_tuple { use select update insert
> delete };
>  
> -tunable_policy(`sepgsql_enable_users_ddl',`
> -       allow sepgsql_client_type sepgsql_table_t:db_table { create
> drop setattr };
> -       allow sepgsql_client_type sepgsql_table_t:db_column { create
> drop setattr };
> -       allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update
> insert delete };
> -')
> -
>  ########################################
>  #
>  # Unconfined access to this module
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Fri, 2009-05-08 at 13:12 +0900, KaiGai Kohei wrote:
> The attached patch allows unprivileged clients to export from or
> import
> to the largeobject owned by themselves.
> 
> The current security policy does not allow them to import/export any
> largeobjects without any clear reason.
> 
> NOTE: Export of the largeobject means that it dumps whole of the
> largeobject into a local file, so SE-PostgreSQL checks both of
> db_blob:{read export} on the largeobject and file:{write} on the
> local file. Import is a reversal behavior.

Merged.

> KaiGai Kohei wrote:
> >>>>> - rework: All the newly created database objects by unprivileged
> >>>>>   clients are prefixed with "user_", and these are controled via
> >>>>>   sepgsql_enable_users_ddl.
> >>>> I don't think we should be mixing user content with other unpriv
> >>>> clients.
> >>> I would like to discriminate between a procedure declared by
> unpriv
> >>> client and by administrative client, because the policy allows the
> >>> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >>> component, but it is undesirable to install unpriv-user defined
> >>> procedures as is.
> >>>
> >>> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >>> something like "anon_", "unpriv_" and so on?
> >> I think we should go with unpriv_ for now.
> > 
> > OK, the attached patch adds the following types for unprivileged
> clients.
> >  - unpriv_sepgsql_table_t
> >  - unpriv_sepgsql_sysobj_t
> >  - unpriv_sepgsql_proc_exec_t
> >  - unpriv_sepgsql_blob_t
> > 
> > These types are the default for unprivileged and unprefixed domains,
> > such as httpd_t and others.
> > 
> > In addition, TYPE_TRANSITION rules are moved to outside of tunable
> > of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> > tunable because UBAC domains (user_t and so on) were allowed to
> > create sepgsql_table_t, and its default was pointed to this type
> > when sepgsql_enable_users_ddl is disabled.
> > However, it has different meanings now, so the TYPE_TRANSITION rules
> > should be unconditional.
> > 

> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (refpolicy-sepgsql-3-db_blob-import-export.patch)
> 
> --- policy/modules/services/postgresql.if.2     2009-05-08 11:58:46.000000000 +0900
> +++ policy/modules/services/postgresql.if.3     2009-05-08 11:59:28.000000000 +0900
> @@ -63,7 +63,7 @@
>         allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr execute };
>         type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
>  
> -       allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
> +       allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
>         type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
>  
>         allow $2 sepgsql_trusted_proc_t:process transition;
> @@ -361,7 +361,7 @@
>         allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr execute };
>         type_transition $1 sepgsql_database_type:db_procedure unpriv_sepgsql_proc_exec_t;
>  
> -       allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
> +       allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
>         type_transition $1 sepgsql_database_type:db_blob unpriv_sepgsql_blob_t;
>  ')
>  
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] [RFC] Security policy reworks for SE-PostgreSQL

[Christopher J. PeBenito]

On Fri, 2009-05-08 at 13:12 +0900, KaiGai Kohei wrote:
> The attached patch allows unprivileged clients to export from or
> import
> to the largeobject owned by themselves.
> 
> The current security policy does not allow them to import/export any
> largeobjects without any clear reason.
> 
> NOTE: Export of the largeobject means that it dumps whole of the
> largeobject into a local file, so SE-PostgreSQL checks both of
> db_blob:{read export} on the largeobject and file:{write} on the
> local file. Import is a reversal behavior.

Merged.

> KaiGai Kohei wrote:
> >>>>> - rework: All the newly created database objects by unprivileged
> >>>>>   clients are prefixed with "user_", and these are controled via
> >>>>>   sepgsql_enable_users_ddl.
> >>>> I don't think we should be mixing user content with other unpriv
> >>>> clients.
> >>> I would like to discriminate between a procedure declared by
> unpriv
> >>> client and by administrative client, because the policy allows the
> >>> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >>> component, but it is undesirable to install unpriv-user defined
> >>> procedures as is.
> >>>
> >>> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >>> something like "anon_", "unpriv_" and so on?
> >> I think we should go with unpriv_ for now.
> > 
> > OK, the attached patch adds the following types for unprivileged
> clients.
> >  - unpriv_sepgsql_table_t
> >  - unpriv_sepgsql_sysobj_t
> >  - unpriv_sepgsql_proc_exec_t
> >  - unpriv_sepgsql_blob_t
> > 
> > These types are the default for unprivileged and unprefixed domains,
> > such as httpd_t and others.
> > 
> > In addition, TYPE_TRANSITION rules are moved to outside of tunable
> > of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> > tunable because UBAC domains (user_t and so on) were allowed to
> > create sepgsql_table_t, and its default was pointed to this type
> > when sepgsql_enable_users_ddl is disabled.
> > However, it has different meanings now, so the TYPE_TRANSITION rules
> > should be unconditional.
> > 

> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (refpolicy-sepgsql-3-db_blob-import-export.patch)
> 
> --- policy/modules/services/postgresql.if.2     2009-05-08 11:58:46.000000000 +0900
> +++ policy/modules/services/postgresql.if.3     2009-05-08 11:59:28.000000000 +0900
> @@ -63,7 +63,7 @@
>         allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr execute };
>         type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
>  
> -       allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
> +       allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
>         type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
>  
>         allow $2 sepgsql_trusted_proc_t:process transition;
> @@ -361,7 +361,7 @@
>         allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr execute };
>         type_transition $1 sepgsql_database_type:db_procedure unpriv_sepgsql_proc_exec_t;
>  
> -       allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
> +       allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
>         type_transition $1 sepgsql_database_type:db_blob unpriv_sepgsql_blob_t;
>  ')
>  
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150