SE-PostgreSQL Security Policy

The attached patch adds support for SE-PostgreSQL.
Most part of them are same as currently we are distributing via RPM package.

This patch adds some booleans, attributes and types.
You can find out the detailed description about works of them in the chapter 5 of "The Security-Enhanced PostgreSQL Security Guide".
See, http://sepgsql.googlecode.com/files/sepgsql_security_guide.20070903.en.pdf

Any comment please,

Quoted 8 lines · Kohei KaiGai

The attached patch adds support for SE-PostgreSQL.
Most part of them are same as currently we are distributing via RPM package.

This patch adds some booleans, attributes and types.
You can find out the detailed description about works of them in the chapter 5 of "The Security-Enhanced PostgreSQL Security Guide".
See, http://sepgsql.googlecode.com/files/sepgsql_security_guide.20070903.en.pdf

Quoted 1 line

Any comment please,

Just like with the X server, I don't believe that sepostgres should have its own module.

At first glance, there appears to be too many
attributes. I'm guessing that you're doing the same thing that is done with the *_unconfined() interfaces. We mainly do that to optimize size since unconfined brings in so many rules.

I also see references to types and attributes that belong do the module.

Also the auditing
tunables seem unneeded; they seem to be more for debugging use. I think I can get a better handle on the policy with these revisions.

Quoted 2 lines

Just like with the X server, I don't believe that sepostgres should have its own module.

OK, I'll make next one as a patch for services/postgresql.*.

Quoted 4 lines

At first glance, there appears to be too many
attributes. I'm guessing that you're doing the same thing that is done with the *_unconfined() interfaces. We mainly do that to optimize size since unconfined brings in so many rules.

OK, I'll replace current interfaces by the following style's one.

