2020-08-18 13:09:10 +00:00
|
|
|
policy_module(postgresql, 1.22.0)
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
gen_require(`
|
|
|
|
class db_database all_db_database_perms;
|
|
|
|
class db_table all_db_table_perms;
|
|
|
|
class db_procedure all_db_procedure_perms;
|
|
|
|
class db_column all_db_column_perms;
|
|
|
|
class db_tuple all_db_tuple_perms;
|
|
|
|
class db_blob all_db_blob_perms;
|
2011-01-14 15:35:44 +00:00
|
|
|
class db_schema all_db_schema_perms;
|
|
|
|
class db_view all_db_view_perms;
|
|
|
|
class db_sequence all_db_sequence_perms;
|
|
|
|
class db_language all_db_language_perms;
|
2008-06-10 15:33:18 +00:00
|
|
|
')
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
#################################
|
|
|
|
#
|
|
|
|
# Declarations
|
|
|
|
#
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
## <desc>
|
|
|
|
## <p>
|
|
|
|
## Allow unprived users to execute DDL statement
|
|
|
|
## </p>
|
|
|
|
## </desc>
|
2012-09-06 13:23:30 +00:00
|
|
|
gen_tunable(sepgsql_enable_users_ddl, false)
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2010-02-08 15:34:08 +00:00
|
|
|
## <desc>
|
|
|
|
## <p>
|
2012-05-18 18:18:00 +00:00
|
|
|
## Allow transmit client label to foreign database
|
2010-02-08 15:34:08 +00:00
|
|
|
## </p>
|
|
|
|
## </desc>
|
2012-05-18 18:18:00 +00:00
|
|
|
gen_tunable(sepgsql_transmit_client_label, false)
|
2010-02-08 15:34:08 +00:00
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
## <desc>
|
|
|
|
## <p>
|
2012-05-18 18:18:00 +00:00
|
|
|
## Allow database admins to execute DML statement
|
2012-05-18 13:28:18 +00:00
|
|
|
## </p>
|
|
|
|
## </desc>
|
2012-09-06 13:23:30 +00:00
|
|
|
gen_tunable(sepgsql_unconfined_dbadm, false)
|
2012-05-18 13:28:18 +00:00
|
|
|
|
2005-09-19 21:17:45 +00:00
|
|
|
type postgresql_t;
|
|
|
|
type postgresql_exec_t;
|
2008-07-23 21:38:39 +00:00
|
|
|
init_daemon_domain(postgresql_t, postgresql_exec_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
type postgresql_db_t;
|
|
|
|
files_type(postgresql_db_t)
|
|
|
|
|
2005-10-24 18:40:24 +00:00
|
|
|
type postgresql_etc_t;
|
|
|
|
files_config_file(postgresql_etc_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2010-02-08 15:34:08 +00:00
|
|
|
type postgresql_initrc_exec_t;
|
|
|
|
init_script_file(postgresql_initrc_exec_t)
|
|
|
|
|
2005-09-19 21:17:45 +00:00
|
|
|
type postgresql_lock_t;
|
|
|
|
files_lock_file(postgresql_lock_t)
|
|
|
|
|
|
|
|
type postgresql_log_t;
|
|
|
|
logging_log_file(postgresql_log_t)
|
|
|
|
|
2019-09-11 00:05:46 +00:00
|
|
|
type postgresql_runtime_t alias postgresql_var_run_t;
|
2020-06-27 21:11:48 +00:00
|
|
|
files_runtime_file(postgresql_runtime_t)
|
|
|
|
init_daemon_runtime_file(postgresql_runtime_t, dir, "postgresql")
|
2019-09-11 00:05:46 +00:00
|
|
|
|
2005-09-19 21:17:45 +00:00
|
|
|
type postgresql_tmp_t;
|
|
|
|
files_tmp_file(postgresql_tmp_t)
|
|
|
|
|
2015-10-20 18:33:56 +00:00
|
|
|
type postgresql_unit_t;
|
|
|
|
init_unit_file(postgresql_unit_t)
|
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
# database clients attribute
|
2010-02-08 15:34:08 +00:00
|
|
|
attribute sepgsql_admin_type;
|
2008-06-10 15:33:18 +00:00
|
|
|
attribute sepgsql_client_type;
|
|
|
|
attribute sepgsql_unconfined_type;
|
|
|
|
|
|
|
|
# database objects attribute
|
|
|
|
attribute sepgsql_database_type;
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
attribute sepgsql_schema_type;
|
2008-06-10 15:33:18 +00:00
|
|
|
attribute sepgsql_table_type;
|
|
|
|
attribute sepgsql_sysobj_table_type;
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
attribute sepgsql_sequence_type;
|
|
|
|
attribute sepgsql_view_type;
|
2008-06-10 15:33:18 +00:00
|
|
|
attribute sepgsql_procedure_type;
|
2012-05-18 13:28:18 +00:00
|
|
|
attribute sepgsql_trusted_procedure_type;
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
attribute sepgsql_language_type;
|
2008-06-10 15:33:18 +00:00
|
|
|
attribute sepgsql_blob_type;
|
|
|
|
attribute sepgsql_module_type;
|
|
|
|
|
|
|
|
# database object types
|
|
|
|
type sepgsql_blob_t;
|
|
|
|
postgresql_blob_object(sepgsql_blob_t)
|
|
|
|
|
|
|
|
type sepgsql_db_t;
|
|
|
|
postgresql_database_object(sepgsql_db_t)
|
|
|
|
|
|
|
|
type sepgsql_fixed_table_t;
|
|
|
|
postgresql_table_object(sepgsql_fixed_table_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type sepgsql_lang_t;
|
|
|
|
postgresql_language_object(sepgsql_lang_t)
|
|
|
|
|
|
|
|
type sepgsql_priv_lang_t;
|
|
|
|
postgresql_language_object(sepgsql_priv_lang_t)
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
type sepgsql_proc_exec_t;
|
|
|
|
postgresql_procedure_object(sepgsql_proc_exec_t)
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
type sepgsql_ro_blob_t;
|
|
|
|
postgresql_blob_object(sepgsql_ro_blob_t)
|
|
|
|
|
|
|
|
type sepgsql_ro_table_t;
|
|
|
|
postgresql_table_object(sepgsql_ro_table_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type sepgsql_safe_lang_t;
|
|
|
|
postgresql_language_object(sepgsql_safe_lang_t)
|
|
|
|
|
|
|
|
type sepgsql_schema_t;
|
|
|
|
postgresql_schema_object(sepgsql_schema_t)
|
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
type sepgsql_secret_blob_t;
|
|
|
|
postgresql_blob_object(sepgsql_secret_blob_t)
|
|
|
|
|
|
|
|
type sepgsql_secret_table_t;
|
|
|
|
postgresql_table_object(sepgsql_secret_table_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type sepgsql_seq_t;
|
|
|
|
postgresql_sequence_object(sepgsql_seq_t)
|
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
type sepgsql_sysobj_t;
|
|
|
|
postgresql_system_table_object(sepgsql_sysobj_t)
|
|
|
|
|
|
|
|
type sepgsql_table_t;
|
|
|
|
postgresql_table_object(sepgsql_table_t)
|
|
|
|
|
2008-06-24 12:57:06 +00:00
|
|
|
type sepgsql_trusted_proc_exec_t;
|
2012-05-18 13:28:18 +00:00
|
|
|
postgresql_trusted_procedure_object(sepgsql_trusted_proc_exec_t)
|
|
|
|
|
|
|
|
# Ranged Trusted Procedure Domain
|
|
|
|
type sepgsql_ranged_proc_t;
|
|
|
|
domain_type(sepgsql_ranged_proc_t)
|
|
|
|
role system_r types sepgsql_ranged_proc_t;
|
2012-05-18 18:18:00 +00:00
|
|
|
|
|
|
|
type sepgsql_ranged_proc_exec_t;
|
|
|
|
postgresql_trusted_procedure_object(sepgsql_ranged_proc_exec_t)
|
2012-05-18 13:28:18 +00:00
|
|
|
|
|
|
|
# Types for temporary objects
|
|
|
|
#
|
|
|
|
# XXX - All the temporary objects are eliminated at end of database session
|
|
|
|
# and invisible from other sessions, so it is unnecessary to restrict users
|
|
|
|
# operations on temporary object. For policy simplification, only one type
|
|
|
|
# is defined for temporary objects under the "pg_temp" schema.
|
|
|
|
type sepgsql_temp_object_t;
|
|
|
|
postgresql_table_object(sepgsql_temp_object_t)
|
|
|
|
postgresql_sequence_object(sepgsql_temp_object_t)
|
|
|
|
postgresql_view_object(sepgsql_temp_object_t)
|
|
|
|
postgresql_procedure_object(sepgsql_temp_object_t)
|
|
|
|
|
2012-05-18 18:18:00 +00:00
|
|
|
# Trusted Procedure Domain
|
|
|
|
type sepgsql_trusted_proc_t;
|
|
|
|
domain_type(sepgsql_trusted_proc_t)
|
|
|
|
postgresql_unconfined(sepgsql_trusted_proc_t)
|
|
|
|
role system_r types sepgsql_trusted_proc_t;
|
|
|
|
|
|
|
|
type sepgsql_view_t;
|
|
|
|
postgresql_view_object(sepgsql_view_t)
|
|
|
|
|
2009-05-21 11:28:14 +00:00
|
|
|
# Types for unprivileged client
|
|
|
|
type unpriv_sepgsql_blob_t;
|
|
|
|
postgresql_blob_object(unpriv_sepgsql_blob_t)
|
|
|
|
|
|
|
|
type unpriv_sepgsql_proc_exec_t;
|
|
|
|
postgresql_procedure_object(unpriv_sepgsql_proc_exec_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type unpriv_sepgsql_schema_t;
|
2011-04-04 16:16:23 +00:00
|
|
|
postgresql_schema_object(unpriv_sepgsql_schema_t)
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
|
|
|
type unpriv_sepgsql_seq_t;
|
|
|
|
postgresql_sequence_object(unpriv_sepgsql_seq_t)
|
|
|
|
|
2009-05-21 11:28:14 +00:00
|
|
|
type unpriv_sepgsql_sysobj_t;
|
|
|
|
postgresql_system_table_object(unpriv_sepgsql_sysobj_t)
|
|
|
|
|
|
|
|
type unpriv_sepgsql_table_t;
|
|
|
|
postgresql_table_object(unpriv_sepgsql_table_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type unpriv_sepgsql_view_t;
|
|
|
|
postgresql_view_object(unpriv_sepgsql_view_t)
|
|
|
|
|
2009-05-21 11:28:14 +00:00
|
|
|
# Types for UBAC
|
2008-11-05 16:10:46 +00:00
|
|
|
type user_sepgsql_blob_t;
|
|
|
|
postgresql_blob_object(user_sepgsql_blob_t)
|
|
|
|
|
|
|
|
type user_sepgsql_proc_exec_t;
|
|
|
|
postgresql_procedure_object(user_sepgsql_proc_exec_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type user_sepgsql_schema_t;
|
|
|
|
postgresql_schema_object(user_sepgsql_schema_t)
|
|
|
|
|
|
|
|
type user_sepgsql_seq_t;
|
|
|
|
postgresql_sequence_object(user_sepgsql_seq_t)
|
|
|
|
|
2008-11-05 16:10:46 +00:00
|
|
|
type user_sepgsql_sysobj_t;
|
|
|
|
postgresql_system_table_object(user_sepgsql_sysobj_t)
|
|
|
|
|
|
|
|
type user_sepgsql_table_t;
|
|
|
|
postgresql_table_object(user_sepgsql_table_t)
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type user_sepgsql_view_t;
|
|
|
|
postgresql_view_object(user_sepgsql_view_t)
|
|
|
|
|
2005-09-19 21:17:45 +00:00
|
|
|
########################################
|
|
|
|
#
|
|
|
|
# postgresql Local policy
|
|
|
|
#
|
2017-02-15 23:47:33 +00:00
|
|
|
allow postgresql_t self:capability { chown dac_override dac_read_search fowner fsetid kill setgid setuid sys_admin sys_nice sys_tty_config };
|
|
|
|
dontaudit postgresql_t self:capability { sys_admin sys_tty_config };
|
2005-10-24 17:28:17 +00:00
|
|
|
allow postgresql_t self:process signal_perms;
|
2008-10-16 16:09:20 +00:00
|
|
|
allow postgresql_t self:fifo_file rw_fifo_file_perms;
|
2020-08-14 14:33:08 +00:00
|
|
|
allow postgresql_t self:file read_inherited_file_perms;
|
2005-09-19 21:17:45 +00:00
|
|
|
allow postgresql_t self:sem create_sem_perms;
|
|
|
|
allow postgresql_t self:shm create_shm_perms;
|
|
|
|
allow postgresql_t self:tcp_socket create_stream_socket_perms;
|
|
|
|
allow postgresql_t self:udp_socket create_stream_socket_perms;
|
|
|
|
allow postgresql_t self:unix_dgram_socket create_socket_perms;
|
2012-12-17 09:42:43 +00:00
|
|
|
allow postgresql_t self:unix_stream_socket { create_stream_socket_perms connectto };
|
2008-06-10 15:33:18 +00:00
|
|
|
allow postgresql_t self:netlink_selinux_socket create_socket_perms;
|
2012-05-18 13:28:18 +00:00
|
|
|
tunable_policy(`sepgsql_transmit_client_label',`
|
|
|
|
allow postgresql_t self:process { setsockcreate };
|
|
|
|
')
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t sepgsql_database_type:db_database { create drop getattr setattr relabelfrom relabelto access install_module load_module get_param set_param };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
allow postgresql_t sepgsql_module_type:db_database install_module;
|
|
|
|
# Database/Loadable module
|
|
|
|
allow sepgsql_database_type sepgsql_module_type:db_database load_module;
|
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t {sepgsql_schema_type sepgsql_temp_object_t}:db_schema { create drop getattr setattr relabelfrom relabelto search add_name remove_name } ;
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_schema_t;
|
2012-05-18 13:28:18 +00:00
|
|
|
type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t sepgsql_table_type:db_table { create drop getattr setattr relabelfrom relabelto select update insert delete lock };
|
|
|
|
allow postgresql_t sepgsql_table_type:db_column { create drop getattr setattr relabelfrom relabelto select update insert };
|
|
|
|
allow postgresql_t sepgsql_table_type:db_tuple { relabelfrom relabelto use select update insert delete };
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition postgresql_t sepgsql_schema_type:db_table sepgsql_sysobj_t;
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t sepgsql_sequence_type:db_sequence { create drop getattr setattr relabelfrom relabelto get_value next_value set_value };
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition postgresql_t sepgsql_schema_type:db_sequence sepgsql_seq_t;
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t sepgsql_view_type:db_view { create drop getattr setattr relabelfrom relabelto expand };
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition postgresql_t sepgsql_schema_type:db_view sepgsql_view_t;
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto execute entrypoint install };
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition postgresql_t sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow postgresql_t sepgsql_blob_type:db_blob { create drop getattr setattr relabelfrom relabelto read write import export };
|
2008-06-10 15:33:18 +00:00
|
|
|
type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2008-07-23 21:38:39 +00:00
|
|
|
manage_dirs_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
|
|
|
|
manage_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
|
|
|
|
manage_lnk_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
|
|
|
|
manage_fifo_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
|
|
|
|
manage_sock_files_pattern(postgresql_t, postgresql_db_t, postgresql_db_t)
|
2006-02-21 18:40:44 +00:00
|
|
|
files_var_lib_filetrans(postgresql_t, postgresql_db_t, { dir file lnk_file sock_file fifo_file })
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2006-12-12 20:08:08 +00:00
|
|
|
allow postgresql_t postgresql_etc_t:dir list_dir_perms;
|
2008-07-23 21:38:39 +00:00
|
|
|
read_files_pattern(postgresql_t, postgresql_etc_t, postgresql_etc_t)
|
|
|
|
read_lnk_files_pattern(postgresql_t, postgresql_etc_t, postgresql_etc_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2020-08-14 14:33:08 +00:00
|
|
|
allow postgresql_t postgresql_exec_t:lnk_file read_lnk_file_perms;
|
2005-09-19 21:17:45 +00:00
|
|
|
can_exec(postgresql_t, postgresql_exec_t )
|
|
|
|
|
2006-12-12 20:08:08 +00:00
|
|
|
allow postgresql_t postgresql_lock_t:file manage_file_perms;
|
2009-06-26 14:40:13 +00:00
|
|
|
files_lock_filetrans(postgresql_t, postgresql_lock_t, file)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2008-07-23 21:38:39 +00:00
|
|
|
manage_files_pattern(postgresql_t, postgresql_log_t, postgresql_log_t)
|
|
|
|
logging_log_filetrans(postgresql_t, postgresql_log_t, { file dir })
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2019-01-23 15:00:25 +00:00
|
|
|
allow postgresql_t postgresql_tmp_t:file map;
|
2008-07-23 21:38:39 +00:00
|
|
|
manage_dirs_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
|
|
|
|
manage_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
|
|
|
|
manage_lnk_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
|
|
|
|
manage_fifo_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
|
|
|
|
manage_sock_files_pattern(postgresql_t, postgresql_tmp_t, postgresql_tmp_t)
|
2006-02-21 18:40:44 +00:00
|
|
|
files_tmp_filetrans(postgresql_t, postgresql_tmp_t, { dir file sock_file })
|
|
|
|
fs_tmpfs_filetrans(postgresql_t, postgresql_tmp_t, { dir file lnk_file sock_file fifo_file })
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2019-09-08 20:55:02 +00:00
|
|
|
manage_dirs_pattern(postgresql_t, postgresql_runtime_t, postgresql_runtime_t)
|
|
|
|
manage_files_pattern(postgresql_t, postgresql_runtime_t, postgresql_runtime_t)
|
|
|
|
manage_sock_files_pattern(postgresql_t, postgresql_runtime_t, postgresql_runtime_t)
|
2020-06-27 21:11:48 +00:00
|
|
|
files_runtime_filetrans(postgresql_t, postgresql_runtime_t, { dir file })
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2006-01-31 16:49:43 +00:00
|
|
|
kernel_read_kernel_sysctls(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
kernel_read_system_state(postgresql_t)
|
|
|
|
kernel_list_proc(postgresql_t)
|
2006-01-31 16:49:43 +00:00
|
|
|
kernel_read_all_sysctls(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
kernel_read_proc_symlinks(postgresql_t)
|
|
|
|
|
2007-06-27 15:23:21 +00:00
|
|
|
corenet_all_recvfrom_netlabel(postgresql_t)
|
2009-01-06 20:24:10 +00:00
|
|
|
corenet_tcp_sendrecv_generic_if(postgresql_t)
|
|
|
|
corenet_udp_sendrecv_generic_if(postgresql_t)
|
2009-01-09 19:48:02 +00:00
|
|
|
corenet_tcp_sendrecv_generic_node(postgresql_t)
|
|
|
|
corenet_udp_sendrecv_generic_node(postgresql_t)
|
2010-03-19 17:51:32 +00:00
|
|
|
corenet_udp_bind_generic_node(postgresql_t)
|
2009-01-09 19:48:02 +00:00
|
|
|
corenet_tcp_bind_generic_node(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
corenet_tcp_bind_postgresql_port(postgresql_t)
|
|
|
|
corenet_tcp_connect_auth_port(postgresql_t)
|
2010-03-19 17:51:32 +00:00
|
|
|
corenet_tcp_connect_postgresql_port(postgresql_t)
|
2006-05-30 19:46:34 +00:00
|
|
|
corenet_sendrecv_postgresql_server_packets(postgresql_t)
|
|
|
|
corenet_sendrecv_auth_client_packets(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
dev_read_sysfs(postgresql_t)
|
|
|
|
dev_read_urand(postgresql_t)
|
|
|
|
|
|
|
|
fs_getattr_all_fs(postgresql_t)
|
|
|
|
fs_search_auto_mountpoints(postgresql_t)
|
2019-01-26 18:50:12 +00:00
|
|
|
fs_mmap_rw_hugetlbfs_files(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
selinux_get_enforce_mode(postgresql_t)
|
|
|
|
selinux_validate_context(postgresql_t)
|
|
|
|
selinux_compute_access_vector(postgresql_t)
|
|
|
|
selinux_compute_create_context(postgresql_t)
|
|
|
|
selinux_compute_relabel_context(postgresql_t)
|
|
|
|
|
2005-09-19 21:17:45 +00:00
|
|
|
term_use_controlling_term(postgresql_t)
|
|
|
|
|
|
|
|
corecmd_exec_bin(postgresql_t)
|
|
|
|
corecmd_exec_shell(postgresql_t)
|
|
|
|
|
2006-02-02 21:08:12 +00:00
|
|
|
domain_dontaudit_list_all_domains_state(postgresql_t)
|
2006-02-20 21:33:25 +00:00
|
|
|
domain_use_interactive_fds(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
files_dontaudit_search_home(postgresql_t)
|
|
|
|
files_manage_etc_files(postgresql_t)
|
|
|
|
files_search_etc(postgresql_t)
|
|
|
|
files_read_etc_runtime_files(postgresql_t)
|
|
|
|
files_read_usr_files(postgresql_t)
|
|
|
|
|
2010-03-19 17:51:32 +00:00
|
|
|
auth_use_pam(postgresql_t)
|
2007-12-06 16:04:14 +00:00
|
|
|
|
2006-01-18 18:08:39 +00:00
|
|
|
init_read_utmp(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
logging_send_syslog_msg(postgresql_t)
|
2010-03-19 17:51:32 +00:00
|
|
|
logging_send_audit_msgs(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
miscfiles_read_localization(postgresql_t)
|
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
seutil_libselinux_linked(postgresql_t)
|
2011-04-15 08:40:56 +00:00
|
|
|
seutil_read_default_contexts(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2006-02-20 21:33:25 +00:00
|
|
|
userdom_dontaudit_use_unpriv_user_fds(postgresql_t)
|
2008-11-05 16:10:46 +00:00
|
|
|
userdom_dontaudit_search_user_home_dirs(postgresql_t)
|
|
|
|
userdom_dontaudit_use_user_terminals(postgresql_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
|
2011-09-09 14:10:03 +00:00
|
|
|
optional_policy(`
|
|
|
|
mta_getattr_spool(postgresql_t)
|
|
|
|
')
|
2005-09-19 21:17:45 +00:00
|
|
|
|
|
|
|
tunable_policy(`allow_execmem',`
|
|
|
|
allow postgresql_t self:process execmem;
|
|
|
|
')
|
|
|
|
|
2006-03-24 16:13:54 +00:00
|
|
|
optional_policy(`
|
2005-09-19 21:17:45 +00:00
|
|
|
consoletype_exec(postgresql_t)
|
|
|
|
')
|
|
|
|
|
2006-03-24 16:13:54 +00:00
|
|
|
optional_policy(`
|
2005-09-19 21:17:45 +00:00
|
|
|
cron_search_spool(postgresql_t)
|
2009-06-26 14:40:13 +00:00
|
|
|
cron_system_entry(postgresql_t, postgresql_exec_t)
|
2005-09-19 21:17:45 +00:00
|
|
|
')
|
|
|
|
|
2006-03-24 16:13:54 +00:00
|
|
|
optional_policy(`
|
2005-09-19 21:17:45 +00:00
|
|
|
hostname_exec(postgresql_t)
|
|
|
|
')
|
|
|
|
|
2007-11-26 16:44:57 +00:00
|
|
|
optional_policy(`
|
|
|
|
ipsec_match_default_spd(postgresql_t)
|
|
|
|
')
|
|
|
|
|
2006-03-24 16:13:54 +00:00
|
|
|
optional_policy(`
|
2005-09-19 21:17:45 +00:00
|
|
|
kerberos_use(postgresql_t)
|
|
|
|
')
|
|
|
|
|
2006-03-24 16:13:54 +00:00
|
|
|
optional_policy(`
|
2005-09-19 21:17:45 +00:00
|
|
|
seutil_sigchld_newrole(postgresql_t)
|
|
|
|
')
|
|
|
|
|
2006-03-24 16:13:54 +00:00
|
|
|
optional_policy(`
|
2005-09-19 21:17:45 +00:00
|
|
|
udev_read_db(postgresql_t)
|
|
|
|
')
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2012-05-18 18:18:00 +00:00
|
|
|
########################################
|
|
|
|
#
|
|
|
|
# Ranged Trusted Procedure Domain
|
|
|
|
#
|
|
|
|
# XXX - the purpose of this domain is to switch security context of
|
|
|
|
# the database client using dynamic domain transition; typically,
|
|
|
|
# used for connection pooling software that shall assign a security
|
|
|
|
# context at beginning of the user session based on the credentials
|
|
|
|
# being invisible from unprivileged domains.
|
|
|
|
#
|
|
|
|
allow sepgsql_ranged_proc_t self:process setcurrent;
|
|
|
|
|
|
|
|
domain_dyntrans_type(sepgsql_ranged_proc_t)
|
|
|
|
|
|
|
|
mcs_process_set_categories(sepgsql_ranged_proc_t)
|
|
|
|
|
|
|
|
mls_process_set_level(sepgsql_ranged_proc_t)
|
|
|
|
|
|
|
|
postgresql_unconfined(sepgsql_ranged_proc_t)
|
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
########################################
|
|
|
|
#
|
|
|
|
# Rules common to all clients
|
|
|
|
#
|
|
|
|
|
|
|
|
allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
|
|
|
|
type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
allow sepgsql_client_type sepgsql_schema_t:db_schema { getattr search };
|
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr select insert lock };
|
|
|
|
allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr select insert };
|
|
|
|
allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { select insert };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_table_t:db_table { getattr select update insert delete lock };
|
|
|
|
allow sepgsql_client_type sepgsql_table_t:db_column { getattr select update insert };
|
|
|
|
allow sepgsql_client_type sepgsql_table_t:db_tuple { select update insert delete };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr select lock };
|
|
|
|
allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr select };
|
|
|
|
allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { select };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
|
|
|
|
allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
|
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr select lock };
|
|
|
|
allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr select };
|
2008-06-10 15:33:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
allow sepgsql_client_type sepgsql_seq_t:db_sequence { getattr get_value next_value };
|
|
|
|
|
|
|
|
allow sepgsql_client_type sepgsql_view_t:db_view { getattr expand };
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
allow sepgsql_client_type sepgsql_proc_exec_t:db_procedure { getattr execute install };
|
2012-05-18 13:28:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_trusted_procedure_type:db_procedure { getattr execute entrypoint };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
allow sepgsql_client_type sepgsql_lang_t:db_language { getattr };
|
|
|
|
allow sepgsql_client_type sepgsql_safe_lang_t:db_language { getattr execute };
|
|
|
|
|
|
|
|
# Only DBA can implement SQL procedures using `unsafe' procedural languages.
|
|
|
|
# The `unsafe' one provides a capability to access internal data structure,
|
|
|
|
# so we don't allow user-defined function being implemented using `unsafe' one.
|
|
|
|
allow sepgsql_proc_exec_t sepgsql_lang_t:db_language { implement };
|
|
|
|
allow sepgsql_procedure_type sepgsql_safe_lang_t:db_language { implement };
|
|
|
|
|
2008-06-10 15:33:18 +00:00
|
|
|
allow sepgsql_client_type sepgsql_blob_t:db_blob { create drop getattr setattr read write };
|
|
|
|
allow sepgsql_client_type sepgsql_ro_blob_t:db_blob { getattr read };
|
|
|
|
allow sepgsql_client_type sepgsql_secret_blob_t:db_blob getattr;
|
|
|
|
|
|
|
|
# The purpose of the dontaudit rule in row-level access control is to prevent a flood of logs.
|
|
|
|
# If a client tries to SELECT a table including violated tuples, these are filtered from
|
|
|
|
# the result set as if not exist, but its access denied longs can be recorded within log files.
|
|
|
|
# In generally, the number of tuples are much larger than the number of columns, tables and so on.
|
|
|
|
# So, it makes a flood of logs when many tuples are violated.
|
|
|
|
#
|
|
|
|
# The default policy does not prevent anything for sepgsql_client_type sepgsql_unconfined_type,
|
|
|
|
# so we don't need "dontaudit" rules in Type-Enforcement. However, MLS/MCS can prevent them
|
|
|
|
# to access classified tuples and can make a audit record.
|
|
|
|
#
|
|
|
|
# Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.
|
2010-02-08 15:34:08 +00:00
|
|
|
dontaudit { postgresql_t sepgsql_admin_type sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { use select update insert delete };
|
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
# It is always allowed to operate temporary objects for any database client.
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_schema { create drop getattr setattr search add_name remove_name };
|
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_table { create drop getattr setattr select update insert delete lock };
|
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_column { create drop getattr setattr select update insert };
|
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_tuple { use select update insert delete };
|
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_sequence { create drop getattr setattr get_value next_value set_value };
|
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_view { create drop getattr setattr expand };
|
|
|
|
allow sepgsql_client_type sepgsql_temp_object_t:db_procedure { create drop getattr setattr execute entrypoint install };
|
2012-05-18 13:28:18 +00:00
|
|
|
|
2011-01-14 15:13:12 +00:00
|
|
|
# Note that permission of creation/deletion are eventually controlled by
|
|
|
|
# create or drop permission of individual objects within shared schemas.
|
|
|
|
# So, it just allows to create/drop user specific types.
|
|
|
|
tunable_policy(`sepgsql_enable_users_ddl',`
|
|
|
|
allow sepgsql_client_type sepgsql_schema_t:db_schema { add_name remove_name };
|
|
|
|
')
|
|
|
|
|
2010-02-08 15:34:08 +00:00
|
|
|
########################################
|
|
|
|
#
|
|
|
|
# Rules common to administrator clients
|
|
|
|
#
|
|
|
|
|
|
|
|
allow sepgsql_admin_type sepgsql_database_type:db_database { create drop getattr setattr relabelfrom relabelto access };
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_schema_type:db_schema { create drop getattr setattr relabelfrom relabelto search add_name remove_name };
|
|
|
|
type_transition sepgsql_admin_type sepgsql_database_type:db_schema sepgsql_schema_t;
|
2012-05-18 13:28:18 +00:00
|
|
|
type_transition sepgsql_admin_type sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
2010-02-08 15:34:08 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_table_type:db_table { create drop getattr setattr relabelfrom relabelto lock };
|
|
|
|
allow sepgsql_admin_type sepgsql_table_type:db_column { create drop getattr setattr relabelfrom relabelto };
|
2012-05-18 13:28:18 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_sysobj_table_type:db_tuple { relabelfrom relabelto use select update insert delete };
|
2010-02-08 15:34:08 +00:00
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type_transition sepgsql_admin_type sepgsql_schema_type:db_table sepgsql_table_t;
|
|
|
|
|
|
|
|
allow sepgsql_admin_type sepgsql_sequence_type:db_sequence { create drop getattr setattr relabelfrom relabelto get_value next_value set_value };
|
|
|
|
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition sepgsql_admin_type sepgsql_schema_type:db_sequence sepgsql_seq_t;
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
|
|
|
allow sepgsql_admin_type sepgsql_view_type:db_view { create drop getattr setattr relabelfrom relabelto expand };
|
|
|
|
|
2011-07-29 12:42:53 +00:00
|
|
|
type_transition sepgsql_admin_type sepgsql_schema_type:db_view sepgsql_view_t;
|
2010-04-12 14:14:10 +00:00
|
|
|
|
2010-02-08 15:34:08 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_procedure_type:db_procedure { create drop getattr relabelfrom relabelto };
|
2010-04-12 14:14:10 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_proc_exec_t:db_procedure execute;
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type_transition sepgsql_admin_type sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
|
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_schema { create drop getattr setattr search add_name remove_name };
|
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_table { create drop getattr setattr select update insert delete lock };
|
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_column { create drop getattr setattr select update insert };
|
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_tuple { use select update insert delete };
|
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_sequence { create drop getattr setattr get_value next_value set_value };
|
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_view { create drop getattr setattr expand };
|
|
|
|
allow sepgsql_admin_type sepgsql_temp_object_t:db_procedure { create drop getattr setattr execute entrypoint install };
|
2012-05-18 18:18:00 +00:00
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_language_type:db_language { create drop getattr setattr relabelfrom relabelto execute };
|
|
|
|
|
|
|
|
type_transition sepgsql_admin_type sepgsql_database_type:db_language sepgsql_lang_t;
|
2010-02-08 15:34:08 +00:00
|
|
|
|
|
|
|
allow sepgsql_admin_type sepgsql_blob_type:db_blob { create drop getattr setattr relabelfrom relabelto };
|
|
|
|
|
2010-04-12 14:14:10 +00:00
|
|
|
type_transition sepgsql_admin_type sepgsql_database_type:db_blob sepgsql_blob_t;
|
|
|
|
|
2010-02-08 15:34:08 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_module_type:db_database install_module;
|
|
|
|
|
|
|
|
kernel_relabelfrom_unlabeled_database(sepgsql_admin_type)
|
|
|
|
|
|
|
|
tunable_policy(`sepgsql_unconfined_dbadm',`
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_database_type:db_database { create drop getattr setattr relabelfrom relabelto access install_module load_module get_param set_param };
|
2010-02-08 15:34:08 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_schema_type:db_schema { create drop getattr setattr relabelfrom relabelto search add_name remove_name };
|
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
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_table_type:db_table { create drop getattr setattr relabelfrom relabelto select update insert delete lock };
|
|
|
|
allow sepgsql_admin_type sepgsql_table_type:db_column { create drop getattr setattr relabelfrom relabelto select update insert };
|
|
|
|
allow sepgsql_admin_type sepgsql_table_type:db_tuple { relabelfrom relabelto use select update insert delete };
|
|
|
|
allow sepgsql_admin_type sepgsql_sequence_type:db_sequence { create drop getattr setattr relabelfrom relabelto get_value next_value set_value };
|
|
|
|
allow sepgsql_admin_type sepgsql_view_type:db_view { create drop getattr setattr relabelfrom relabelto expand };
|
2010-02-08 15:34:08 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_proc_exec_t:db_procedure { create drop getattr setattr relabelfrom relabelto execute entrypoint install };
|
|
|
|
allow sepgsql_admin_type sepgsql_trusted_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto execute entrypoint };
|
|
|
|
allow sepgsql_admin_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto entrypoint };
|
2010-02-08 15:34:08 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_language_type:db_language { create drop getattr setattr relabelfrom relabelto 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
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_admin_type sepgsql_blob_type:db_blob { create drop getattr setattr relabelfrom relabelto read write import export };
|
2010-02-08 15:34:08 +00:00
|
|
|
')
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
########################################
|
|
|
|
#
|
|
|
|
# Unconfined access to this module
|
|
|
|
#
|
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_unconfined_type sepgsql_database_type:db_database { create drop getattr setattr relabelfrom relabelto access install_module load_module get_param set_param };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_unconfined_type { sepgsql_schema_type sepgsql_temp_object_t }:db_schema { create drop getattr setattr relabelfrom relabelto search add_name remove_name };
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_schema_t;
|
2012-05-18 13:28:18 +00:00
|
|
|
type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_temp_object_t "pg_temp";
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
|
|
|
|
type_transition sepgsql_unconfined_type sepgsql_schema_type:db_table sepgsql_table_t;
|
|
|
|
type_transition sepgsql_unconfined_type sepgsql_schema_type:db_sequence sepgsql_seq_t;
|
|
|
|
type_transition sepgsql_unconfined_type sepgsql_schema_type:db_view sepgsql_view_t;
|
|
|
|
type_transition sepgsql_unconfined_type sepgsql_schema_type:db_procedure sepgsql_proc_exec_t;
|
|
|
|
type_transition sepgsql_unconfined_type sepgsql_database_type:db_language sepgsql_lang_t;
|
2008-06-10 15:33:18 +00:00
|
|
|
type_transition sepgsql_unconfined_type sepgsql_database_type:db_blob sepgsql_blob_t;
|
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_unconfined_type sepgsql_table_type:db_table { create drop getattr setattr relabelfrom relabelto select update insert delete lock };
|
|
|
|
allow sepgsql_unconfined_type sepgsql_table_type:db_column { create drop getattr setattr relabelfrom relabelto select update insert };
|
|
|
|
allow sepgsql_unconfined_type sepgsql_table_type:db_tuple { relabelfrom relabelto use select update insert delete };
|
|
|
|
allow sepgsql_unconfined_type sepgsql_sequence_type:db_sequence { create drop getattr setattr relabelfrom relabelto get_value next_value set_value };
|
|
|
|
allow sepgsql_unconfined_type sepgsql_view_type:db_view { create drop getattr setattr relabelfrom relabelto expand };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
# unconfined domain is not allowed to invoke user defined procedure directly.
|
|
|
|
# They have to confirm and relabel it at first.
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_unconfined_type sepgsql_proc_exec_t:db_procedure { create drop getattr setattr relabelfrom relabelto execute entrypoint install };
|
|
|
|
allow sepgsql_unconfined_type sepgsql_trusted_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto execute entrypoint };
|
|
|
|
allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto entrypoint };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_unconfined_type sepgsql_language_type:db_language { create drop getattr setattr relabelfrom relabelto 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
|
|
|
|
2017-08-13 20:21:44 +00:00
|
|
|
allow sepgsql_unconfined_type sepgsql_blob_type:db_blob { create drop getattr setattr relabelfrom relabelto read write import export };
|
2008-06-10 15:33:18 +00:00
|
|
|
|
|
|
|
allow sepgsql_unconfined_type sepgsql_module_type:db_database install_module;
|
|
|
|
|
|
|
|
kernel_relabelfrom_unlabeled_database(sepgsql_unconfined_type)
|