RepoMirrors
/
selinux-refpolicy
mirror of https://github.com/SELinuxProject/refpolicy
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
selinux-refpolicy/policy/modules/services/postgresql.te

591 lines
22 KiB
Plaintext
Raw Normal View History

Bump module versions for release.
2012-07-25 18:33:06 +00:00
policy_module(postgresql, 1.15.0)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
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;
Add missing object class dependencies in postgresql.
2011-01-14 15:35:44 +00:00
class db_schema all_db_schema_perms;
class db_view all_db_view_perms;
class db_sequence all_db_sequence_perms;
class db_language all_db_language_perms;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
')
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
#################################
#
# Declarations
#
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
## <desc>
## <p>
## Allow unprived users to execute DDL statement
## </p>
## </desc>
gen_tunable(sepgsql_enable_users_ddl, true)
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
## <desc>
## <p>
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
## Allow transmit client label to foreign database
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
## </p>
## </desc>
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
gen_tunable(sepgsql_transmit_client_label, false)
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
## <desc>
## <p>
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
## Allow database admins to execute DML statement
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
## </p>
## </desc>
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
gen_tunable(sepgsql_unconfined_dbadm, true)
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
type postgresql_t;
type postgresql_exec_t;
trunk: massive whitespace cleanup from dominick grift.
2008-07-23 21:38:39 +00:00
init_daemon_domain(postgresql_t, postgresql_exec_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
type postgresql_db_t;
files_type(postgresql_db_t)
more fix
2005-10-24 18:40:24 +00:00
type postgresql_etc_t;
files_config_file(postgresql_etc_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
type postgresql_initrc_exec_t;
init_script_file(postgresql_initrc_exec_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
type postgresql_lock_t;
files_lock_file(postgresql_lock_t)
type postgresql_log_t;
logging_log_file(postgresql_log_t)
type postgresql_tmp_t;
files_tmp_file(postgresql_tmp_t)
type postgresql_var_run_t;
files_pid_file(postgresql_var_run_t)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
# database clients attribute
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
attribute sepgsql_admin_type;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
attribute sepgsql_client_type;
attribute sepgsql_unconfined_type;
# database objects attribute
attribute sepgsql_database_type;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
attribute sepgsql_schema_type;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
attribute sepgsql_table_type;
attribute sepgsql_sysobj_table_type;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
attribute sepgsql_sequence_type;
attribute sepgsql_view_type;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
attribute sepgsql_procedure_type;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
attribute sepgsql_trusted_procedure_type;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
attribute sepgsql_language_type;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
attribute sepgsql_blob_type;
attribute sepgsql_module_type;
# database object types
type sepgsql_blob_t;
postgresql_blob_object(sepgsql_blob_t)
type sepgsql_db_t;
postgresql_database_object(sepgsql_db_t)
type sepgsql_fixed_table_t;
postgresql_table_object(sepgsql_fixed_table_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type sepgsql_lang_t;
postgresql_language_object(sepgsql_lang_t)
type sepgsql_priv_lang_t;
postgresql_language_object(sepgsql_priv_lang_t)
se-postgresql update from kaigai - rework: Add a comment of "deprecated" for deprecated permissions. - bugfix: MCS policy did not constrain the following permissions. db_database:{getattr} db_table:{getattr lock} db_column:{getattr} db_procedure:{drop getattr setattr} db_blob:{getattr import export} - rework: db_table:{lock} is moved to reader side, because it makes impossible to refer read-only table with foreign-key constraint. (FK checks internally acquire explicit locks.) - bugfix: some of permissions in db_procedure class are allowed on sepgsql_trusted_proc_t, but it is a domain, not a procedure. It should allow them on sepgsql_trusted_proc_exec_t. I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid such kind of confusion, as Chris suggested before. - rework: we should not allow db_procedure:{install} on the sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted procedure implicitly. - bugfix: MLS policy dealt db_blob:{export} as writer-side permission, but it is required whrn the largeobject is refered. - bugfix: MLS policy didn't constrain the db_procedure class.
2009-05-07 12:35:32 +00:00
type sepgsql_proc_exec_t;
typealias sepgsql_proc_exec_t alias sepgsql_proc_t;
postgresql_procedure_object(sepgsql_proc_exec_t)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
type sepgsql_ro_blob_t;
postgresql_blob_object(sepgsql_ro_blob_t)
type sepgsql_ro_table_t;
postgresql_table_object(sepgsql_ro_table_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type sepgsql_safe_lang_t;
postgresql_language_object(sepgsql_safe_lang_t)
type sepgsql_schema_t;
postgresql_schema_object(sepgsql_schema_t)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
type sepgsql_secret_blob_t;
postgresql_blob_object(sepgsql_secret_blob_t)
type sepgsql_secret_table_t;
postgresql_table_object(sepgsql_secret_table_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type sepgsql_seq_t;
postgresql_sequence_object(sepgsql_seq_t)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
type sepgsql_sysobj_t;
postgresql_system_table_object(sepgsql_sysobj_t)
type sepgsql_table_t;
postgresql_table_object(sepgsql_table_t)
trunk: fix up stored procedure naming patch from kaigai.
2008-06-24 12:57:06 +00:00
type sepgsql_trusted_proc_exec_t;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
postgresql_trusted_procedure_object(sepgsql_trusted_proc_exec_t)
# Ranged Trusted Procedure Domain
type sepgsql_ranged_proc_t;
domain_type(sepgsql_ranged_proc_t)
role system_r types sepgsql_ranged_proc_t;
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
type sepgsql_ranged_proc_exec_t;
postgresql_trusted_procedure_object(sepgsql_ranged_proc_exec_t)
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
# Types for temporary objects
#
# XXX - All the temporary objects are eliminated at end of database session
# and invisible from other sessions, so it is unnecessary to restrict users
# operations on temporary object. For policy simplification, only one type
# is defined for temporary objects under the "pg_temp" schema.
type sepgsql_temp_object_t;
postgresql_table_object(sepgsql_temp_object_t)
postgresql_sequence_object(sepgsql_temp_object_t)
postgresql_view_object(sepgsql_temp_object_t)
postgresql_procedure_object(sepgsql_temp_object_t)
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
# Trusted Procedure Domain
type sepgsql_trusted_proc_t;
domain_type(sepgsql_trusted_proc_t)
postgresql_unconfined(sepgsql_trusted_proc_t)
role system_r types sepgsql_trusted_proc_t;
type sepgsql_view_t;
postgresql_view_object(sepgsql_view_t)
trunk: OK, the attached patch adds the following types for unprivileged clients. - unpriv_sepgsql_table_t - unpriv_sepgsql_sysobj_t - unpriv_sepgsql_proc_exec_t - unpriv_sepgsql_blob_t These types are the default for unprivileged and unprefixed domains, such as httpd_t and others. In addition, TYPE_TRANSITION rules are moved to outside of tunable of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the tunable because UBAC domains (user_t and so on) were allowed to create sepgsql_table_t, and its default was pointed to this type when sepgsql_enable_users_ddl is disabled. However, it has different meanings now, so the TYPE_TRANSITION rules should be unconditional. KaiGai Kohei
2009-05-21 11:28:14 +00:00
# Types for unprivileged client
type unpriv_sepgsql_blob_t;
postgresql_blob_object(unpriv_sepgsql_blob_t)
type unpriv_sepgsql_proc_exec_t;
postgresql_procedure_object(unpriv_sepgsql_proc_exec_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type unpriv_sepgsql_schema_t;
trunk: remove unnecessary semicolons after interface/template calls everywhere Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
2011-04-04 16:16:23 +00:00
postgresql_schema_object(unpriv_sepgsql_schema_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type unpriv_sepgsql_seq_t;
postgresql_sequence_object(unpriv_sepgsql_seq_t)
trunk: OK, the attached patch adds the following types for unprivileged clients. - unpriv_sepgsql_table_t - unpriv_sepgsql_sysobj_t - unpriv_sepgsql_proc_exec_t - unpriv_sepgsql_blob_t These types are the default for unprivileged and unprefixed domains, such as httpd_t and others. In addition, TYPE_TRANSITION rules are moved to outside of tunable of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the tunable because UBAC domains (user_t and so on) were allowed to create sepgsql_table_t, and its default was pointed to this type when sepgsql_enable_users_ddl is disabled. However, it has different meanings now, so the TYPE_TRANSITION rules should be unconditional. KaiGai Kohei
2009-05-21 11:28:14 +00:00
type unpriv_sepgsql_sysobj_t;
postgresql_system_table_object(unpriv_sepgsql_sysobj_t)
type unpriv_sepgsql_table_t;
postgresql_table_object(unpriv_sepgsql_table_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type unpriv_sepgsql_view_t;
postgresql_view_object(unpriv_sepgsql_view_t)
trunk: OK, the attached patch adds the following types for unprivileged clients. - unpriv_sepgsql_table_t - unpriv_sepgsql_sysobj_t - unpriv_sepgsql_proc_exec_t - unpriv_sepgsql_blob_t These types are the default for unprivileged and unprefixed domains, such as httpd_t and others. In addition, TYPE_TRANSITION rules are moved to outside of tunable of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the tunable because UBAC domains (user_t and so on) were allowed to create sepgsql_table_t, and its default was pointed to this type when sepgsql_enable_users_ddl is disabled. However, it has different meanings now, so the TYPE_TRANSITION rules should be unconditional. KaiGai Kohei
2009-05-21 11:28:14 +00:00
# Types for UBAC
trunk: merge UBAC.
2008-11-05 16:10:46 +00:00
type user_sepgsql_blob_t;
typealias user_sepgsql_blob_t alias { staff_sepgsql_blob_t sysadm_sepgsql_blob_t };
typealias user_sepgsql_blob_t alias { auditadm_sepgsql_blob_t secadm_sepgsql_blob_t };
postgresql_blob_object(user_sepgsql_blob_t)
type user_sepgsql_proc_exec_t;
typealias user_sepgsql_proc_exec_t alias { staff_sepgsql_proc_exec_t sysadm_sepgsql_proc_exec_t };
typealias user_sepgsql_proc_exec_t alias { auditadm_sepgsql_proc_exec_t secadm_sepgsql_proc_exec_t };
postgresql_procedure_object(user_sepgsql_proc_exec_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type user_sepgsql_schema_t;
typealias user_sepgsql_schema_t alias { staff_sepgsql_schema_t sysadm_sepgsql_schema_t };
typealias user_sepgsql_schema_t alias { auditadm_sepgsql_schema_t secadm_sepgsql_schema_t };
postgresql_schema_object(user_sepgsql_schema_t)
type user_sepgsql_seq_t;
typealias user_sepgsql_seq_t alias { staff_sepgsql_seq_t sysadm_sepgsql_seq_t };
typealias user_sepgsql_seq_t alias { auditadm_sepgsql_seq_t secadm_sepgsql_seq_t };
postgresql_sequence_object(user_sepgsql_seq_t)
trunk: merge UBAC.
2008-11-05 16:10:46 +00:00
type user_sepgsql_sysobj_t;
typealias user_sepgsql_sysobj_t alias { staff_sepgsql_sysobj_t sysadm_sepgsql_sysobj_t };
typealias user_sepgsql_sysobj_t alias { auditadm_sepgsql_sysobj_t secadm_sepgsql_sysobj_t };
postgresql_system_table_object(user_sepgsql_sysobj_t)
type user_sepgsql_table_t;
typealias user_sepgsql_table_t alias { staff_sepgsql_table_t sysadm_sepgsql_table_t };
typealias user_sepgsql_table_t alias { auditadm_sepgsql_table_t secadm_sepgsql_table_t };
postgresql_table_object(user_sepgsql_table_t)
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type user_sepgsql_view_t;
typealias user_sepgsql_view_t alias { staff_sepgsql_view_t sysadm_sepgsql_view_t };
typealias user_sepgsql_view_t alias { auditadm_sepgsql_view_t secadm_sepgsql_view_t };
postgresql_view_object(user_sepgsql_view_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
########################################
#
# postgresql Local policy
#
allow postgresql_t self:capability { kill dac_override dac_read_search chown fowner fsetid setuid setgid sys_nice sys_tty_config sys_admin };
most of patch from dan Mon, 15 May 2006 11:58:01 -0400
2006-05-17 14:50:31 +00:00
dontaudit postgresql_t self:capability { sys_tty_config sys_admin };
Added signal permissions to postgres so it can start
2005-10-24 17:28:17 +00:00
allow postgresql_t self:process signal_perms;
trunk: Enable open permission checks policy capability.
2008-10-16 16:09:20 +00:00
allow postgresql_t self:fifo_file rw_fifo_file_perms;
postgresql patch from Dan Walsh: "File context for /etc/sysconfig/pgsql and other bugs. Sends audit messages connect to posgresql_server port Reads its own process info" Moved signal interface for style.
2010-03-19 17:51:32 +00:00
allow postgresql_t self:file { getattr read };
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
allow postgresql_t self:sem create_sem_perms;
allow postgresql_t self:shm create_shm_perms;
allow postgresql_t self:tcp_socket create_stream_socket_perms;
allow postgresql_t self:udp_socket create_stream_socket_perms;
allow postgresql_t self:unix_dgram_socket create_socket_perms;
allow postgresql_t self:unix_stream_socket create_stream_socket_perms;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow postgresql_t self:netlink_selinux_socket create_socket_perms;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
tunable_policy(`sepgsql_transmit_client_label',`
allow postgresql_t self:process { setsockcreate };
')
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow postgresql_t sepgsql_database_type:db_database *;
allow postgresql_t sepgsql_module_type:db_database install_module;
# Database/Loadable module
allow sepgsql_database_type sepgsql_module_type:db_database load_module;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow postgresql_t {sepgsql_schema_type sepgsql_temp_object_t}:db_schema *;
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_schema_t;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition postgresql_t sepgsql_schema_type:db_table sepgsql_sysobj_t;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow postgresql_t sepgsql_sequence_type:db_sequence *;
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition postgresql_t sepgsql_schema_type:db_sequence sepgsql_seq_t;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow postgresql_t sepgsql_view_type:db_view *;
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition postgresql_t sepgsql_schema_type:db_view sepgsql_view_t;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow postgresql_t sepgsql_procedure_type:db_procedure *;
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition postgresql_t sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow postgresql_t sepgsql_blob_type:db_blob *;
type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
trunk: massive whitespace cleanup from dominick grift.
2008-07-23 21:38:39 +00:00
manage_dirs_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
manage_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
manage_lnk_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
manage_fifo_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
manage_sock_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
another round of renaming
2006-02-21 18:40:44 +00:00
files_var_lib_filetrans(postgresql_t, postgresql_db_t, { dir file lnk_file sock_file fifo_file })
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
merge policy patterns to trunk
2006-12-12 20:08:08 +00:00
allow postgresql_t postgresql_etc_t:dir list_dir_perms;
trunk: massive whitespace cleanup from dominick grift.
2008-07-23 21:38:39 +00:00
read_files_pattern(postgresql_t, postgresql_etc_t, postgresql_etc_t)
read_lnk_files_pattern(postgresql_t, postgresql_etc_t, postgresql_etc_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
allow postgresql_t postgresql_exec_t:lnk_file { getattr read };
can_exec(postgresql_t, postgresql_exec_t )
merge policy patterns to trunk
2006-12-12 20:08:08 +00:00
allow postgresql_t postgresql_lock_t:file manage_file_perms;
trunk: whitespace fixes
2009-06-26 14:40:13 +00:00
files_lock_filetrans(postgresql_t, postgresql_lock_t, file)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
trunk: massive whitespace cleanup from dominick grift.
2008-07-23 21:38:39 +00:00
manage_files_pattern(postgresql_t, postgresql_log_t, postgresql_log_t)
logging_log_filetrans(postgresql_t, postgresql_log_t, { file dir })
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
trunk: massive whitespace cleanup from dominick grift.
2008-07-23 21:38:39 +00:00
manage_dirs_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
manage_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
manage_lnk_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
manage_fifo_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
manage_sock_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
another round of renaming
2006-02-21 18:40:44 +00:00
files_tmp_filetrans(postgresql_t, postgresql_tmp_t, { dir file sock_file })
fs_tmpfs_filetrans(postgresql_t, postgresql_tmp_t, { dir file lnk_file sock_file fifo_file })
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
postgresql patch from Dan Walsh
2010-09-01 15:06:38 +00:00
manage_dirs_pattern(postgresql_t, postgresql_var_run_t, postgresql_var_run_t)
trunk: massive whitespace cleanup from dominick grift.
2008-07-23 21:38:39 +00:00
manage_files_pattern(postgresql_t, postgresql_var_run_t, postgresql_var_run_t)
manage_sock_files_pattern(postgresql_t, postgresql_var_run_t, postgresql_var_run_t)
postgresql patch from Dan Walsh
2010-09-01 15:06:38 +00:00
files_pid_filetrans(postgresql_t, postgresql_var_run_t, { dir file })
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
renaming from 20060131 interface review, round 2
2006-01-31 16:49:43 +00:00
kernel_read_kernel_sysctls(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
kernel_read_system_state(postgresql_t)
kernel_list_proc(postgresql_t)
renaming from 20060131 interface review, round 2
2006-01-31 16:49:43 +00:00
kernel_read_all_sysctls(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
kernel_read_proc_symlinks(postgresql_t)
trunk: Unified labeled networking policy from Paul Moore. The latest revision of the labeled policy patches which enable both labeled and unlabeled policy support for NetLabel. This revision takes into account Chris' feedback from the first version and reduces the number of interface calls in each domain down to two at present: one for unlabeled access, one for NetLabel access. The older, transport layer specific interfaces, are still present for use by third-party modules but are not used in the default policy modules. trunk: Use netmsg initial SID for MLS-only Netlabel packets, from Paul Moore. This patch changes the policy to use the netmsg initial SID as the "base" SID/context for NetLabel packets which only have MLS security attributes. Currently we use the unlabeled initial SID which makes it very difficult to distinquish between actual unlabeled packets and those packets which have MLS security attributes.
2007-06-27 15:23:21 +00:00
corenet_all_recvfrom_unlabeled(postgresql_t)
corenet_all_recvfrom_netlabel(postgresql_t)
trunk: change network interface access from all to generic network interfaces.
2009-01-06 20:24:10 +00:00
corenet_tcp_sendrecv_generic_if(postgresql_t)
corenet_udp_sendrecv_generic_if(postgresql_t)
trunk: Remove node definitions and change node usage to generic nodes.
2009-01-09 19:48:02 +00:00
corenet_tcp_sendrecv_generic_node(postgresql_t)
corenet_udp_sendrecv_generic_node(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
corenet_tcp_sendrecv_all_ports(postgresql_t)
corenet_udp_sendrecv_all_ports(postgresql_t)
postgresql patch from Dan Walsh: "File context for /etc/sysconfig/pgsql and other bugs. Sends audit messages connect to posgresql_server port Reads its own process info" Moved signal interface for style.
2010-03-19 17:51:32 +00:00
corenet_udp_bind_generic_node(postgresql_t)
trunk: Remove node definitions and change node usage to generic nodes.
2009-01-09 19:48:02 +00:00
corenet_tcp_bind_generic_node(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
corenet_tcp_bind_postgresql_port(postgresql_t)
corenet_tcp_connect_auth_port(postgresql_t)
postgresql patch from Dan Walsh: "File context for /etc/sysconfig/pgsql and other bugs. Sends audit messages connect to posgresql_server port Reads its own process info" Moved signal interface for style.
2010-03-19 17:51:32 +00:00
corenet_tcp_connect_postgresql_port(postgresql_t)
packets for services
2006-05-30 19:46:34 +00:00
corenet_sendrecv_postgresql_server_packets(postgresql_t)
corenet_sendrecv_auth_client_packets(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
dev_read_sysfs(postgresql_t)
dev_read_urand(postgresql_t)
fs_getattr_all_fs(postgresql_t)
fs_search_auto_mountpoints(postgresql_t)
trunk: 2 patches from dan.
2008-08-14 15:10:41 +00:00
fs_rw_hugetlbfs_files(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
selinux_get_enforce_mode(postgresql_t)
selinux_validate_context(postgresql_t)
selinux_compute_access_vector(postgresql_t)
selinux_compute_create_context(postgresql_t)
selinux_compute_relabel_context(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
term_use_controlling_term(postgresql_t)
corecmd_exec_bin(postgresql_t)
corecmd_exec_shell(postgresql_t)
another slew of renaming
2006-02-02 21:08:12 +00:00
domain_dontaudit_list_all_domains_state(postgresql_t)
another round of renaming
2006-02-20 21:33:25 +00:00
domain_use_interactive_fds(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
files_dontaudit_search_home(postgresql_t)
files_manage_etc_files(postgresql_t)
files_search_etc(postgresql_t)
files_read_etc_runtime_files(postgresql_t)
files_read_usr_files(postgresql_t)
postgresql patch from Dan Walsh: "File context for /etc/sysconfig/pgsql and other bugs. Sends audit messages connect to posgresql_server port Reads its own process info" Moved signal interface for style.
2010-03-19 17:51:32 +00:00
auth_use_pam(postgresql_t)
trunk: another round of nsswitch from dan.
2007-12-06 16:04:14 +00:00
Change initrc_var_run_t interface noun from script_pid to utmp for clarity.
2006-01-18 18:08:39 +00:00
init_read_utmp(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
logging_send_syslog_msg(postgresql_t)
postgresql patch from Dan Walsh: "File context for /etc/sysconfig/pgsql and other bugs. Sends audit messages connect to posgresql_server port Reads its own process info" Moved signal interface for style.
2010-03-19 17:51:32 +00:00
logging_send_audit_msgs(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
miscfiles_read_localization(postgresql_t)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
seutil_libselinux_linked(postgresql_t)
allow postgresql_t to read selabel files The attached patch allows postgresql_t domain to read selabel definition files (such as /etc/selinux/targeted/contexts/sepgsql_contexts). The upcoming version (v9.1) uses selabel_lookup(3) to assign initial security context of database objects, we need to allow this reference. Thanks, -- NEC Europe Ltd, SAP Global Competence Center KaiGai Kohei <kohei.kaigai@eu.nec.com>
2011-04-15 08:40:56 +00:00
seutil_read_default_contexts(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
another round of renaming
2006-02-20 21:33:25 +00:00
userdom_dontaudit_use_unpriv_user_fds(postgresql_t)
trunk: merge UBAC.
2008-11-05 16:10:46 +00:00
userdom_dontaudit_search_user_home_dirs(postgresql_t)
userdom_dontaudit_use_user_terminals(postgresql_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
Move modules to contrib submodule.
2011-09-09 14:10:03 +00:00
optional_policy(`
mta_getattr_spool(postgresql_t)
')
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
tunable_policy(`allow_execmem',`
allow postgresql_t self:process execmem;
')
deprecate module name as first parameter of optional_policy()
2006-03-24 16:13:54 +00:00
optional_policy(`
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
consoletype_exec(postgresql_t)
')
deprecate module name as first parameter of optional_policy()
2006-03-24 16:13:54 +00:00
optional_policy(`
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
cron_search_spool(postgresql_t)
trunk: whitespace fixes
2009-06-26 14:40:13 +00:00
cron_system_entry(postgresql_t, postgresql_exec_t)
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
')
deprecate module name as first parameter of optional_policy()
2006-03-24 16:13:54 +00:00
optional_policy(`
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
hostname_exec(postgresql_t)
')
trunk: More complete labeled networking infrastructure from KaiGai Kohei.
2007-11-26 16:44:57 +00:00
optional_policy(`
ipsec_match_default_spd(postgresql_t)
')
deprecate module name as first parameter of optional_policy()
2006-03-24 16:13:54 +00:00
optional_policy(`
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
kerberos_use(postgresql_t)
')
deprecate module name as first parameter of optional_policy()
2006-03-24 16:13:54 +00:00
optional_policy(`
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
seutil_sigchld_newrole(postgresql_t)
')
deprecate module name as first parameter of optional_policy()
2006-03-24 16:13:54 +00:00
optional_policy(`
final updates from nsa cvs
2005-09-19 21:17:45 +00:00
udev_read_db(postgresql_t)
')
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
########################################
#
# Ranged Trusted Procedure Domain
#
# XXX - the purpose of this domain is to switch security context of
# the database client using dynamic domain transition; typically,
# used for connection pooling software that shall assign a security
# context at beginning of the user session based on the credentials
# being invisible from unprivileged domains.
#
allow sepgsql_ranged_proc_t self:process setcurrent;
domain_dyntrans_type(sepgsql_ranged_proc_t)
mcs_process_set_categories(sepgsql_ranged_proc_t)
mls_process_set_level(sepgsql_ranged_proc_t)
postgresql_unconfined(sepgsql_ranged_proc_t)
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
########################################
#
# Rules common to all clients
#
allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_client_type sepgsql_schema_t:db_schema { getattr search };
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
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 };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
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 };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
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 };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr select lock };
allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr select };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_client_type sepgsql_seq_t:db_sequence { getattr get_value next_value };
allow sepgsql_client_type sepgsql_view_t:db_view { getattr expand };
se-postgresql update from kaigai - rework: Add a comment of "deprecated" for deprecated permissions. - bugfix: MCS policy did not constrain the following permissions. db_database:{getattr} db_table:{getattr lock} db_column:{getattr} db_procedure:{drop getattr setattr} db_blob:{getattr import export} - rework: db_table:{lock} is moved to reader side, because it makes impossible to refer read-only table with foreign-key constraint. (FK checks internally acquire explicit locks.) - bugfix: some of permissions in db_procedure class are allowed on sepgsql_trusted_proc_t, but it is a domain, not a procedure. It should allow them on sepgsql_trusted_proc_exec_t. I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid such kind of confusion, as Chris suggested before. - rework: we should not allow db_procedure:{install} on the sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted procedure implicitly. - bugfix: MLS policy dealt db_blob:{export} as writer-side permission, but it is required whrn the largeobject is refered. - bugfix: MLS policy didn't constrain the db_procedure class.
2009-05-07 12:35:32 +00:00
allow sepgsql_client_type sepgsql_proc_exec_t:db_procedure { getattr execute install };
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow sepgsql_client_type sepgsql_trusted_procedure_type:db_procedure { getattr execute entrypoint };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_client_type sepgsql_lang_t:db_language { getattr };
allow sepgsql_client_type sepgsql_safe_lang_t:db_language { getattr execute };
# Only DBA can implement SQL procedures using `unsafe' procedural languages.
# The `unsafe' one provides a capability to access internal data structure,
# so we don't allow user-defined function being implemented using `unsafe' one.
allow sepgsql_proc_exec_t sepgsql_lang_t:db_language { implement };
allow sepgsql_procedure_type sepgsql_safe_lang_t:db_language { implement };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow sepgsql_client_type sepgsql_blob_t:db_blob { create drop getattr setattr read write };
allow sepgsql_client_type sepgsql_ro_blob_t:db_blob { getattr read };
allow sepgsql_client_type sepgsql_secret_blob_t:db_blob getattr;
# The purpose of the dontaudit rule in row-level access control is to prevent a flood of logs.
# If a client tries to SELECT a table including violated tuples, these are filtered from
# the result set as if not exist, but its access denied longs can be recorded within log files.
# In generally, the number of tuples are much larger than the number of columns, tables and so on.
# So, it makes a flood of logs when many tuples are violated.
#
# The default policy does not prevent anything for sepgsql_client_type sepgsql_unconfined_type,
# so we don't need "dontaudit" rules in Type-Enforcement. However, MLS/MCS can prevent them
# to access classified tuples and can make a audit record.
#
# Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
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 };
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
# 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 };
Move one block in postgresql.
2011-01-14 15:13:12 +00:00
# Note that permission of creation/deletion are eventually controlled by
# create or drop permission of individual objects within shared schemas.
# So, it just allows to create/drop user specific types.
tunable_policy(`sepgsql_enable_users_ddl',`
allow sepgsql_client_type sepgsql_schema_t:db_schema { add_name remove_name };
')
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
########################################
#
# Rules common to administrator clients
#
allow sepgsql_admin_type sepgsql_database_type:db_database { create drop getattr setattr relabelfrom relabelto access };
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_admin_type sepgsql_schema_type:db_schema { create drop getattr setattr relabelfrom relabelto search add_name remove_name };
type_transition sepgsql_admin_type sepgsql_database_type:db_schema sepgsql_schema_t;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
type_transition sepgsql_admin_type sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
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 };
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow sepgsql_admin_type sepgsql_sysobj_table_type:db_tuple { relabelfrom relabelto use select update insert delete };
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type_transition sepgsql_admin_type sepgsql_schema_type:db_table sepgsql_table_t;
allow sepgsql_admin_type sepgsql_sequence_type:db_sequence { create drop getattr setattr relabelfrom relabelto get_value next_value set_value };
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition sepgsql_admin_type sepgsql_schema_type:db_sequence sepgsql_seq_t;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_admin_type sepgsql_view_type:db_view { create drop getattr setattr relabelfrom relabelto expand };
Type transition fix in Postgresql database objects from KaiGai Kohei.
2011-07-29 12:42:53 +00:00
type_transition sepgsql_admin_type sepgsql_schema_type:db_view sepgsql_view_t;
[BUGFIX] lack of type transition on dbadm domain (Re: dbadm.pp is not available in selinux-policy package) I found out a bug when we initialize the database with dbadm_r:dbadm_t which belongs to sepgsql_admin_type attribute. In the case when sepgsql_admin_type create a new database objects, it does not have valid type_transition rules. So, it was failed. Sorry, I didn't find out it for a long time. And db_procedure:{execute} on the sepgsql_proc_exec_t might be necessary for the administrative domain independently from sepgsql_unconfined_dbadm, because we need to execute some of system defined procedures to look up system tables.
2010-04-12 14:14:10 +00:00
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_procedure_type:db_procedure { create drop getattr relabelfrom relabelto };
[BUGFIX] lack of type transition on dbadm domain (Re: dbadm.pp is not available in selinux-policy package) I found out a bug when we initialize the database with dbadm_r:dbadm_t which belongs to sepgsql_admin_type attribute. In the case when sepgsql_admin_type create a new database objects, it does not have valid type_transition rules. So, it was failed. Sorry, I didn't find out it for a long time. And db_procedure:{execute} on the sepgsql_proc_exec_t might be necessary for the administrative domain independently from sepgsql_unconfined_dbadm, because we need to execute some of system defined procedures to look up system tables.
2010-04-12 14:14:10 +00:00
allow sepgsql_admin_type sepgsql_proc_exec_t:db_procedure execute;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type_transition sepgsql_admin_type sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
Rearrange lines in postgresql.
2012-05-18 18:18:00 +00:00
allow sepgsql_admin_type sepgsql_temp_object_t:{db_schema db_table db_column db_tuple db_sequence db_view db_procedure} ~{ relabelto relabelfrom };
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_admin_type sepgsql_language_type:db_language { create drop getattr setattr relabelfrom relabelto execute };
type_transition sepgsql_admin_type sepgsql_database_type:db_language sepgsql_lang_t;
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_blob_type:db_blob { create drop getattr setattr relabelfrom relabelto };
[BUGFIX] lack of type transition on dbadm domain (Re: dbadm.pp is not available in selinux-policy package) I found out a bug when we initialize the database with dbadm_r:dbadm_t which belongs to sepgsql_admin_type attribute. In the case when sepgsql_admin_type create a new database objects, it does not have valid type_transition rules. So, it was failed. Sorry, I didn't find out it for a long time. And db_procedure:{execute} on the sepgsql_proc_exec_t might be necessary for the administrative domain independently from sepgsql_unconfined_dbadm, because we need to execute some of system defined procedures to look up system tables.
2010-04-12 14:14:10 +00:00
type_transition sepgsql_admin_type sepgsql_database_type:db_blob sepgsql_blob_t;
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_module_type:db_database install_module;
kernel_relabelfrom_unlabeled_database(sepgsql_admin_type)
tunable_policy(`sepgsql_unconfined_dbadm',`
allow sepgsql_admin_type sepgsql_database_type:db_database *;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_admin_type sepgsql_schema_type:db_schema *;
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_table_type:{ db_table db_column db_tuple } *;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_admin_type sepgsql_sequence_type:db_sequence *;
allow sepgsql_admin_type sepgsql_view_type:db_view *;
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_proc_exec_t:db_procedure *;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow sepgsql_admin_type sepgsql_trusted_procedure_type:db_procedure ~install;
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_procedure_type:db_procedure ~{ execute install };
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_admin_type sepgsql_language_type:db_language ~implement;
Add dbadm, from KaiGai Kohei.
2010-02-08 15:34:08 +00:00
allow sepgsql_admin_type sepgsql_blob_type:db_blob *;
')
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
########################################
#
# Unconfined access to this module
#
allow sepgsql_unconfined_type sepgsql_database_type:db_database *;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow sepgsql_unconfined_type {sepgsql_schema_type sepgsql_temp_object_t}:db_schema *;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_schema_t;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
type_transition sepgsql_unconfined_type sepgsql_schema_type:db_table 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;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
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 } *;
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_unconfined_type sepgsql_sequence_type:db_sequence *;
allow sepgsql_unconfined_type sepgsql_view_type:db_view *;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
# unconfined domain is not allowed to invoke user defined procedure directly.
# They have to confirm and relabel it at first.
se-postgresql update from kaigai - rework: Add a comment of "deprecated" for deprecated permissions. - bugfix: MCS policy did not constrain the following permissions. db_database:{getattr} db_table:{getattr lock} db_column:{getattr} db_procedure:{drop getattr setattr} db_blob:{getattr import export} - rework: db_table:{lock} is moved to reader side, because it makes impossible to refer read-only table with foreign-key constraint. (FK checks internally acquire explicit locks.) - bugfix: some of permissions in db_procedure class are allowed on sepgsql_trusted_proc_t, but it is a domain, not a procedure. It should allow them on sepgsql_trusted_proc_exec_t. I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid such kind of confusion, as Chris suggested before. - rework: we should not allow db_procedure:{install} on the sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted procedure implicitly. - bugfix: MLS policy dealt db_blob:{export} as writer-side permission, but it is required whrn the largeobject is refered. - bugfix: MLS policy didn't constrain the db_procedure class.
2009-05-07 12:35:32 +00:00
allow sepgsql_unconfined_type sepgsql_proc_exec_t:db_procedure *;
SEPostgresql changes from Kohei KaiGai. * fix bugs in MLS/MCS * add connection pooling server support * foreign data wrapper support * Add temporary objects support * redefinition of use permission onto system objects
2012-05-18 13:28:18 +00:00
allow sepgsql_unconfined_type sepgsql_trusted_procedure_type:db_procedure ~install;
se-postgresql update from kaigai - rework: Add a comment of "deprecated" for deprecated permissions. - bugfix: MCS policy did not constrain the following permissions. db_database:{getattr} db_table:{getattr lock} db_column:{getattr} db_procedure:{drop getattr setattr} db_blob:{getattr import export} - rework: db_table:{lock} is moved to reader side, because it makes impossible to refer read-only table with foreign-key constraint. (FK checks internally acquire explicit locks.) - bugfix: some of permissions in db_procedure class are allowed on sepgsql_trusted_proc_t, but it is a domain, not a procedure. It should allow them on sepgsql_trusted_proc_exec_t. I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid such kind of confusion, as Chris suggested before. - rework: we should not allow db_procedure:{install} on the sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted procedure implicitly. - bugfix: MLS policy dealt db_blob:{export} as writer-side permission, but it is required whrn the largeobject is refered. - bugfix: MLS policy didn't constrain the db_procedure class.
2009-05-07 12:35:32 +00:00
allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure ~{ execute install };
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
New database object classes The attached patch adds a few database object classes, as follows: * db_schema ------------ A schema object performs as a namespace in database; similar to directories in filesystem. It seems some of (but not all) database objects are stored within a certain schema logically. We can qualify these objects using schema name. For example, a table: "my_tbl" within a schema: "my_scm" is identified by "my_scm.my_tbl". This table is completely different from "your_scm.my_tbl" that it a table within a schema: "your_scm". Its characteristics is similar to a directory in filesystem, so it has similar permissions. The 'search' controls to resolve object name within a schema. The 'add_name' and 'remove_name' controls to add/remove an object to/from a schema. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html In the past discussion, a rubix folks concerned about no object class definition for schema and catalog which is an upper level namespace. Since I'm not certain whether we have a disadvantage when 'db_schema' class is applied on catalog class, I don't add this definition yet. Default security context of 'db_table' and 'db_procedure' classes get being computed using type_transition with 'db_schema' class, instead of 'db_database' class. It reflects logical hierarchy of database object more correctly. * db_view ---------- A view object performs as a virtual table. We can run SELECT statement on views, although it has no physical entities. The definition of views are expanded in run-time, so it allows us to describe complex queries with keeping readability. This object class uniquely provides 'expand' permission that controls whether user can expand this view, or not. The default security context shall be computed by type transition rule with a schema object that owning the view. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createview.html * db_sequence -------------- A sequence object is a sequential number generator. This object class uniquely provides 'get_value', 'next_value' and 'set_value' permissions. The 'get_value' controls to reference the sequence object. The 'next_value' controls to fetch and increment the value of sequence object. The 'set_value' controls to set an arbitrary value. The default security context shall be computed by type transition rule with a schema object that owning the sequence. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html * db_language -------------- A language object is an installed engine to execute procedures. PostgreSQL supports to define SQL procedures using regular script languages; such as Perl, Tcl, not only SQL or binary modules. In addition, v9.0 or later supports DO statement. It allows us to execute a script statement on server side without defining a SQL procedure. It requires to control whether user can execute DO statement on this language, or not. This object class uniquely provides 'implement' and 'execute' permissions. The 'implement' controls whether a procedure can be implemented with this language, or not. So, it takes security context of the procedure as subject. The 'execute' controls to execute code block using DO statement. The default security context shall be computed by type transition rule with a database object, because it is not owned by a certain schema. In the default policy, we provide two types: 'sepgsql_lang_t' and 'sepgsql_safe_lang_t' that allows unpriv users to execute DO statement. The default is 'sepgsql_leng_t'. We assume newly installed language may be harm, so DBA has to relabel it explicitly, if he want user defined procedures using the language. See also, http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html http://developer.postgresql.org/pgdocs/postgres/sql-do.html P.S) I found a bug in MCS. It didn't constraint 'relabelfrom' permission of 'db_procedure' class. IIRC, I fixed it before, but it might be only MLS side. Sorry. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com> policy/flask/access_vectors | 29 ++++++++ policy/flask/security_classes | 6 ++ policy/mcs | 16 ++++- policy/mls | 58 ++++++++++++++- policy/modules/kernel/kernel.if | 8 ++ policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++-- policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++- 7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
allow sepgsql_unconfined_type sepgsql_language_type:db_language ~implement;
trunk: add sepostgresql policy from kaigai kohei.
2008-06-10 15:33:18 +00:00
allow sepgsql_unconfined_type sepgsql_blob_type:db_blob *;
allow sepgsql_unconfined_type sepgsql_module_type:db_database install_module;
kernel_relabelfrom_unlabeled_database(sepgsql_unconfined_type)