selinux-refpolicy/policy/modules/services/postgresql.if

598 lines
16 KiB
Plaintext
Raw Normal View History

2005-09-19 21:17:45 +00:00
## <summary>PostgreSQL relational database</summary>
#######################################
## <summary>
2008-12-03 19:16:20 +00:00
## Role access for SE-PostgreSQL.
## </summary>
2008-11-05 16:10:46 +00:00
## <param name="user_role">
2008-12-03 19:16:20 +00:00
## <summary>
## The role associated with the user domain.
## </summary>
## </param>
## <param name="user_domain">
## <summary>
2008-12-03 19:16:20 +00:00
## The type of the user domain.
## </summary>
## </param>
#
2008-11-05 16:10:46 +00:00
interface(`postgresql_role',`
gen_require(`
class db_database all_db_database_perms;
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
class db_schema all_db_schema_perms;
class db_table all_db_table_perms;
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
class db_sequence all_db_sequence_perms;
class db_view all_db_view_perms;
class db_procedure all_db_procedure_perms;
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
class db_language all_db_language_perms;
class db_column all_db_column_perms;
class db_tuple all_db_tuple_perms;
class db_blob all_db_blob_perms;
attribute sepgsql_client_type, sepgsql_database_type;
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, sepgsql_sysobj_table_type;
type sepgsql_trusted_proc_exec_t, sepgsql_trusted_proc_t;
type sepgsql_ranged_proc_exec_t, sepgsql_ranged_proc_t;
2008-11-05 16:10:46 +00:00
type user_sepgsql_blob_t, 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, user_sepgsql_seq_t;
2008-11-05 16:10:46 +00:00
type user_sepgsql_sysobj_t, 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;
type sepgsql_temp_object_t;
')
########################################
#
# Declarations
#
typeattribute $2 sepgsql_client_type;
2008-11-05 16:10:46 +00:00
role $1 types sepgsql_trusted_proc_t;
role $1 types sepgsql_ranged_proc_t;
##############################
#
# Client local policy
#
tunable_policy(`sepgsql_enable_users_ddl',`
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 $2 user_sepgsql_schema_t:db_schema { create drop setattr };
allow $2 user_sepgsql_table_t:db_table { create drop setattr };
allow $2 user_sepgsql_table_t:db_column { create drop setattr };
2008-11-05 16:10:46 +00:00
allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
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 $2 user_sepgsql_seq_t:db_sequence { create drop setattr set_value };
allow $2 user_sepgsql_view_t:db_view { create drop setattr };
allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop setattr };
')
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 $2 user_sepgsql_schema_t:db_schema { getattr search add_name remove_name };
type_transition $2 sepgsql_database_type:db_schema user_sepgsql_schema_t;
type_transition $2 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
allow $2 user_sepgsql_table_t:db_table { getattr select update insert delete lock };
allow $2 user_sepgsql_table_t:db_column { getattr select update insert };
allow $2 user_sepgsql_table_t:db_tuple { select update insert delete };
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 $2 sepgsql_schema_type:db_table user_sepgsql_table_t;
allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
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 $2 user_sepgsql_seq_t:db_sequence { getattr get_value next_value };
type_transition $2 sepgsql_schema_type:db_sequence user_sepgsql_seq_t;
allow $2 user_sepgsql_view_t:db_view { getattr expand };
type_transition $2 sepgsql_schema_type:db_view user_sepgsql_view_t;
allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr 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 $2 sepgsql_schema_type:db_procedure user_sepgsql_proc_exec_t;
allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
2008-11-05 16:10:46 +00:00
type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
allow $2 sepgsql_ranged_proc_t:process transition;
type_transition $2 sepgsql_ranged_proc_exec_t:process sepgsql_ranged_proc_t;
allow sepgsql_ranged_proc_t $2:process dyntransition;
2012-05-18 18:18:00 +00:00
allow $2 sepgsql_trusted_proc_t:process transition;
type_transition $2 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Marks as a SE-PostgreSQL loadable shared library module
## </summary>
## <param name="type">
2008-12-03 19:16:20 +00:00
## <summary>
## Type marked as a database object type.
## </summary>
## </param>
#
interface(`postgresql_loadable_module',`
gen_require(`
attribute sepgsql_module_type;
')
typeattribute $1 sepgsql_module_type;
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Marks as a SE-PostgreSQL database object type
## </summary>
## <param name="type">
2008-12-03 19:16:20 +00:00
## <summary>
## Type marked as a database object type.
## </summary>
## </param>
#
interface(`postgresql_database_object',`
gen_require(`
attribute sepgsql_database_type;
')
typeattribute $1 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
########################################
## <summary>
## Marks as a SE-PostgreSQL schema object type
## </summary>
## <param name="type">
## <summary>
## Type marked as a schema object type.
## </summary>
## </param>
#
interface(`postgresql_schema_object',`
gen_require(`
attribute sepgsql_schema_type;
')
typeattribute $1 sepgsql_schema_type;
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Marks as a SE-PostgreSQL table/column/tuple object type
## </summary>
## <param name="type">
2008-12-03 19:16:20 +00:00
## <summary>
## Type marked as a table/column/tuple object type.
## </summary>
## </param>
#
interface(`postgresql_table_object',`
gen_require(`
attribute sepgsql_table_type;
')
typeattribute $1 sepgsql_table_type;
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Marks as a SE-PostgreSQL system table/column/tuple object type
## </summary>
## <param name="type">
2008-12-03 19:16:20 +00:00
## <summary>
## Type marked as a table/column/tuple object type.
## </summary>
## </param>
#
interface(`postgresql_system_table_object',`
gen_require(`
attribute sepgsql_table_type, sepgsql_sysobj_table_type;
')
typeattribute $1 sepgsql_table_type;
typeattribute $1 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
########################################
## <summary>
## Marks as a SE-PostgreSQL sequence type
## </summary>
## <param name="type">
## <summary>
## Type marked as a sequence type.
## </summary>
## </param>
#
interface(`postgresql_sequence_object',`
gen_require(`
attribute sepgsql_sequence_type;
')
typeattribute $1 sepgsql_sequence_type;
')
########################################
## <summary>
## Marks as a SE-PostgreSQL view object type
## </summary>
## <param name="type">
## <summary>
## Type marked as a view object type.
## </summary>
## </param>
#
interface(`postgresql_view_object',`
gen_require(`
attribute sepgsql_view_type;
')
typeattribute $1 sepgsql_view_type;
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Marks as a SE-PostgreSQL procedure object type
## </summary>
## <param name="type">
2008-12-03 19:16:20 +00:00
## <summary>
## Type marked as a procedure object type.
2008-12-03 19:16:20 +00:00
## </summary>
## </param>
#
interface(`postgresql_procedure_object',`
gen_require(`
attribute sepgsql_procedure_type;
')
typeattribute $1 sepgsql_procedure_type;
')
########################################
## <summary>
## Marks as a SE-PostgreSQL trusted procedure object type
## </summary>
## <param name="type">
## <summary>
## Type marked as a trusted procedure object type.
## </summary>
## </param>
#
interface(`postgresql_trusted_procedure_object',`
gen_require(`
attribute sepgsql_procedure_type;
attribute sepgsql_trusted_procedure_type;
')
typeattribute $1 sepgsql_procedure_type;
typeattribute $1 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
########################################
## <summary>
## Marks as a SE-PostgreSQL procedural language object type
## </summary>
## <param name="type">
## <summary>
## Type marked as a procedural language object type.
## </summary>
## </param>
#
interface(`postgresql_language_object',`
gen_require(`
attribute sepgsql_language_type;
')
typeattribute $1 sepgsql_language_type;
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Marks as a SE-PostgreSQL binary large object type
## </summary>
## <param name="type">
2008-12-03 19:16:20 +00:00
## <summary>
## Type marked as a database binary large object type.
## </summary>
## </param>
#
interface(`postgresql_blob_object',`
gen_require(`
attribute sepgsql_blob_type;
')
typeattribute $1 sepgsql_blob_type;
')
2005-09-19 21:17:45 +00:00
########################################
## <summary>
## Allow the specified domain to search postgresql's database directory.
## </summary>
## <param name="domain">
## <summary>
2005-09-19 21:17:45 +00:00
## Domain allowed access.
## </summary>
2005-09-19 21:17:45 +00:00
## </param>
#
2006-02-02 21:08:12 +00:00
interface(`postgresql_search_db',`
2005-09-19 21:17:45 +00:00
gen_require(`
type postgresql_db_t;
')
allow $1 postgresql_db_t:dir search;
')
########################################
## <summary>
## Allow the specified domain to manage postgresql's database.
## </summary>
## <param name="domain">
## <summary>
2005-09-19 21:17:45 +00:00
## Domain allowed access.
## </summary>
2005-09-19 21:17:45 +00:00
## </param>
interface(`postgresql_manage_db',`
gen_require(`
type postgresql_db_t;
')
allow $1 postgresql_db_t:dir rw_dir_perms;
allow $1 postgresql_db_t:file rw_file_perms;
allow $1 postgresql_db_t:lnk_file { getattr read };
')
########################################
## <summary>
## Execute postgresql in the postgresql domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
2005-09-19 21:17:45 +00:00
## </param>
#
interface(`postgresql_domtrans',`
gen_require(`
type postgresql_t, postgresql_exec_t;
')
domtrans_pattern($1, postgresql_exec_t, postgresql_t)
2005-09-19 21:17:45 +00:00
')
######################################
## <summary>
## Allow domain to signal postgresql
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`postgresql_signal',`
gen_require(`
type postgresql_t;
')
allow $1 postgresql_t:process signal;
')
2005-09-19 21:17:45 +00:00
########################################
## <summary>
## Allow the specified domain to read postgresql's etc.
## </summary>
## <param name="domain">
## <summary>
2005-09-19 21:17:45 +00:00
## Domain allowed access.
## </summary>
2005-09-19 21:17:45 +00:00
## </param>
2006-09-06 22:07:25 +00:00
## <rolecap/>
2005-09-19 21:17:45 +00:00
#
interface(`postgresql_read_config',`
gen_require(`
type postgresql_etc_t;
')
files_search_etc($1)
2008-10-20 16:10:42 +00:00
allow $1 postgresql_etc_t:dir list_dir_perms;
allow $1 postgresql_etc_t:file read_file_perms;
allow $1 postgresql_etc_t:lnk_file read_lnk_file_perms;
2005-09-19 21:17:45 +00:00
')
########################################
## <summary>
## Allow the specified domain to connect to postgresql with a tcp socket.
2005-09-19 21:17:45 +00:00
## </summary>
## <param name="domain">
## <summary>
2005-09-19 21:17:45 +00:00
## Domain allowed access.
## </summary>
2005-09-19 21:17:45 +00:00
## </param>
#
interface(`postgresql_tcp_connect',`
gen_require(`
type postgresql_t;
')
corenet_tcp_recvfrom_labeled($1, postgresql_t)
corenet_tcp_sendrecv_postgresql_port($1)
corenet_tcp_connect_postgresql_port($1)
corenet_sendrecv_postgresql_client_packets($1)
2005-09-19 21:17:45 +00:00
')
########################################
## <summary>
## Allow the specified domain to connect to postgresql with a unix socket.
## </summary>
## <param name="domain">
## <summary>
2005-09-19 21:17:45 +00:00
## Domain allowed access.
## </summary>
2005-09-19 21:17:45 +00:00
## </param>
2006-09-06 22:07:25 +00:00
## <rolecap/>
2005-09-19 21:17:45 +00:00
#
2006-02-02 21:08:12 +00:00
interface(`postgresql_stream_connect',`
2005-09-19 21:17:45 +00:00
gen_require(`
type postgresql_t, postgresql_var_run_t, postgresql_tmp_t;
2005-09-19 21:17:45 +00:00
')
stream_connect_pattern($1, { postgresql_var_run_t postgresql_tmp_t }, { postgresql_var_run_t postgresql_tmp_t }, postgresql_t)
2005-09-19 21:17:45 +00:00
files_search_pids($1)
files_search_tmp($1)
2005-09-19 21:17:45 +00:00
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Allow the specified domain unprivileged accesses to unifined database objects
## managed by SE-PostgreSQL,
## </summary>
## <param name="domain">
2008-12-03 19:16:20 +00:00
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`postgresql_unpriv_client',`
gen_require(`
class db_database all_db_database_perms;
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
class db_schema all_db_schema_perms;
class db_table all_db_table_perms;
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
class db_sequence all_db_sequence_perms;
class db_view all_db_view_perms;
class db_procedure all_db_procedure_perms;
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
class db_language all_db_language_perms;
class db_column all_db_column_perms;
class db_tuple all_db_tuple_perms;
class db_blob all_db_blob_perms;
attribute sepgsql_client_type;
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_database_type, sepgsql_schema_type;
attribute sepgsql_sysobj_table_type;
type sepgsql_ranged_proc_t, sepgsql_ranged_proc_exec_t;
2012-05-18 18:18:00 +00:00
type sepgsql_temp_object_t;
type sepgsql_trusted_proc_t, sepgsql_trusted_proc_exec_t;
type unpriv_sepgsql_blob_t, 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, unpriv_sepgsql_seq_t;
type unpriv_sepgsql_sysobj_t, 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;
')
########################################
#
# Declarations
#
typeattribute $1 sepgsql_client_type;
########################################
#
# Client local policy
#
type_transition $1 sepgsql_ranged_proc_exec_t:process sepgsql_ranged_proc_t;
allow $1 sepgsql_ranged_proc_t:process transition;
allow sepgsql_ranged_proc_t $1:process dyntransition;
2012-05-18 18:18:00 +00:00
type_transition $1 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
allow $1 sepgsql_trusted_proc_t:process transition;
allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
type_transition $1 sepgsql_database_type:db_blob unpriv_sepgsql_blob_t;
allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr execute };
type_transition $1 sepgsql_schema_type:db_procedure 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
allow $1 unpriv_sepgsql_schema_t:db_schema { getattr add_name remove_name };
type_transition $1 sepgsql_database_type:db_schema unpriv_sepgsql_schema_t;
type_transition $1 sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
allow $1 unpriv_sepgsql_table_t:db_table { getattr select update insert delete lock };
allow $1 unpriv_sepgsql_table_t:db_column { getattr select update insert };
allow $1 unpriv_sepgsql_table_t:db_tuple { select update insert delete };
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 $1 sepgsql_schema_type:db_table unpriv_sepgsql_table_t;
allow $1 unpriv_sepgsql_seq_t:db_sequence { getattr get_value next_value set_value };
type_transition $1 sepgsql_schema_type:db_sequence unpriv_sepgsql_seq_t;
allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
type_transition $1 sepgsql_sysobj_table_type:db_tuple unpriv_sepgsql_sysobj_t;
2012-05-18 18:18:00 +00:00
allow $1 unpriv_sepgsql_view_t:db_view { getattr expand };
type_transition $1 sepgsql_schema_type:db_view unpriv_sepgsql_view_t;
2012-05-18 18:18:00 +00:00
tunable_policy(`sepgsql_enable_users_ddl',`
allow $1 unpriv_sepgsql_schema_t:db_schema { create drop setattr };
allow $1 unpriv_sepgsql_table_t:db_table { create drop setattr };
allow $1 unpriv_sepgsql_table_t:db_column { create drop setattr };
allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update insert delete };
allow $1 unpriv_sepgsql_seq_t:db_sequence { create drop setattr };
allow $1 unpriv_sepgsql_view_t:db_view { create drop setattr };
allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop setattr };
')
')
########################################
## <summary>
2008-12-03 19:16:20 +00:00
## Allow the specified domain unconfined accesses to any database objects
## managed by SE-PostgreSQL,
## </summary>
## <param name="domain">
2008-12-03 19:16:20 +00:00
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`postgresql_unconfined',`
gen_require(`
attribute sepgsql_unconfined_type;
')
typeattribute $1 sepgsql_unconfined_type;
')
2010-02-08 15:34:08 +00:00
########################################
## <summary>
## All of the rules required to administrate an postgresql environment
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
## <param name="role">
## <summary>
## The role to be allowed to manage the postgresql domain.
## </summary>
## </param>
## <rolecap/>
#
interface(`postgresql_admin',`
gen_require(`
attribute sepgsql_admin_type;
attribute sepgsql_client_type;
type postgresql_t, postgresql_var_run_t;
type postgresql_tmp_t, postgresql_db_t;
type postgresql_etc_t, postgresql_log_t;
type postgresql_initrc_exec_t;
')
typeattribute $1 sepgsql_admin_type;
allow $1 postgresql_t:process { ptrace signal_perms };
ps_process_pattern($1, postgresql_t)
init_labeled_script_domtrans($1, postgresql_initrc_exec_t)
domain_system_change_exemption($1)
role_transition $2 postgresql_initrc_exec_t system_r;
allow $2 system_r;
admin_pattern($1, postgresql_var_run_t)
admin_pattern($1, postgresql_db_t)
admin_pattern($1, postgresql_etc_t)
admin_pattern($1, postgresql_log_t)
admin_pattern($1, postgresql_tmp_t)
postgresql_tcp_connect($1)
postgresql_stream_connect($1)
')