interface(sepostgresql_unconfined',

        gen_require(`
                attribute sepostgresql_unconfined_type;
        ')
        typeattribute $1 sepostgresql_unconfined_type;

')

Quoted 1 line

I also see references to types and attributes that belong do the module.

Is it unlabel_t and system_r?
Where is the best place to associate them with my local policy?

Quoted 3 lines

Also the auditing
tunables seem unneeded; they seem to be more for debugging use. I think I can get a better handle on the policy with these revisions.

Hmm...
The reason why I added these tunables is that database folks told me that collecting logs in column/tuple level is an attractive feature, because native DBMS cannot provide fine-grained access control and cannot collect logs in these level.
Thus, I believe the feature to turn on/off auditing readily should be remained.

Thanks,

The attached patch provides security policies related to SE-PostgreSQL.

The followings are updates/unchanges from the previous version submitted at two weeks ago. These updates replaced most of the part in the previous one.

- The targets of this patch are moved to services/postgresql.*, although the previous one added new entries.
- Any interface got slim. They contains only one TYPEATTRIBUTE statement, and postgresql.te allows most of permissions to the associated attributes.
* Tunables to turn on/off audit are remained now, because database folks told me fine-grained logs are worthwhile feature.

Any comment please,

Thanks,

Quoted 37 lines

Quoted 2 lines

Just like with the X server, I don't believe that sepostgres should have its own module.

OK, I'll make next one as a patch for services/postgresql.*.

Quoted 4 lines

At first glance, there appears to be too many
attributes. I'm guessing that you're doing the same thing that is done with the *_unconfined() interfaces. We mainly do that to optimize size since unconfined brings in so many rules.

OK, I'll replace current interfaces by the following style's one.

interface(sepostgresql_unconfined',

        gen_require(`
                attribute sepostgresql_unconfined_type;
        ')
        typeattribute $1 sepostgresql_unconfined_type;

')

Quoted 1 line

I also see references to types and attributes that belong do the module.

Is it unlabel_t and system_r?
Where is the best place to associate them with my local policy?

Quoted 3 lines

Also the auditing
tunables seem unneeded; they seem to be more for debugging use. I think I can get a better handle on the policy with these revisions.

Hmm...
The reason why I added these tunables is that database folks told me that collecting logs in column/tuple level is an attractive feature, because native DBMS cannot provide fine-grained access control and cannot collect logs in these level.
Thus, I believe the feature to turn on/off auditing readily should be remained.

Thanks,

The attached patch provides security policies related to SE-PostgreSQL.

The followings are updates/unchanges from the previous version submitted
at two weeks ago. These updates replaced most of the part in the previous
one.

- The targets of this patch are moved to services/postgresql.*, although the previous one added new entries.

- Any interface got slim. They contains only one TYPEATTRIBUTE statement, and postgresql.te allows most of permissions to the associated attributes.

* Tunables to turn on/off audit are remained now, because database folks told me fine-grained logs are worthwhile feature.

+interface(sepgsql_unconfined_domain',

policy/modules/services/postgresql.te +8 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };

policy/modules/services/postgresql.te +5 -0

+# type transitions for rest of domains
+type_transition domain domain : db_database sepgsql_db_t;
+type_transition { domain - sepgsql_server_type } sepgsql_database_type : db_table sepgsql_table_t;
+type_transition { domain - sepgsql_server_type - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+type_transition domain sepgsql_database_type : db_blob sepgsql_blob_t;

policy/modules/services/postgresql.te +14 -0

+tunable_policy(`sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_database_type  : db_database all_db_database_perms;
+       auditallow domain sepgsql_table_type     : db_table all_db_table_perms;
+       auditallow domain sepgsql_table_type     : db_column all_db_column_perms;
+       auditallow domain sepgsql_procedure_type : db_procedure all_db_procedure_perms;
+       auditallow domain sepgsql_blob_type      : db_blob all_db_blob_perms;
+       auditallow domain sepgsql_server_type    : db_blob { import export };
+       auditallow domain sepgsql_module_type    : db_database { install_module };
+')
+tunable_policy(`sepgsql_enable_audittuple && sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_table_type     : db_tuple all_db_tuple_perms;
+')
+tunable_policy(`! sepgsql_enable_auditdeny',`
+       dontaudit domain sepgsql_database_type   : db_database all_db_database_perms;

Quoted 12 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

The followings are updates/unchanges from the previous version submitted
at two weeks ago. These updates replaced most of the part in the previous
one.

- The targets of this patch are moved to services/postgresql.*, although the previous one added new entries.

policy/modules/services/postgresql.te line 380

Quoted 10 lines

policy/modules/services/postgresql.te +9 -0

+tunable_policy(`sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_database_type  : db_database all_db_database_perms;
+       auditallow domain sepgsql_table_type     : db_table all_db_table_perms;
+       auditallow domain sepgsql_table_type     : db_column all_db_column_perms;
+       auditallow domain sepgsql_procedure_type : db_procedure all_db_procedure_perms;
+       auditallow domain sepgsql_blob_type      : db_blob all_db_blob_perms;
+       auditallow domain sepgsql_server_type    : db_blob { import export };
+       auditallow domain sepgsql_module_type    : db_database { install_module };
+')

Quoted 25 lines · Christopher J. PeBenito

Quoted 23 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

The followings are updates/unchanges from the previous version submitted
at two weeks ago. These updates replaced most of the part in the previous
one.

- The targets of this patch are moved to services/postgresql.*, although the previous one added new entries.

(quoted diff) +2 -0

+tunable_policy(`sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_database_type  : db_database 

all_db_database_perms;
+ auditallow domain sepgsql_table_type : db_table
all_db_table_perms;
+ auditallow domain sepgsql_table_type : db_column
all_db_column_perms;
+ auditallow domain sepgsql_procedure_type : db_procedure
all_db_procedure_perms;

Quoted 8 lines

Quoted 8 lines

+ auditallow domain sepgsql_blob_type : db_blob
all_db_blob_perms;
+ auditallow domain sepgsql_server_type : db_blob { import
export };
+ auditallow domain sepgsql_module_type : db_database {
install_module };
+')

A couple questions about the install_module and load_module permissions. First they seem here to be refering to sepgsql_module_type as the object which currently are lib_t and textrel_shlib_t, file types. So the object class of db_database seems to be inaccurate.

Also, after looking at the code I don't see why install_module and load_module need to be different permissions, granted they are a privileged operation but why not collapse them into a single access vector?

Also, why are blobs a separate object class? How is it a privileged operation to use blobs in a table? As far as reading and writing them they should be treated like any other column, shouldn't they?

And one more question. I see you have a type transition for sepgsql_proc_t but I never saw sepgsql_proc_t as the subject of any rules, which I don't understand. The hooks appear to always use the client_sid as the subject but for stored procedures to be useful they may need to access data that the client wouldn't be able to, or did I miss something?

Quoted 36 lines · Joshua Brindle

Quoted 33 lines · Christopher J. PeBenito

Quoted 31 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

The followings are updates/unchanges from the previous version submitted
at two weeks ago. These updates replaced most of the part in the previous
one.

- The targets of this patch are moved to services/postgresql.*, although the previous one added new entries.

(quoted diff) +2 -0

+tunable_policy(`sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_database_type  : db_database 

all_db_database_perms;
+ auditallow domain sepgsql_table_type : db_table
all_db_table_perms;
+ auditallow domain sepgsql_table_type : db_column
all_db_column_perms;
+ auditallow domain sepgsql_procedure_type : db_procedure
all_db_procedure_perms;
+ auditallow domain sepgsql_blob_type : db_blob
all_db_blob_perms;
+ auditallow domain sepgsql_server_type : db_blob { import
export };
+ auditallow domain sepgsql_module_type : db_database {
install_module };
+')

Quoted 1 line

A couple questions about the install_module and load_module permissions. First they seem here to be refering to sepgsql_module_type as the object which currently are lib_t and textrel_shlib_t, file types. So the object class of db_database seems to be inaccurate.

Is it appropriate to define a new permission in file class to associate a database with a library file?

Quoted 1 line

Also, after looking at the code I don't see why install_module and load_module need to be different permissions, granted they are a privileged operation but why not collapse them into a single access vector?

load_module is a permission to associate a database and a loadable module, like filesystem:associate permission.

When we tries to load a shared library module, the following permissins are required.

(Client) (Shared Library) : db_database install_module;
(Client) (Database) : db_database install_module;
(Database) (Shared Library) : db_database load_module;

install_module' defines a relationship between a client and database/library. load_module' defines a relationship between a database and library.

Quoted 1 line

Also, why are blobs a separate object class? How is it a privileged operation to use blobs in a table? As far as reading and writing them they should be treated like any other column, shouldn't they?

In MySQL, blob is one of the data types, and it can be stored in a table. However, blob is a set of tuples stored in pg_largeobject system catalog in PostgreSQL. To separate large binary object into small blocks improves ramdam access performance, but dameges to consistency in access control. It is the reason why SE-PostgreSQL need special care for blobs.

http://www.postgresql.org/docs/8.3/static/catalog-pg-largeobject.html

BTW, current PostgreSQL does not have any access controls mechanism in large object. :(

Quoted 1 line

And one more question. I see you have a type transition for sepgsql_proc_t but I never saw sepgsql_proc_t as the subject of any rules, which I don't understand. The hooks appear to always use the client_sid as the subject but for stored procedures to be useful they may need to access data that the client wouldn't be able to, or did I miss something?

When a sepgsql_client_domain invokes sepgsql_trusted_proc_t, the client_sid is transted into sepgsql_trusted_domain_t.
However, domain transition is kept in invokations for another procedure type. sepgsql_proc_t is always a object type, as postgresql_exex_t is always a file type, not a domain.

Quoted 12 lines

Quoted 1 line

Also, after looking at the code I don't see why install_module and load_module need to be different permissions, granted they are a privileged operation but why not collapse them into a single access vector?

load_module is a permission to associate a database and a loadable module, like filesystem:associate permission.

When we tries to load a shared library module, the following permissins are required.

(Client) (Shared Library) : db_database install_module;
(Client) (Database) : db_database install_module;
(Database) (Shared Library) : db_database load_module;

Quoted 3 lines

install_module' defines a relationship between a client and database/library. load_module' defines a relationship between a database and library.

I see, do you have an actual use case for load_module? I don't know that filesystem:associate has ever been used in a useful way, though I might just not know of such a use.

Quoted 8 lines

Quoted 1 line

And one more question. I see you have a type transition for sepgsql_proc_t but I never saw sepgsql_proc_t as the subject of any rules, which I don't understand. The hooks appear to always use the client_sid as the subject but for stored procedures to be useful they may need to access data that the client wouldn't be able to, or did I miss something?

When a sepgsql_client_domain invokes sepgsql_trusted_proc_t, the client_sid is transted into sepgsql_trusted_domain_t.
However, domain transition is kept in invokations for another procedure type. sepgsql_proc_t is always a object type, as postgresql_exex_t is always a file type, not a domain.

What if you call multiple procedures in a single call? Are the domain transition lifetimes limited to while the procedure is running? Are the other columns queried in the same query the original caller context?

e.g., if I did:

select fname, lname, get_ssn(ssn), dob, get_cr(cr);

and there were type_transitions for get_ssn and get_cr, how are the transitions handled?

Quoted 9 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

The followings are updates/unchanges from the previous version submitted
at two weeks ago. These updates replaced most of the part in the previous
one.

Quoted 2 lines

- The targets of this patch are moved to services/postgresql.*, although the previous one added new entries.

Interfaces must be renamed from sepgsql_* to postgresql_*

Quoted 3 lines

- Any interface got slim. They contains only one TYPEATTRIBUTE statement, and postgresql.te allows most of permissions to the associated attributes.

I'm not convinced that any of these are necessary except for the one for unconfined access.

Quoted 2 lines

* Tunables to turn on/off audit are remained now, because database folks told me fine-grained logs are worthwhile feature.

I'm still not very compelled by this, as I doubt people who do want more auditing will want to to enable it so coarsely.

Quoted 1 line

+interface(sepgsql_unconfined_domain',

This should be postgresql_unconfined().

policy/modules/services/postgresql.if line 177

Quoted 6 lines

policy/modules/services/postgresql.if +6 -0

+interface(`sepgsql_client_domain',`
+       gen_require(`
+               attribute sepgsql_client_type;
+       ')
+       typeattribute $1 sepgsql_client_type;
+')

The two existing connect interfaces (tcp and stream) should probably call this interface. If its regular postgresql, it won't hurt anything.

policy/modules/services/postgresql.te line 250

Quoted 4 lines

policy/modules/services/postgresql.te +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

policy/modules/services/postgresql.te line 257

Quoted 6 lines

policy/modules/services/postgresql.te +6 -0

+########################################
+#
+# SE-PostgreSQL Server Local policy
+#                    (sepgsql_server_type)
+
+sepgsql_server_domain(postgresql_t)

I don't see any other usage of this other than on postgresql_t, why is it needed?

Quoted 12 lines

policy/modules/services/postgresql.te +12 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };
+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };
+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;

policy/modules/services/postgresql.te line 294

Quoted 6 lines

policy/modules/services/postgresql.te +6 -0

+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

Quoted 5 lines

policy/modules/services/postgresql.te +5 -0

+# type transitions for rest of domains
+type_transition domain domain : db_database sepgsql_db_t;
+type_transition { domain - sepgsql_server_type } sepgsql_database_type : db_table sepgsql_table_t;
+type_transition { domain - sepgsql_server_type - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+type_transition domain sepgsql_database_type : db_blob sepgsql_blob_t;

[...]

Quoted 14 lines

policy/modules/services/postgresql.te +14 -0

+tunable_policy(`sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_database_type  : db_database all_db_database_perms;
+       auditallow domain sepgsql_table_type     : db_table all_db_table_perms;
+       auditallow domain sepgsql_table_type     : db_column all_db_column_perms;
+       auditallow domain sepgsql_procedure_type : db_procedure all_db_procedure_perms;
+       auditallow domain sepgsql_blob_type      : db_blob all_db_blob_perms;
+       auditallow domain sepgsql_server_type    : db_blob { import export };
+       auditallow domain sepgsql_module_type    : db_database { install_module };
+')
+tunable_policy(`sepgsql_enable_audittuple && sepgsql_enable_auditallow',`
+       auditallow domain sepgsql_table_type     : db_tuple all_db_tuple_perms;
+')
+tunable_policy(`! sepgsql_enable_auditdeny',`
+       dontaudit domain sepgsql_database_type   : db_database all_db_database_perms;

policy/modules/services/postgresql.te line 395

Quoted 10 lines

policy/modules/services/postgresql.te +10 -0

+       dontaudit domain sepgsql_table_type      : db_table all_db_table_perms;
+       dontaudit domain sepgsql_table_type      : db_column all_db_column_perms;
+       dontaudit domain sepgsql_procedure_type  : db_procedure all_db_procedure_perms;
+       dontaudit domain sepgsql_blob_type       : db_blob all_db_blob_perms;
+       dontaudit domain sepgsql_server_type     : db_blob { import export };
+       dontaudit domain sepgsql_module_type     : db_database { install_module };
+')
+tunable_policy(`! sepgsql_enable_audittuple || ! sepgsql_enable_auditdeny',`
+       dontaudit domain sepgsql_table_type      : db_tuple all_db_tuple_perms;
+')

Usage of domain here is not permitted. Why does everything

type_transition to sepgsql_table_t, etc? It makes it impossible to type_transition to something else. With the current config, everything is the same type for each table, blob, etc. Thats fine for the base config, but when people add types for their tables, they won't be able to type_transition their tables to their type. It seems like several templates need to be created to handle this. E.g. we want to have support for module foo to have a foo_table_t and foo_db_procedure_t. The same can be said for columns and other relevant objects.

Quoted 2 lines

The two existing connect interfaces (tcp and stream) should probably call this interface. If its regular postgresql, it won't hurt anything.

OK,

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

Quoted 6 lines

policy/modules/services/postgresql.te line 250

Quoted 4 lines

policy/modules/services/postgresql.te +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

Is it appropriate manner to deploy optional_policy at kernel/kernel.te?

Quoted 12 lines

Quoted 12 lines

policy/modules/services/postgresql.te +12 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };
+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };
+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;

Quoted 8 lines

policy/modules/services/postgresql.te line 294

Quoted 6 lines

policy/modules/services/postgresql.te +6 -0

+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

I intend that users can turn off this tunable during its operation phase after initial database setting up, to prevent applying unconfined accesses.

When sepgsql_enable_unconfined is disabled, sepgsql_unconfined_type works as if they are sepgsql_client_type, because sepgsql_unconfined_domain() interface associates a domain with sepgsql_(unconfined|client)_type.

Quoted 4 lines · Kohei KaiGai

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

[...]

Quoted 6 lines

Quoted 5 lines

policy/modules/services/postgresql.te line 250

Quoted 4 lines

policy/modules/services/postgresql.te +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

Is it appropriate manner to deploy optional_policy at kernel/kernel.te?

Why is this needed at all?

Quoted 22 lines

Quoted 11 lines

Quoted 11 lines

policy/modules/services/postgresql.te +11 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };
+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };

Quoted 8 lines

policy/modules/services/postgresql.te line 294

Quoted 7 lines

policy/modules/services/postgresql.te +7 -0

+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;
+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

I intend that users can turn off this tunable during its operation phase after initial database setting up, to prevent applying unconfined accesses.

Quoted 3 lines

When sepgsql_enable_unconfined is disabled, sepgsql_unconfined_type works as if they are sepgsql_client_type, because sepgsql_unconfined_domain() interface associates a domain with sepgsql_(unconfined|client)_type.

The problem is that this is inconsistent with the way other *_unconfined() access works.

Quoted 13 lines · Christopher J. PeBenito

Quoted 4 lines · Kohei KaiGai

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

[...]

Quoted 6 lines

Quoted 5 lines

policy/modules/services/postgresql.te line 250

Quoted 4 lines

policy/modules/services/postgresql.te +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

Is it appropriate manner to deploy optional_policy at kernel/kernel.te?

Quoted 1 line

Why is this needed at all?

Database objects have persistent security context, as filesystem doing. If their security contexts are invalidated by policy reloading etc, it is necessary them to be relabeled.

Above rules enables administrative domains to access and relabel these objects in this case.

Quoted 22 lines

Quoted 22 lines

Quoted 11 lines

Quoted 11 lines

policy/modules/services/postgresql.te +11 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };
+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };

Quoted 8 lines

policy/modules/services/postgresql.te line 294

Quoted 7 lines

policy/modules/services/postgresql.te +7 -0

+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;
+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

I intend that users can turn off this tunable during its operation phase after initial database setting up, to prevent applying unconfined accesses.

Quoted 6 lines

Quoted 3 lines

When sepgsql_enable_unconfined is disabled, sepgsql_unconfined_type works as if they are sepgsql_client_type, because sepgsql_unconfined_domain() interface associates a domain with sepgsql_(unconfined|client)_type.

The problem is that this is inconsistent with the way other *_unconfined() access works.

However, this feature to disclaim widespread permissions is worthwhile in database management system, because it is less frequently required in operation phase different from construction phase.
So, I think the default security policy should provide a way to restrict permissions for administrative domain.

If you concerned about its name is confusable with other *_unconfined() interfaces, sepgsql_enable_unconfined' can be renamed to sepgsql_enable_administrative' and ditto for the name of interface.

In the latest my patch, newly created tables are labeled as sepgsql_FOO_table_t when client does not belong to administrative domains. Because unconfined_t loses the grounds of its widespread permission when the boolean is disabled,

it works as
a generic domain. It also includes behavior changing in type_transition for tables.

Quoted 14 lines · KaiGai Kohei

Quoted 13 lines · Christopher J. PeBenito

Quoted 4 lines · Kohei KaiGai

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

[...]

Quoted 6 lines

Quoted 5 lines

policy/modules/services/postgresql.te line 250

Quoted 4 lines

policy/modules/services/postgresql.te +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

Is it appropriate manner to deploy optional_policy at kernel/kernel.te?

Why is this needed at all?

Quoted 6 lines

Database objects have persistent security context, as filesystem doing. If their security contexts are invalidated by policy reloading etc, it is necessary them to be relabeled.

Above rules enables administrative domains to access and relabel these objects in this case.

You need to add interfaces in the kernel module.

Quoted 33 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 8 lines

policy/modules/services/postgresql.te +8 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };

policy/modules/services/postgresql.te line 294

Quoted 10 lines

policy/modules/services/postgresql.te +10 -0

+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };
+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;
+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

Quoted 8 lines

Quoted 6 lines

I intend that users can turn off this tunable during its operation phase after initial database setting up, to prevent applying unconfined accesses.

When sepgsql_enable_unconfined is disabled, sepgsql_unconfined_type works as if they are sepgsql_client_type, because sepgsql_unconfined_domain() interface associates a domain with sepgsql_(unconfined|client)_type.

The problem is that this is inconsistent with the way other *_unconfined() access works.

However, this feature to disclaim widespread permissions is worthwhile in database management system, because it is less frequently required in operation phase different from construction phase.
So, I think the default security policy should provide a way to restrict permissions for administrative domain.

Quoted 3 lines

If you concerned about its name is confusable with other *_unconfined() interfaces, sepgsql_enable_unconfined' can be renamed to sepgsql_enable_administrative' and ditto for the name of interface.

It seems to make more sense to have the interfaces be unconditional, and then have the tunable at the call site.

Quoted 3 lines

In the latest my patch, newly created tables are labeled as sepgsql_FOO_table_t when client does not belong to administrative domains. Because unconfined_t loses the grounds of its widespread permission when the boolean is disabled,

unconfined_t is going to have to always have unconfined access.

Quoted 2 lines

it works as
a generic domain. It also includes behavior changing in type_transition for tables.

I'll have to re-review it, but I'm still uneasy about changing type_transitions.

Quoted 14 lines · Christopher J. PeBenito

Quoted 13 lines · KaiGai Kohei

Quoted 12 lines · Christopher J. PeBenito

Quoted 4 lines · Kohei KaiGai

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

[...]

Quoted 6 lines

Quoted 5 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

Is it appropriate manner to deploy optional_policy at kernel/kernel.te?

Quoted 8 lines

Quoted 7 lines

Quoted 1 line

Why is this needed at all?

Database objects have persistent security context, as filesystem doing. If their security contexts are invalidated by policy reloading etc, it is necessary them to be relabeled.

Above rules enables administrative domains to access and relabel these objects in this case.

You need to add interfaces in the kernel module.

Are you saying I should put new interfaces on kernel/kernel.if and use them in services/postgresql.te? Or inverse meaning?

Quoted 33 lines

Quoted 33 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 8 lines

(quoted diff) +8 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };

Review

Quoted 10 lines

(quoted diff) +10 -0

+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };
+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;
+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

Quoted 8 lines

Quoted 6 lines

I intend that users can turn off this tunable during its operation phase after initial database setting up, to prevent applying unconfined accesses.

When sepgsql_enable_unconfined is disabled, sepgsql_unconfined_type works as if they are sepgsql_client_type, because sepgsql_unconfined_domain() interface associates a domain with sepgsql_(unconfined|client)_type.

The problem is that this is inconsistent with the way other *_unconfined() access works.

However, this feature to disclaim widespread permissions is worthwhile in database management system, because it is less frequently required in operation phase different from construction phase.
So, I think the default security policy should provide a way to restrict permissions for administrative domain.

Quoted 5 lines

Quoted 3 lines

If you concerned about its name is confusable with other *_unconfined() interfaces, sepgsql_enable_unconfined' can be renamed to sepgsql_enable_administrative' and ditto for the name of interface.

It seems to make more sense to have the interfaces be unconditional, and then have the tunable at the call site.

Is it possible?
Currently, we cannot put TYPEATTRIBUTE statement in a tunable block.
If caller side put postgresql_unconfined() in a tunable block, we cannot build it well.

Quoted 4 lines

Quoted 3 lines

In the latest my patch, newly created tables are labeled as sepgsql_FOO_table_t when client does not belong to administrative domains. Because unconfined_t loses the grounds of its widespread permission when the boolean is disabled,

unconfined_t is going to have to always have unconfined access.

I can understand unconfined_t should work as its literal.

However, I'm worry about unconfined domain can invoke user defined functions with his capabilities, because it can contain malicious queries. In my current policy, it denies unconfined domains to invoke user defined functions directly. They have to confirm its harmless and to relabel it to sepgsql_proc_t.

It is a different issue from the tunable unconfined domain. However, I want you to understand allowing unconfined domains to invoke user defined functions directly is fundamentally risky. (Thus, I don't allow unconfined domains to invoke sepgsql_FOO_proc_t.)

Quoted 4 lines

Quoted 2 lines

it works as
a generic domain. It also includes behavior changing in type_transition for tables.

I'll have to re-review it, but I'm still uneasy about changing type_transitions.

I think the default type of database objects should be common, not a local type like sepgsql_FOO_table_t. When it works as a DBA, a newly created table should be labled as sepgsql_table_t, even if unconfined_t has its local sepgsql_unconfined_table_t. Thus, type_transition also need to be tunable, if unconfined domain is tunable.

Thanks,

Quoted 12 lines · KaiGai Kohei

Quoted 11 lines · Christopher J. PeBenito

Quoted 4 lines · Kohei KaiGai

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides security policies related to SE-PostgreSQL.

[...]

Quoted 5 lines

Quoted 5 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

+typeattribute unlabeled_t      sepgsql_database_type;
+typeattribute unlabeled_t      sepgsql_table_type;
+typeattribute unlabeled_t      sepgsql_procedure_type;
+typeattribute unlabeled_t      sepgsql_blob_type;

Usage of unlabeled_t here is not permitted.

Quoted 8 lines

Quoted 2 lines

Quoted 1 line

Is it appropriate manner to deploy optional_policy at kernel/kernel.te?

Why is this needed at all?

Database objects have persistent security context, as filesystem doing. If their security contexts are invalidated by policy reloading etc, it is necessary them to be relabeled.

Above rules enables administrative domains to access and relabel these objects in this case.

You need to add interfaces in the kernel module.

Quoted 33 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 8 lines

(quoted diff) +8 -0

+########################################
+#
+# SE-PostgreSQL Administrative domain local policy
+#                    (sepgsql_unconfined_type)
+
+tunable_policy(`sepgsql_enable_unconfined',`
+       allow sepgsql_unconfined_type sepgsql_database_type : db_database *;
+       allow sepgsql_unconfined_type sepgsql_module_type : db_database { install_module };

Review

Quoted 10 lines

(quoted diff) +10 -0

+       allow sepgsql_unconfined_type sepgsql_table_type : { db_table db_column db_tuple } *;
+       allow sepgsql_unconfined_type { sepgsql_procedure_type - sepgsql_user_proc_t } : db_procedure *;
+       allow sepgsql_unconfined_type sepgsql_user_proc_t : db_procedure { create drop getattr setattr relabelfrom relabelto };
+       allow sepgsql_unconfined_type sepgsql_blob_type : db_blob *;
+       allow sepgsql_unconfined_type postgresql_t : db_blob { import export };
+
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+',`
+       type_transition { sepgsql_unconfined_type - sepgsql_server_type } sepgsql_database_type : db_procedure sepgsql_user_proc_t;
+')

Why is this tunable? Why is there a different type_transition behavior?

Quoted 8 lines

Quoted 6 lines

I intend that users can turn off this tunable during its operation phase after initial database setting up, to prevent applying unconfined accesses.

When sepgsql_enable_unconfined is disabled, sepgsql_unconfined_type works as if they are sepgsql_client_type, because sepgsql_unconfined_domain() interface associates a domain with sepgsql_(unconfined|client)_type.

The problem is that this is inconsistent with the way other *_unconfined() access works.

However, this feature to disclaim widespread permissions is worthwhile in database management system, because it is less frequently required in operation phase different from construction phase.
So, I think the default security policy should provide a way to restrict permissions for administrative domain.

Quoted 3 lines

If you concerned about its name is confusable with other *_unconfined() interfaces, sepgsql_enable_unconfined' can be renamed to sepgsql_enable_administrative' and ditto for the name of interface.

It seems to make more sense to have the interfaces be unconditional, and then have the tunable at the call site.

Quoted 3 lines

In the latest my patch, newly created tables are labeled as sepgsql_FOO_table_t when client does not belong to administrative domains. Because unconfined_t loses the grounds of its widespread permission when the boolean is disabled,

unconfined_t is going to have to always have unconfined access.

Quoted 2 lines

it works as
a generic domain. It also includes behavior changing in type_transition for tables.

I'll have to re-review it, but I'm still uneasy about changing type_transitions.

The attached patch provides revised SE-PostgreSQL policy.

Updates from the previous version:
o sepgsql_enable_unconfined was removed.
o conditional type_transition was removed.

However, the following policies are unchanged, because I'm not sure what is your opinion.
- In kernel/kernel.te, interfaces declared in services/postgresql.if are invoked.
- Unconfined domains cannot invoke user defined functions due to security reason.

In the discussion about conditional type_transiton, I mentioned about a new boolean "sepgsql_unified_type" to turn on/off per-domain types like sepgsql_user_table_t, it is not included in this patch yet.

Please review this one.
Thanks,

Index: refpolicy-sepgsql/policy/modules/kernel/kernel.te
===================================================================

policy/modules/kernel/kernel.te (working copy) renamed from policy/modules/kernel/kernel.te (revision 2639) +0 -0

@@ -358,6 +358,17 @@
 

Index: refpolicy-sepgsql/policy/modules/services/postgresql.if
===================================================================

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +54 -0

@@ -120,3 +120,228 @@
         # Some versions of postgresql put the sock file in /tmp
        allow $1 postgresql_tmp_t:sock_file write;
 ')
+
+#######################################
+## <summary>
+##      The userdomain template for the SE-PostgreSQL.
+## </summary>
+## <desc>
+##      This template creates a delivered types which are used
+##     for given userdomains.
+## </desc>
+## <param name="userdomain_prefix">
+##      <summary>
+##      The prefix of the user domain (e.g., user
+##      is the prefix for user_t).
+##      </summary>
+## </param>
+#
+template(`postgresql_userdom_template',`
+       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_unconfined_type;
+               attribute sepgsql_userdom_type;
+
+               attribute sepgsql_database_type;
+               type sepgsql_trusted_domain_t;
+               type sepgsql_sysobj_t;
+
+               bool sepgsql_enable_users_ddl;
+       ')
+
+       ########################################
+       #
+       # Declarations
+       #
+
+       typeattribute $1_t sepgsql_client_type;
+       typeattribute $1_t sepgsql_userdom_type;
+
+       type sepgsql_$1_table_t;
+       postgresql_table_object(sepgsql_$1_table_t)
+
+       type sepgsql_$1_sysobj_t;
+       postgresql_system_table_object(sepgsql_$1_sysobj_t)
+
+       type sepgsql_$1_proc_t;
+       postgresql_procedure_object(sepgsql_$1_proc_t)
+
+       type sepgsql_$1_blob_t;

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +8 -0

+       tunable_policy(`sepgsql_enable_users_ddl',`
+               allow $1_t sepgsql_$1_table_t  : db_table { create drop };
+               allow $1_t sepgsql_$1_table_t  : db_column { create drop };
+               allow $1_t sepgsql_$1_sysobj_t : db_tuple { update insert delete };
+       ')
+
+       allow $1_t sepgsql_$1_table_t  : db_table  { getattr setattr use select update insert delete };
+       allow $1_t sepgsql_$1_table_t  : db_column { getattr setattr use select update insert };

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +50 -0

@@ -166,3 +166,178 @@
 optional_policy(`
        udev_read_db(postgresql_t)
 ')
+
+#################################
+#
+# SE-PostgreSQL Boolean declarations
+#
+
+## <desc>
+## <p>
+## Allow unprived users to execute DDL statement
+## </p>
+## </desc>
+gen_tunable(sepgsql_enable_users_ddl, true)
+
+#################################
+#
+# SE-PostgreSQL Type/Attribute declarations
+#
+
+# database subjects
+attribute sepgsql_client_type;
+attribute sepgsql_unconfined_type;
+attribute sepgsql_userdom_type;
+
+# database objects attribute
+attribute sepgsql_database_type;
+attribute sepgsql_table_type;
+attribute sepgsql_sysobj_table_type;
+attribute sepgsql_procedure_type;
+attribute sepgsql_blob_type;
+attribute sepgsql_module_type;
+
+# database trusted domain
+type sepgsql_trusted_domain_t;
+
+# database object types
+type sepgsql_db_t;
+postgresql_database_object(sepgsql_db_t)
+
+type sepgsql_table_t;
+postgresql_table_object(sepgsql_table_t)
+type sepgsql_sysobj_t;
+postgresql_system_table_object(sepgsql_sysobj_t)
+type sepgsql_secret_table_t;
+postgresql_table_object(sepgsql_secret_table_t)
+type sepgsql_ro_table_t;
+postgresql_table_object(sepgsql_ro_table_t)
+type sepgsql_fixed_table_t;
+postgresql_table_object(sepgsql_fixed_table_t)
+
+type sepgsql_proc_t;

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +35 -0

+########################################
+#
+# SE-PostgreSQL unpriv-Client domain local policy
+#                    (sepgsql_client_type)
+
+allow sepgsql_client_type sepgsql_db_t : db_database { getattr access get_param set_param};
+
+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 };
+
+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_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_secret_table_t : db_table { getattr };
+allow sepgsql_client_type sepgsql_secret_table_t : db_column { getattr };
+
+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_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_proc_t : db_procedure { getattr execute };
+allow sepgsql_client_type sepgsql_trusted_proc_t : db_procedure { getattr execute entrypoint };
+

Quoted 27 lines · Kohei KaiGai

The attached patch provides revised SE-PostgreSQL policy.

Updates from the previous version:
o sepgsql_enable_unconfined was removed.
o conditional type_transition was removed.

However, the following policies are unchanged, because I'm not sure what is your opinion.
- In kernel/kernel.te, interfaces declared in services/postgresql.if are invoked.
- Unconfined domains cannot invoke user defined functions due to security reason.

In the discussion about conditional type_transiton, I mentioned about a new boolean "sepgsql_unified_type" to turn on/off per-domain types like sepgsql_user_table_t, it is not included in this patch yet.

Please review this one.
Thanks,

Index: refpolicy-sepgsql/policy/modules/kernel/kernel.te
===================================================================

policy/modules/kernel/kernel.te (working copy) renamed from policy/modules/kernel/kernel.te (revision 2639) +0 -0

@@ -358,6 +358,17 @@
 

policy/modules/kernel/kernel.te (working copy) line 368

Quoted 10 lines

policy/modules/kernel/kernel.te (working copy) renamed from policy/modules/kernel/kernel.te (revision 2639) +8 -0

 ########################################
 #
+# Unlabeled database objects
+#
+optional_policy(`
+       postgresql_database_object(unlabeled_t)
+       postgresql_table_object(unlabeled_t)
+       postgresql_procedure_object(unlabeled_t)
+       postgresql_blob_object(unlabeled_t)
+')

I think interfaces should be added to kernel.if to allow the appropriate access. It seems that the database would have some access to the objects, and then an admin would be able to relabel from unlabeled_t for db_database, db_table, etc.

for example:

interface(kernel_relabelfrom_unlabeled_table',

	gen_require(`
		type unlabeled_t;
		class db_table relabelfrom;
	')

	allow $1 unlabeled_t:db_table relabelfrom;

')

Quoted 17 lines

Index: refpolicy-sepgsql/policy/modules/services/postgresql.if
===================================================================

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +9 -0

@@ -120,3 +120,228 @@
         # Some versions of postgresql put the sock file in /tmp
        allow $1 postgresql_tmp_t:sock_file write;
 ')
+
+#######################################
+## <summary>
+##      The userdomain template for the SE-PostgreSQL.
+## </summary>
+## <desc>
+##      This template creates a delivered types which are used
+##     for given userdomains.
+## </desc>

policy/modules/services/postgresql.if (working copy) line 139

Quoted 8 lines

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +8 -0

+## <param name="userdomain_prefix">
+##      <summary>
+##      The prefix of the user domain (e.g., user
+##      is the prefix for user_t).
+##      </summary>
+## </param>
+#
+template(`postgresql_userdom_template',`

policy/modules/services/postgresql.if (working copy) line 147

Quoted 8 lines

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +8 -0

+       ##############################
+       #
+       # Client local policy
+       #
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_table     sepgsql_$1_table_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_$1_proc_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_blob      sepgsql_$1_blob_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_sysobj_t      : db_tuple     sepgsql_$1_sysobj_t;

This should probably transition even if its unconfined. If a user starts out unconfined and then the admin later decides the user should be confined, the user will lose access to its object, right?

Quoted 13 lines

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +13 -0

+       tunable_policy(`sepgsql_enable_users_ddl',`
+               allow $1_t sepgsql_$1_table_t  : db_table { create drop };
+               allow $1_t sepgsql_$1_table_t  : db_column { create drop };
+               allow $1_t sepgsql_$1_sysobj_t : db_tuple { update insert delete };
+       ')
+
+       allow $1_t sepgsql_$1_table_t  : db_table  { getattr setattr use select update insert delete };
+       allow $1_t sepgsql_$1_table_t  : db_column { getattr setattr use select update insert };
+       allow $1_t sepgsql_$1_table_t  : db_tuple  { use select update insert delete };
+       allow $1_t sepgsql_$1_sysobj_t : db_tuple  { use select };
+
+       allow $1_t sepgsql_$1_proc_t : db_procedure { create drop getattr setattr execute };
+

policy/modules/services/postgresql.if (working copy) line 165

Quoted 5 lines

policy/modules/services/postgresql.if (working copy) renamed from policy/modules/services/postgresql.if (revision 2639) +5 -0

+       allow $1_t sepgsql_$1_blob_t : db_blob { create drop getattr setattr read write };
+
+       # Trusted Procedure
+       role $1_r types sepgsql_trusted_domain_t;
+')

Seems that this should have 3 parameters, just like per-role templates. Then $1_t becomes $2 and $1_r becomes $3.

Quoted 20 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +14 -0

@@ -166,3 +166,178 @@
 optional_policy(`
        udev_read_db(postgresql_t)
 ')
+
+#################################
+#
+# SE-PostgreSQL Boolean declarations
+#
+
+## <desc>
+## <p>
+## Allow unprived users to execute DDL statement
+## </p>
+## </desc>
+gen_tunable(sepgsql_enable_users_ddl, true)
+
+#################################

policy/modules/services/postgresql.te (working copy) line 190

Quoted 8 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +8 -0

+#
+# SE-PostgreSQL Type/Attribute declarations
+#
+
+# database subjects
+attribute sepgsql_client_type;
+attribute sepgsql_unconfined_type;
+attribute sepgsql_userdom_type;

policy/modules/services/postgresql.te (working copy) line 194

Quoted 4 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +4 -0

+type sepgsql_ro_blob_t;
+postgresql_blob_object(sepgsql_ro_blob_t)
+type sepgsql_secret_blob_t;
+postgresql_blob_object(sepgsql_secret_blob_t)

The declarations should be moved up with the other declarations in this file.

policy/modules/services/postgresql.te (working copy) line 200

Quoted 6 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +6 -0

+########################################
+#
+# SE-PostgreSQL unpriv-Client domain local policy
+#                    (sepgsql_client_type)
+
+allow sepgsql_client_type sepgsql_db_t : db_database { getattr access get_param set_param};

policy/modules/services/postgresql.te (working copy) line 206

Quoted 6 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +6 -0

+# call trusted procedure
+type_transition sepgsql_client_type sepgsql_trusted_proc_t : process sepgsql_trusted_domain_t;
+allow sepgsql_client_type sepgsql_trusted_domain_t : process { transition };
+
+# type transitions for rest of domains
+type_transition sepgsql_client_type postgresql_t : db_database sepgsql_db_t;

Seems like this type_transition should go in the above sepgsql_enable_users_ddl tunable.

policy/modules/services/postgresql.te (working copy) line 209

Quoted 3 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +3 -0

+type_transition { sepgsql_client_type - sepgsql_unconfined_type - sepgsql_userdom_type } sepgsql_database_type : db_table sepgsql_table_t;
+type_transition { sepgsql_client_type - sepgsql_unconfined_type - sepgsql_userdom_type } sepgsql_database_type : db_procedure sepgsql_proc_t;
+type_transition { sepgsql_client_type - sepgsql_unconfined_type - sepgsql_userdom_type } sepgsql_database_type : db_blob sepgsql_blob_t;

Is the negation here to prevent type_transition conflicts/duplicates?

It seems that if the user template is instantiated, then it should already have all the access that a client might have. I'm still thinking about it, but we might want to just drop the type transition out of the unconfined section and just require that something that is unconfined should be either a client or userdom too, to make the the type_transitions are correct.

This whole section should probably just go into postgresql_client() and then the attribute could be dropped.

Quoted 4 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +4 -0

+########################################
+#
+# SE-PostgreSQL Misc policies
+#

policy/modules/services/postgresql.te (working copy) line 218

Quoted 5 lines

policy/modules/services/postgresql.te (working copy) renamed from policy/modules/services/postgresql.te (revision 2639) +5 -0

+
+# Trusted Procedure Domain
+domain_type(sepgsql_trusted_domain_t)
+postgresql_unconfined(sepgsql_trusted_domain_t)
+role system_r types sepgsql_trusted_domain_t;

This declaration should go with the others. sepgsql_trusted_proc_t seems like a better type name.

Quoted 6 lines

It seems that if the user template is instantiated, then it should already have all the access that a client might have. I'm still thinking about it, but we might want to just drop the type transition out of the unconfined section and just require that something that is unconfined should be either a client or userdom too, to make the the type_transitions are correct.

In this policy, sepgsql_client_type is also given minimum set of permissions

policy/modules/services/postgresql.if +8 -0

+interface(`postgresql_unconfined',`
+       gen_require(`
+               attribute sepgsql_unconfined_type;
+               attribute sepgsql_client_type;
+       ')
+       typeattribute $1 sepgsql_unconfined_type;
+       typeattribute $1 sepgsql_client_type;
+')

It is a relic when unconfined domain is conditional, unnecessary now. It does not need to invoke trusted procedure when unconfined domain is persistent, and unconfined domain will not need to be within userdom because its does not create objects with any user prefix.

Quoted 2 lines

This whole section should probably just go into postgresql_client() and then the attribute could be dropped.

However, I want remain sepgsql_client_type to mark domains as a client of SE-PostgreSQL, with separating from minimum set of permissions. It enables to describe user defined policy easier.
(Like auditallow switch for debugging.)

Chris, Thanks for your reviewing.

Rest of comments are bellow.

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Kohei KaiGai

The attached patch provides revised SE-PostgreSQL policy.

+template(postgresql_userdom_template',

- snip -

Quoted 8 lines

Quoted 8 lines

policy/modules/services/postgresql.if +8 -0

+       ##############################
+       #
+       # Client local policy
+       #
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_table     sepgsql_$1_table_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_$1_proc_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_blob      sepgsql_$1_blob_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_sysobj_t      : db_tuple     sepgsql_$1_sysobj_t;

Quoted 3 lines

This should probably transition even if its unconfined. If a user starts out unconfined and then the admin later decides the user should be confined, the user will lose access to its object, right?

No. In this case, a new confined user can access to its object if it was not explicitly relabeled.
The default type of db_table class created by unconfined users is sepgsql_table_t. Any confined users can also access to them with restricted permissions.

Quoted 18 lines · KaiGai Kohei

Chris, Thanks for your reviewing.

Rest of comments are bellow.

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Kohei KaiGai

The attached patch provides revised SE-PostgreSQL policy.

+template(postgresql_userdom_template',

- snip -

Quoted 8 lines

Quoted 8 lines

policy/modules/services/postgresql.if +8 -0

+       ##############################
+       #
+       # Client local policy
+       #
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_table     sepgsql_$1_table_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_$1_proc_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_blob      sepgsql_$1_blob_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_sysobj_t      : db_tuple     sepgsql_$1_sysobj_t;

I missed this previously but I just realized that to be consistent with the rest of the policy the prefix should actually be a prefix, not infix. i.e. the types should be like $1_sepgsql_table_t not sepgsql_ $1_table_t.

Quoted 7 lines

Quoted 3 lines

This should probably transition even if its unconfined. If a user starts out unconfined and then the admin later decides the user should be confined, the user will lose access to its object, right?

No. In this case, a new confined user can access to its object if it was not explicitly relabeled.
The default type of db_table class created by unconfined users is sepgsql_table_t. Any confined users can also access to them with restricted permissions.

I finally realized what the problem with the type_transitions. You have many of them to set up the default type for tables, procedures, blobs, etc. Shouldn't the default labels just be settings in a config file? Then all of the complex type transitioning behavior isn't needed.

Quoted 20 lines · Christopher J. PeBenito

Quoted 18 lines · KaiGai Kohei

Chris, Thanks for your reviewing.

Rest of comments are bellow.

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Kohei KaiGai

The attached patch provides revised SE-PostgreSQL policy.

+template(postgresql_userdom_template',

- snip -

Quoted 8 lines

Quoted 8 lines

policy/modules/services/postgresql.if +8 -0

+       ##############################
+       #
+       # Client local policy
+       #
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_table     sepgsql_$1_table_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_$1_proc_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_blob      sepgsql_$1_blob_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_sysobj_t      : db_tuple     sepgsql_$1_sysobj_t;

Quoted 4 lines

I missed this previously but I just realized that to be consistent with the rest of the policy the prefix should actually be a prefix, not infix. i.e. the types should be like $1_sepgsql_table_t not sepgsql_ $1_table_t.

I want to keep "sepgsql_" as a prefix for types related to SE-PostgreSQL, because all of them have uniformed naming convention.
Can you consider the head of "sepgsql_" means its assumed object manager, and we are omitting it for most of types managed by kernel?
I feel that object manager identification should have higher priority than user domain prefix in naming convention.
In my sense, "kernel_user_home_t" is better than "user_kernel_home_t", if object manager identification is not omitted.

However, it is just a name. I don't oppose this strongly.

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

This should probably transition even if its unconfined. If a user starts out unconfined and then the admin later decides the user should be confined, the user will lose access to its object, right?

No. In this case, a new confined user can access to its object if it was not explicitly relabeled.
The default type of db_table class created by unconfined users is sepgsql_table_t. Any confined users can also access to them with restricted permissions.

Quoted 4 lines

I finally realized what the problem with the type_transitions. You have many of them to set up the default type for tables, procedures, blobs, etc. Shouldn't the default labels just be settings in a config file? Then all of the complex type transitioning behavior isn't needed.

I dislike thie option.
It can make harder to find out the cause of trouble came from labeling behavior, if end users put incorrect configuration. Especially, I don't want to require database folks additional configuration, because they are not SELinux specialist. It can be configured in the security policy enough simply, so the default behavior should be also described in.

Quoted 32 lines · KaiGai Kohei

Quoted 18 lines · Christopher J. PeBenito

Quoted 17 lines · KaiGai Kohei

Chris, Thanks for your reviewing.

Rest of comments are bellow.

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Kohei KaiGai

The attached patch provides revised SE-PostgreSQL policy. +template(postgresql_userdom_template',

- snip -

Quoted 8 lines

Quoted 8 lines

policy/modules/services/postgresql.if +8 -0

+       ##############################
+       #
+       # Client local policy
+       #
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_table     sepgsql_$1_table_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_procedure sepgsql_$1_proc_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_database_type : db_blob      sepgsql_$1_blob_t;
+       type_transition { $1_t - sepgsql_unconfined_type } sepgsql_sysobj_t      : db_tuple     sepgsql_$1_sysobj_t;

Quoted 4 lines

I missed this previously but I just realized that to be consistent with the rest of the policy the prefix should actually be a prefix, not infix. i.e. the types should be like $1_sepgsql_table_t not sepgsql_ $1_table_t.

I want to keep "sepgsql_" as a prefix for types related to SE-PostgreSQL, because all of them have uniformed naming convention.
Can you consider the head of "sepgsql_" means its assumed object manager, and we are omitting it for most of types managed by kernel?
I feel that object manager identification should have higher priority than user domain prefix in naming convention.
In my sense, "kernel_user_home_t" is better than "user_kernel_home_t", if object manager identification is not omitted.

Quoted 1 line

However, it is just a name. I don't oppose this strongly.

I think we want consistency across the policy in naming. Determining if it goes with a userspace object manager can be found based on what object classes have the label.

Quoted 11 lines

Quoted 11 lines

Quoted 7 lines

Quoted 3 lines

This should probably transition even if its unconfined. If a user starts out unconfined and then the admin later decides the user should be confined, the user will lose access to its object, right?

No. In this case, a new confined user can access to its object if it was not explicitly relabeled.
The default type of db_table class created by unconfined users is sepgsql_table_t. Any confined users can also access to them with restricted permissions.

I finally realized what the problem with the type_transitions. You have many of them to set up the default type for tables, procedures, blobs, etc. Shouldn't the default labels just be settings in a config file? Then all of the complex type transitioning behavior isn't needed.

Quoted 6 lines

I dislike thie option.
It can make harder to find out the cause of trouble came from labeling behavior, if end users put incorrect configuration. Especially, I don't want to require database folks additional configuration, because they are not SELinux specialist. It can be configured in the security policy enough simply, so the default behavior should be also described in.

I think I was a little unclear. I'm suggesting they go in a file like /etc/selinux/refpolicy/contexts/postgresql_contexts, not in a primary config file for postgresql.

Quoted 14 lines · Christopher J. PeBenito

Quoted 6 lines · KaiGai Kohei

Quoted 4 lines · Christopher J. PeBenito

I finally realized what the problem with the type_transitions. You have many of them to set up the default type for tables, procedures, blobs, etc. Shouldn't the default labels just be settings in a config file? Then all of the complex type transitioning behavior isn't needed.

Quoted 6 lines

I dislike thie option.
It can make harder to find out the cause of trouble came from labeling behavior, if end users put incorrect configuration. Especially, I don't want to require database folks additional configuration, because they are not SELinux specialist. It can be configured in the security policy enough simply, so the default behavior should be also described in.

Quoted 3 lines

I think I was a little unclear. I'm suggesting they go in a file like /etc/selinux/refpolicy/contexts/postgresql_contexts, not in a primary config file for postgresql.

Yes, I have same implementation image as you suggested.

However, I don't want to add this kind of stuff although it can be described within the security policy, because it provides us uncertainties on SE-PostgreSQL behavior. It shall make harder to find out the cause of trouble came from labeling matter as I said before.

Do you consider they are really complex type_transition rules now? They are not conditional, not set operations.

Quoted 2 lines

Do you consider they are really complex type_transition rules now? They are not conditional, not set operations.

Sounds like they are ok, but I'd have to see the policy to make sure.

Quoted 4 lines

Quoted 2 lines

Do you consider they are really complex type_transition rules now? They are not conditional, not set operations.

Sounds like they are ok, but I'd have to see the policy to make sure.

I'm sorry, I din't submit the latest one yet, although I gave assurance to update some points you pointed out.

The attached one is the latest one.
Please confirm this version.

Significant updates:
- kernel_relabelfrom_unlabeled_database() is added to kernel/kernel.if. It enables sepgsql_unconfined_type to relabel unlabaled_t to other types.
- Any types/attributes/booleans are declared at the head of services/postgresql.te.
- postgresql_userdom_template() requires tree arguments of prefix, domain and role.
- Naming convention is changed. When userdomain tries to create a new object, it is labeled as FOO_sepgsql_table_t, not sepgsql_FOO_table_t.
- The target of type_transition is unconditional.
If userdomain create a new objects, it is always labeled as FOO_sepgsql_xxx_t. If others create a new one, it is always labeled as sepgsql_xxx_t.
- A new attribute of sepgsql_unpriv_client_type provides baseline permissions to attached domain. It is necessary to avoid to deploy sepgsql_enable_users_ddl boolean within interfaces.
- The meanings of sepgsql_client_type is changed. It means a set of domains connectable to SE-PostgreSQL.

Quoted 9 lines · KaiGai Kohei

Quoted 3 lines

Quoted 2 lines

Do you consider they are really complex type_transition rules now? They are not conditional, not set operations.

Sounds like they are ok, but I'd have to see the policy to make sure.

I'm sorry, I din't submit the latest one yet, although I gave assurance to update some points you pointed out.

The attached one is the latest one.
Please confirm this version.

Quoted 7 lines

Significant updates:
- kernel_relabelfrom_unlabeled_database() is added to kernel/kernel.if. It enables sepgsql_unconfined_type to relabel unlabaled_t to other types.
- Any types/attributes/booleans are declared at the head of services/postgresql.te.
- postgresql_userdom_template() requires tree arguments of prefix, domain and role.
- Naming convention is changed. When userdomain tries to create a new object, it is labeled as FOO_sepgsql_table_t, not sepgsql_FOO_table_t.

Quoted 8 lines

- The target of type_transition is unconditional.
If userdomain create a new objects, it is always labeled as FOO_sepgsql_xxx_t. If others create a new one, it is always labeled as sepgsql_xxx_t.
- A new attribute of sepgsql_unpriv_client_type provides baseline permissions to attached domain. It is necessary to avoid to deploy sepgsql_enable_users_ddl boolean within interfaces.
- The meanings of sepgsql_client_type is changed. It means a set of domains connectable to SE-PostgreSQL.

I'd like to wrap this one up, so I spent some time revising the patch (attached). Its just about ready to merge. Is the neverallow really needed?

Also, I'd still strongly urge you to reconsider adding the postgresql_contexts file with the default object labels. I think this is the clearest example why:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;

What object is being transitioned on? Other type transitions are
clearer: a file being created in a directory or a message enqueued to a message queue. I won't block merging the policy over this, but I think the postgresql_contexts is the better method.

Quoted 6 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;

What object is being transitioned on? Other type transitions are
clearer: a file being created in a directory or a message enqueued to a message queue. I won't block merging the policy over this, but I think the postgresql_contexts is the better method.

This type transition rule means a new database is created on a database management system. A database management system can maintain several databases in same time, like several files are placed under a directory. An only difference between a directory and a database management system is whether it is a process, or not. So, I don't think it is unnatural method to decide a correct context of newly created database.

(sorry for the dupe KaiGai, but I got a delivery failure on the nsa addresses)

Quoted 16 lines

Quoted 6 lines

Quoted 6 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;

What object is being transitioned on? Other type transitions are
clearer: a file being created in a directory or a message enqueued to a message queue. I won't block merging the policy over this, but I think the postgresql_contexts is the better method.

Quoted 6 lines

This type transition rule means a new database is created on a database management system. A database management system can maintain several databases in same time, like several files are placed under a directory. An only difference between a directory and a database management system is whether it is a process, or not. So, I don't think it is unnatural method to decide a correct context of newly created database.

In properly speaking, I oppose to drop type_transition rule for a newly created database object, don't oppose the postgresql_contexts file. I noticed they are not exclusive options after a carefull consideration.

Quoted 5 lines

The biggest concern of dropping type_transition is that we cannot decide what security context should be attached for a new database when the postgresql_contexts is lost, if we completely depends on this file. We can help the situation, if we can decide it with type_transition rule when the file or proper entries are not found.

I'd say its not unreasonable to require that postgresql_contexts exists. If it doesn't, it could just create the databases unlabeled, or the services fails to start when its missing. I don't know which is the better answer, so I'll reference another object manager. Eamon, what do you do in the X server when the x_contexts file is incomplete or missing?

Quoted 5 lines

If you feel strange to use the context of server process as the target of the type_transition, using the root directory of database cluster is an alternative idea. (It is '/var/lib/sepgsql/data' in default.) Any database files are placed under the directory, like filed placed under a directory.

I think that this is much less desirable option than what we have right now. Database objects don't exist outside of postgresql since its a userspace object manager. The fact that they're stored as files in a directory isn't relevant from the database object's perspective.

Quoted 4 lines

Quoted 2 lines

* Tunables to turn on/off audit are remained now, because database folks told me fine-grained logs are worthwhile feature.

I'm still not very compelled by this, as I doubt people who do want more auditing will want to to enable it so coarsely.

Hmm...
OK, I'll remove these tunable, and add a documentation to collect fine-grained database access logs.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

* Tunables to turn on/off audit are remained now, because database folks told me fine-grained logs are worthwhile feature.

I'm still not very compelled by this, as I doubt people who do want more auditing will want to to enable it so coarsely.

Hmm...
OK, I'll remove these tunable, and add a documentation to collect fine-grained database access logs.

When we apply tuple-level access control, access denied logs of filtered tuples are noisy, and it gives adversed effect for performance. For example, if a table contains 1,000,000 tuples and half of them are labeled as ":s0:c0", unclassified users will look a flood of logs on every accesses.

At least, is it necessary to be controlable on tuples?

[kaigai@saba ~]$ runcon -l s0 psql postgres -q
postgres=# SELECT * FROM drink;

NOTICE:  SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_tuple name=relid:16482,oid:16490
NOTICE:  SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_tuple name=relid:16482,oid:16491
NOTICE:  SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_tuple name=relid:16482,oid:16492
 id | name  | price | alcohol
----+-------+-------+---------
  1 | water |   100 | f
  2 | coke  |   120 | f
  3 | juice |   130 | f

(3 rows)

Quoted 14 lines · Kohei KaiGai

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

* Tunables to turn on/off audit are remained now, because database folks told me fine-grained logs are worthwhile feature.

I'm still not very compelled by this, as I doubt people who do want more auditing will want to to enable it so coarsely.

Hmm...
OK, I'll remove these tunable, and add a documentation to collect fine-grained database access logs.

When we apply tuple-level access control, access denied logs of filtered tuples are noisy, and it gives adversed effect for performance. For example, if a table contains 1,000,000 tuples and half of them are labeled as ":s0:c0", unclassified users will look a flood of logs on every accesses.

At least, is it necessary to be controlable on tuples?

[...]

Quoted 11 lines

[kaigai@saba ~]$ runcon -l s0 psql postgres -q
postgres=# SELECT * FROM drink;

NOTICE:  SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_tuple name=relid:16482,oid:16490
NOTICE:  SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_tuple name=relid:16482,oid:16491
NOTICE:  SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_tuple name=relid:16482,oid:16492
 id | name  | price | alcohol
----+-------+-------+---------
  1 | water |   100 | f
  2 | coke  |   120 | f
  3 | juice |   130 | f

(3 rows)

I would just unconditionally dontaudit it.