[PATCH] Add db_materialized_view object class

[PATCH] Add db_materialized_view object class

[Kohei KaiGai]

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

Hello,

Recent PostgreSQL development newly adds a new feature; materialized view.
However, we have no relevant object class in selinux side, so I'd like to add
a new db_materialized_view object class to support this object type.

Materialized-view allows to construct its result-set to be returned on
references
by user's query preliminarily, to improve performance to scan multiple tables
being combined with complicated joins.
In contradiction to its name, its behavior is almost identical with
regular tables
rather than traditional views. Line SELECT ... INTO command, it saves
a snapshot when a particular user (with security label, of course) references
the underlying tables onto a regular tables in behalf of MV.

In perspective of SELinux, nothings are different from an operation that writes
data being read from another tables to a regular table; it should check
permission to write on the destination table and to read from the source
tables, but materialized-view calls this operation as "refresh".

The attached patch adds db_materialized_view object class with select,
insert, update, delete, lock, refresh and common database permissions.
These permissions shall be checked on relevant accesses in manner of
what regular table doing, and "refresh" shall be also checked when MV
is refreshed.

I didn't define new types for materialized-views, because its behavior is
almost same as regular tables, thus I though it is a reasonable solution
to utilize existing types for tables.

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

[-- Attachment #2: refpolicy-sepgsql-materialized-view-support.v1.patch --]
[-- Type: application/octet-stream, Size: 16167 bytes --]

 policy/flask/access_vectors           | 11 +++++++++++
 policy/flask/security_classes         |  1 +
 policy/mcs                            |  5 ++++-
 policy/mls                            | 17 +++++++++++++++--
 policy/modules/kernel/kernel.if       |  2 ++
 policy/modules/services/postgresql.if | 14 ++++++++++----
 policy/modules/services/postgresql.te | 20 ++++++++++++++------
 7 files changed, 57 insertions(+), 13 deletions(-)

diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
index a94b169..3e0bce6 100644
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -865,3 +865,14 @@ inherits database
 	implement
 	execute
 }
+
+class db_materialized_view
+inherits database
+{
+	select
+	update
+	insert
+	delete
+	lock
+	refresh
+}
diff --git a/policy/flask/security_classes b/policy/flask/security_classes
index 14a4799..22c8534 100644
--- a/policy/flask/security_classes
+++ b/policy/flask/security_classes
@@ -130,5 +130,6 @@ class db_schema			# userspace
 class db_view			# userspace
 class db_sequence		# userspace
 class db_language		# userspace
+class db_materialized_view	# userspace
 
 # FLASK
diff --git a/policy/mcs b/policy/mcs
index 216b3d1..a3f4937 100644
--- a/policy/mcs
+++ b/policy/mcs
@@ -129,7 +129,7 @@ mlsconstrain { tcp_socket udp_socket rawip_socket } node_bind
 
 # Any database object must be dominated by the relabeling subject
 # clearance, also the objects are single-level.
-mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
+mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob db_materialized_view } { create relabelto }
 	(( h1 dom h2 ) and ( l2 eq h2 ));
 
 mlsconstrain { db_tuple } { insert relabelto }
@@ -157,6 +157,9 @@ mlsconstrain db_sequence { drop getattr setattr relabelfrom get_value next_value
 mlsconstrain db_view { drop getattr setattr relabelfrom expand }
 	( h1 dom h2 );
 
+mlsconstrain db_materialized_view { drop getattr setattr relabelfrom select update insert delete lock refresh }
+	( h1 dom h2 );
+
 mlsconstrain db_procedure { drop getattr setattr relabelfrom execute install entrypoint }
 	( h1 dom h2 );
 
diff --git a/policy/mls b/policy/mls
index d218387..1b2e136 100644
--- a/policy/mls
+++ b/policy/mls
@@ -727,13 +727,13 @@ mlsconstrain context contains
 #
 
 # make sure these database classes are "single level"
-mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
+mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob db_materialized_view } { 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_schema db_table db_sequence db_view db_procedure db_language db_column db_tuple db_blob } { relabelto }
+mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_tuple db_blob db_materialized_view } { relabelto }
 	( h1 dom h2 );
 
 # the database "read" ops (note the check is dominance of the low level)
@@ -773,6 +773,12 @@ mlsconstrain { db_view } { getattr expand }
 	 ( t1 == mlsdbread ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_materialized_view } { getattr select lock }
+	(( l1 dom l2 ) or
+	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsdbread ) or
+	 ( t2 == mlstrustedobject ));
+
 mlsconstrain { db_procedure } { getattr execute entrypoint install }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
@@ -840,6 +846,13 @@ mlsconstrain { db_view } { create drop setattr relabelfrom }
 	 ( t1 == mlsdbwrite ) or
 	 ( t2 == mlstrustedobject ));
 
+mlsconstrain { db_materialized_view } { create drop setattr relabelfrom update insert delete refresh }
+	(( 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_procedure } { create drop setattr relabelfrom }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
diff --git a/policy/modules/kernel/kernel.if b/policy/modules/kernel/kernel.if
index 649e458..c7ef9b5 100644
--- a/policy/modules/kernel/kernel.if
+++ b/policy/modules/kernel/kernel.if
@@ -2940,6 +2940,7 @@ interface(`kernel_relabelfrom_unlabeled_database',`
 		class db_table { setattr relabelfrom };
 		class db_sequence { setattr relabelfrom };
 		class db_view { setattr relabelfrom };
+		class db_materialized_view { setattr relabelfrom };
 		class db_procedure { setattr relabelfrom };
 		class db_language { setattr relabelfrom };
 		class db_column { setattr relabelfrom };
@@ -2952,6 +2953,7 @@ interface(`kernel_relabelfrom_unlabeled_database',`
 	allow $1 unlabeled_t:db_table { setattr relabelfrom };
 	allow $1 unlabeled_t:db_sequence { setattr relabelfrom };
 	allow $1 unlabeled_t:db_view { setattr relabelfrom };
+	allow $1 unlabeled_t:db_materialized_view { setattr relabelfrom };
 	allow $1 unlabeled_t:db_procedure { setattr relabelfrom };
 	allow $1 unlabeled_t:db_language { setattr relabelfrom };
 	allow $1 unlabeled_t:db_column { setattr relabelfrom };
diff --git a/policy/modules/services/postgresql.if b/policy/modules/services/postgresql.if
index 9d2f311..58c6433 100644
--- a/policy/modules/services/postgresql.if
+++ b/policy/modules/services/postgresql.if
@@ -22,6 +22,7 @@ interface(`postgresql_role',`
 		class db_table all_db_table_perms;
 		class db_sequence all_db_sequence_perms;
 		class db_view all_db_view_perms;
+		class db_materialized_view all_db_materialized_view_perms;
 		class db_procedure all_db_procedure_perms;
 		class db_language all_db_language_perms;
 		class db_column all_db_column_perms;
@@ -58,6 +59,7 @@ interface(`postgresql_role',`
 		allow $2 user_sepgsql_schema_t:db_schema { create drop setattr };
 		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_table_t:db_materialized_view { create drop setattr };
 		allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
 		allow $2 user_sepgsql_seq_t:db_sequence { create drop setattr set_value };
 		allow $2 user_sepgsql_view_t:db_view { create drop setattr };
@@ -71,7 +73,8 @@ interface(`postgresql_role',`
 	allow $2 user_sepgsql_table_t:db_table	{ getattr select update insert delete lock };
 	allow $2 user_sepgsql_table_t:db_column { getattr select update insert };
 	allow $2 user_sepgsql_table_t:db_tuple	{ select update insert delete };
-	type_transition $2 sepgsql_schema_type:db_table user_sepgsql_table_t;
+	allow $2 user_sepgsql_table_t:db_materialized_view { getattr select update insert delete lock refresh };
+	type_transition $2 sepgsql_schema_type:{ db_table db_materialized_view } 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;
@@ -170,11 +173,11 @@ interface(`postgresql_table_object',`
 
 ########################################
 ## <summary>
-##	Marks as a SE-PostgreSQL system table/column/tuple object type
+##	Marks as a SE-PostgreSQL system table/column/tuple/db_materialized_view object type
 ## </summary>
 ## <param name="type">
 ##	<summary>
-##	Type marked as a table/column/tuple object type.
+##	Type marked as a table/column/tuple/db_materialized_view object type.
 ##	</summary>
 ## </param>
 #
@@ -452,6 +455,7 @@ interface(`postgresql_unpriv_client',`
 		class db_table all_db_table_perms;
 		class db_sequence all_db_sequence_perms;
 		class db_view all_db_view_perms;
+		class db_materialized_view all_db_materialized_view_perms;
 		class db_procedure all_db_procedure_perms;
 		class db_language all_db_language_perms;
 		class db_column all_db_column_perms;
@@ -503,7 +507,8 @@ interface(`postgresql_unpriv_client',`
 	allow $1 unpriv_sepgsql_table_t:db_table { getattr select update insert delete lock };
 	allow $1 unpriv_sepgsql_table_t:db_column { getattr select update insert };
 	allow $1 unpriv_sepgsql_table_t:db_tuple { select update insert delete };
-	type_transition $1 sepgsql_schema_type:db_table unpriv_sepgsql_table_t;
+	allow $1 unpriv_sepgsql_table_t:db_materialized_view { getattr select update insert delete lock refresh };
+	type_transition $1 sepgsql_schema_type:{ db_table db_materialized_view } unpriv_sepgsql_table_t;
 
 	allow $1 unpriv_sepgsql_seq_t:db_sequence { getattr get_value next_value set_value };
 	type_transition $1 sepgsql_schema_type:db_sequence unpriv_sepgsql_seq_t;
@@ -520,6 +525,7 @@ interface(`postgresql_unpriv_client',`
 		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_materialized_view { create drop setattr };
 		allow $1 unpriv_sepgsql_seq_t:db_sequence { create drop setattr };
 		allow $1 unpriv_sepgsql_view_t:db_view { create drop setattr };
 		allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop setattr };
diff --git a/policy/modules/services/postgresql.te b/policy/modules/services/postgresql.te
index 346d011..e84b4a1 100644
--- a/policy/modules/services/postgresql.te
+++ b/policy/modules/services/postgresql.te
@@ -9,6 +9,7 @@ gen_require(`
 	class db_blob all_db_blob_perms;
 	class db_schema all_db_schema_perms;
 	class db_view all_db_view_perms;
+	class db_materialized_view all_db_materialized_view_perms;
 	class db_sequence all_db_sequence_perms;
 	class db_language all_db_language_perms;
 ')
@@ -250,8 +251,9 @@ allow postgresql_t {sepgsql_schema_type sepgsql_temp_object_t}:db_schema *;
 type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_schema_t;
 type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
 
-allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
+allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple db_materialized_view } *;
 type_transition postgresql_t sepgsql_schema_type:db_table sepgsql_sysobj_t;
+type_transition postgresql_t sepgsql_schema_type:db_materialized_view sepgsql_table_t;
 
 allow postgresql_t sepgsql_sequence_type:db_sequence *;
 type_transition postgresql_t sepgsql_schema_type:db_sequence sepgsql_seq_t;
@@ -433,17 +435,21 @@ allow sepgsql_client_type sepgsql_schema_t:db_schema { getattr search };
 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_fixed_table_t:db_materialized_view { getattr select insert lock };
 
 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_table_t:db_materialized_view { getattr select insert lock refresh };
 
 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_ro_table_t:db_materialized_view { getattr select lock };
 
 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_secret_table_t:db_materialized_view getattr;
 
 allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr select lock };
 allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr select };
@@ -483,7 +489,7 @@ allow sepgsql_client_type sepgsql_secret_blob_t:db_blob getattr;
 dontaudit { postgresql_t sepgsql_admin_type sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { use select update insert delete };
 
 # It is always allowed to operate temporary objects for any database client.
-allow sepgsql_client_type sepgsql_temp_object_t:{db_schema db_table db_column db_tuple db_sequence db_view db_procedure} ~{ relabelto relabelfrom };
+allow sepgsql_client_type sepgsql_temp_object_t:{db_schema db_table db_column db_tuple db_sequence db_view db_materialized_view db_procedure} ~{ relabelto relabelfrom };
 
 # Note that permission of creation/deletion are eventually controlled by
 # create or drop permission of individual objects within shared schemas.
@@ -506,8 +512,9 @@ type_transition sepgsql_admin_type sepgsql_database_type:db_schema sepgsql_temp_
 allow sepgsql_admin_type sepgsql_table_type:db_table { create drop getattr setattr relabelfrom relabelto lock };
 allow sepgsql_admin_type sepgsql_table_type:db_column { create drop getattr setattr relabelfrom relabelto };
 allow sepgsql_admin_type sepgsql_sysobj_table_type:db_tuple { relabelfrom relabelto use select update insert delete };
+allow sepgsql_admin_type sepgsql_table_type:db_materialized_view { create drop getattr setattr relabelfrom relabelto lock refresh };
 
-type_transition sepgsql_admin_type sepgsql_schema_type:db_table sepgsql_table_t;
+type_transition sepgsql_admin_type sepgsql_schema_type:{ db_table db_materialized_view } sepgsql_table_t;
 
 allow sepgsql_admin_type sepgsql_sequence_type:db_sequence { create drop getattr setattr relabelfrom relabelto get_value next_value set_value };
 
@@ -522,7 +529,7 @@ allow sepgsql_admin_type sepgsql_proc_exec_t:db_procedure execute;
 
 type_transition sepgsql_admin_type sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
 
-allow sepgsql_admin_type sepgsql_temp_object_t:{db_schema db_table db_column db_tuple db_sequence db_view db_procedure} ~{ relabelto relabelfrom };
+allow sepgsql_admin_type sepgsql_temp_object_t:{db_schema db_table db_column db_tuple db_sequence db_view db_materialized_view db_procedure} ~{ relabelto relabelfrom };
 
 allow sepgsql_admin_type sepgsql_language_type:db_language { create drop getattr setattr relabelfrom relabelto execute };
 
@@ -541,7 +548,7 @@ tunable_policy(`sepgsql_unconfined_dbadm',`
 
 	allow sepgsql_admin_type sepgsql_schema_type:db_schema *;
 
-	allow sepgsql_admin_type sepgsql_table_type:{ db_table db_column db_tuple } *;
+	allow sepgsql_admin_type sepgsql_table_type:{ db_table db_column db_tuple db_materialized_view } *;
 	allow sepgsql_admin_type sepgsql_sequence_type:db_sequence *;
 	allow sepgsql_admin_type sepgsql_view_type:db_view *;
 
@@ -566,13 +573,14 @@ type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
 
 type_transition sepgsql_unconfined_type sepgsql_schema_type:db_table sepgsql_table_t;
+type_transition sepgsql_unconfined_type sepgsql_schema_type:db_materialized_view sepgsql_table_t;
 type_transition sepgsql_unconfined_type sepgsql_schema_type:db_sequence sepgsql_seq_t;
 type_transition sepgsql_unconfined_type sepgsql_schema_type:db_view sepgsql_view_t;
 type_transition sepgsql_unconfined_type sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_language sepgsql_lang_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 } *;
+allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple db_materialized_view } *;
 allow sepgsql_unconfined_type sepgsql_sequence_type:db_sequence *;
 allow sepgsql_unconfined_type sepgsql_view_type:db_view *;
 

[refpolicy] [PATCH] Add db_materialized_view object class

[Kohei KaiGai]

Hello,

Recent PostgreSQL development newly adds a new feature; materialized view.
However, we have no relevant object class in selinux side, so I'd like to add
a new db_materialized_view object class to support this object type.

Materialized-view allows to construct its result-set to be returned on
references
by user's query preliminarily, to improve performance to scan multiple tables
being combined with complicated joins.
In contradiction to its name, its behavior is almost identical with
regular tables
rather than traditional views. Line SELECT ... INTO command, it saves
a snapshot when a particular user (with security label, of course) references
the underlying tables onto a regular tables in behalf of MV.

In perspective of SELinux, nothings are different from an operation that writes
data being read from another tables to a regular table; it should check
permission to write on the destination table and to read from the source
tables, but materialized-view calls this operation as "refresh".

The attached patch adds db_materialized_view object class with select,
insert, update, delete, lock, refresh and common database permissions.
These permissions shall be checked on relevant accesses in manner of
what regular table doing, and "refresh" shall be also checked when MV
is refreshed.

I didn't define new types for materialized-views, because its behavior is
almost same as regular tables, thus I though it is a reasonable solution
to utilize existing types for tables.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-materialized-view-support.v1.patch
Type: application/octet-stream
Size: 16166 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130210/810815ec/attachment-0001.obj 

Re: [PATCH] Add db_materialized_view object class

[Joshua Brindle]

Kohei KaiGai wrote:
> Hello,
>
> Recent PostgreSQL development newly adds a new feature; materialized
> view.
> However, we have no relevant object class in selinux side, so I'd like
> to add
> a new db_materialized_view object class to support this object type.

Why not just use the db_table object class?

>
> Materialized-view allows to construct its result-set to be returned on
> references
> by user's query preliminarily, to improve performance to scan multiple
> tables
> being combined with complicated joins.
> In contradiction to its name, its behavior is almost identical with
> regular tables
> rather than traditional views. Line SELECT ... INTO command, it saves
> a snapshot when a particular user (with security label, of course)
> references
> the underlying tables onto a regular tables in behalf of MV.
>
> In perspective of SELinux, nothings are different from an operation
> that writes
> data being read from another tables to a regular table; it should check
> permission to write on the destination table and to read from the source
> tables, but materialized-view calls this operation as "refresh".
>

If a user has the ability to update a table backing an mv, but not the 
refresh permission on the mv, will the mv now be inconsistent?

> The attached patch adds db_materialized_view object class with select,
> insert, update, delete, lock, refresh and common database permissions.
> These permissions shall be checked on relevant accesses in manner of
> what regular table doing, and "refresh" shall be also checked when MV
> is refreshed.
>

It seems to me that MV's don't really need to be treated specially. If 
you have access to the backing table/row you'll see it, otherwise you 
won't. Running the query that builds an MV shouldn't yield a different 
result from querying the MV, should it?

> I didn't define new types for materialized-views, because its behavior is
> almost same as regular tables, thus I though it is a reasonable solution
> to utilize existing types for tables.
>
> Thanks,

--
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: [PATCH] Add db_materialized_view object class

[Kohei KaiGai]

Sorry for my response being late.

2013/2/26 Joshua Brindle <method@manicmethod.com>:
> Kohei KaiGai wrote:
>>
>> Hello,
>>
>> Recent PostgreSQL development newly adds a new feature; materialized
>> view.
>> However, we have no relevant object class in selinux side, so I'd like
>> to add
>> a new db_materialized_view object class to support this object type.
>
>
> Why not just use the db_table object class?
>
Even though the behavior of MV is almost common with table's one,
we will confuse how to control the "refresh" operation.
If we try to adopt "db_table" object class here, we have no relevant
permissions here. I initially thought to abuse "update" permission for
this purpose, however, it was short-sighted solution because it will
make another problem once MV got updatable feature in future
version.

>> Materialized-view allows to construct its result-set to be returned on
>> references
>> by user's query preliminarily, to improve performance to scan multiple
>> tables
>> being combined with complicated joins.
>> In contradiction to its name, its behavior is almost identical with
>> regular tables
>> rather than traditional views. Line SELECT ... INTO command, it saves
>> a snapshot when a particular user (with security label, of course)
>> references
>> the underlying tables onto a regular tables in behalf of MV.
>>
>> In perspective of SELinux, nothings are different from an operation
>> that writes
>> data being read from another tables to a regular table; it should check
>> permission to write on the destination table and to read from the source
>> tables, but materialized-view calls this operation as "refresh".
>>
>
> If a user has the ability to update a table backing an mv, but not the
> refresh permission on the mv, will the mv now be inconsistent?
>
Yes. But MV is originally designed to refresh itself asynchronously
because of performance perspective.

>> The attached patch adds db_materialized_view object class with select,
>> insert, update, delete, lock, refresh and common database permissions.
>> These permissions shall be checked on relevant accesses in manner of
>> what regular table doing, and "refresh" shall be also checked when MV
>> is refreshed.
>>
>
> It seems to me that MV's don't really need to be treated specially. If you
> have access to the backing table/row you'll see it, otherwise you won't.
> Running the query that builds an MV shouldn't yield a different result from
> querying the MV, should it?
>
Even though backing table/row are the only source for the relevant MV,
it may cause a problem when MV and backing tables have different
security label. For example, when MV has "unclassified" and backing
table has "classified" label, is a user with "classified" able to refresh
the MV with source of classified tables. It will allow unclassified users to
reference classified data via MV.
One other problematic scenario is interaction with row-level security
that generates different view depending on user's credential who
refresh the MV. Then, another one may reference the MV being
refreshed with inconsistent credential.

So, these are the reason why I consider MV should has its own
object class to control "refresh" as writer operation, in addition
to insert, update or delete that may be used for the purpose as
literal in the future version.

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] [PATCH] Add db_materialized_view object class

[Kohei KaiGai]

Sorry for my response being late.

2013/2/26 Joshua Brindle <method@manicmethod.com>:
> Kohei KaiGai wrote:
>>
>> Hello,
>>
>> Recent PostgreSQL development newly adds a new feature; materialized
>> view.
>> However, we have no relevant object class in selinux side, so I'd like
>> to add
>> a new db_materialized_view object class to support this object type.
>
>
> Why not just use the db_table object class?
>
Even though the behavior of MV is almost common with table's one,
we will confuse how to control the "refresh" operation.
If we try to adopt "db_table" object class here, we have no relevant
permissions here. I initially thought to abuse "update" permission for
this purpose, however, it was short-sighted solution because it will
make another problem once MV got updatable feature in future
version.

>> Materialized-view allows to construct its result-set to be returned on
>> references
>> by user's query preliminarily, to improve performance to scan multiple
>> tables
>> being combined with complicated joins.
>> In contradiction to its name, its behavior is almost identical with
>> regular tables
>> rather than traditional views. Line SELECT ... INTO command, it saves
>> a snapshot when a particular user (with security label, of course)
>> references
>> the underlying tables onto a regular tables in behalf of MV.
>>
>> In perspective of SELinux, nothings are different from an operation
>> that writes
>> data being read from another tables to a regular table; it should check
>> permission to write on the destination table and to read from the source
>> tables, but materialized-view calls this operation as "refresh".
>>
>
> If a user has the ability to update a table backing an mv, but not the
> refresh permission on the mv, will the mv now be inconsistent?
>
Yes. But MV is originally designed to refresh itself asynchronously
because of performance perspective.

>> The attached patch adds db_materialized_view object class with select,
>> insert, update, delete, lock, refresh and common database permissions.
>> These permissions shall be checked on relevant accesses in manner of
>> what regular table doing, and "refresh" shall be also checked when MV
>> is refreshed.
>>
>
> It seems to me that MV's don't really need to be treated specially. If you
> have access to the backing table/row you'll see it, otherwise you won't.
> Running the query that builds an MV shouldn't yield a different result from
> querying the MV, should it?
>
Even though backing table/row are the only source for the relevant MV,
it may cause a problem when MV and backing tables have different
security label. For example, when MV has "unclassified" and backing
table has "classified" label, is a user with "classified" able to refresh
the MV with source of classified tables. It will allow unclassified users to
reference classified data via MV.
One other problematic scenario is interaction with row-level security
that generates different view depending on user's credential who
refresh the MV. Then, another one may reference the MV being
refreshed with inconsistent credential.

So, these are the reason why I consider MV should has its own
object class to control "refresh" as writer operation, in addition
to insert, update or delete that may be used for the purpose as
literal in the future version.

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