selinux-refpolicy/policy/mcs

148 lines
4.2 KiB
Plaintext
Raw Normal View History

2005-09-16 13:36:26 +00:00
ifdef(`enable_mcs',`
#
# Define sensitivities
#
# MCS is single-sensitivity.
gen_sens(1)
2005-09-16 13:36:26 +00:00
#
# Define the categories
#
# Generate declarations
gen_cats(mcs_num_cats)
2005-09-16 13:36:26 +00:00
#
# Each MCS level specifies a sensitivity and zero or more categories which may
# be associated with that sensitivity.
#
gen_levels(1,mcs_num_cats)
2005-09-16 13:36:26 +00:00
#
# Define the MCS policy
#
# mlsconstrain class_set perm_set expression ;
#
# mlsvalidatetrans class_set expression ;
#
# expression : ( expression )
# | not expression
# | expression and expression
# | expression or expression
# | u1 op u2
# | r1 role_mls_op r2
# | t1 op t2
# | l1 role_mls_op l2
# | l1 role_mls_op h2
# | h1 role_mls_op l2
# | h1 role_mls_op h2
# | l1 role_mls_op h1
# | l2 role_mls_op h2
# | u1 op names
# | u2 op names
# | r1 op names
# | r2 op names
# | t1 op names
# | t2 op names
# | u3 op names (NOTE: this is only available for mlsvalidatetrans)
# | r3 op names (NOTE: this is only available for mlsvalidatetrans)
# | t3 op names (NOTE: this is only available for mlsvalidatetrans)
#
# op : == | !=
# role_mls_op : == | != | eq | dom | domby | incomp
#
# names : name | { name_list }
# name_list : name | name_list name
#
#
# MCS policy for the file classes
#
# Constrain file access so that the high range of the process dominates
# the high range of the file. We use the high range of the process so
# that processes can always simply run at s0.
#
# Note:
# - getattr on dirs/files is not constrained.
# - /proc/pid operations are not constrained.
mlsconstrain file { read ioctl lock execute execute_no_trans }
(( h1 dom h2 ) or ( t1 == mcsreadall ) or ( t2 == domain ));
mlsconstrain file { write setattr append unlink link rename }
(( h1 dom h2 ) or ( t1 == mcswriteall ) or ( t2 == domain ));
mlsconstrain dir { search read ioctl lock }
(( h1 dom h2 ) or ( t1 == mcsreadall ) or ( t2 == domain ));
mlsconstrain dir { write setattr append unlink link rename add_name remove_name }
(( h1 dom h2 ) or ( t1 == mcswriteall ) or ( t2 == domain ));
# New filesystem object labels must be dominated by the relabeling subject
# clearance, also the objects are single-level.
2006-03-29 14:51:49 +00:00
mlsconstrain file { create relabelto }
(( h1 dom h2 ) and ( l2 eq h2 ));
2005-09-16 13:36:26 +00:00
# new file labels must be dominated by the relabeling subject clearance
mlsconstrain { dir lnk_file chr_file blk_file sock_file fifo_file } { relabelfrom }
( h1 dom h2 );
2006-03-29 14:51:49 +00:00
mlsconstrain { dir lnk_file chr_file blk_file sock_file fifo_file } { create relabelto }
(( h1 dom h2 ) and ( l2 eq h2 ));
mlsconstrain process { transition dyntransition }
(( h1 dom h2 ) or ( t1 == mcssetcats ));
2006-03-29 14:51:49 +00:00
mlsconstrain process { ptrace }
(( h1 dom h2) or ( t1 == mcsptraceall ));
2005-09-16 13:36:26 +00:00
2006-03-29 14:51:49 +00:00
mlsconstrain process { sigkill sigstop }
(( h1 dom h2 ) or ( t1 == mcskillall ));
2005-09-16 13:36:26 +00:00
#
# MCS policy for SELinux-enabled databases
#
# Any database object must be dominated by the relabeling subject
# clearance, also the objects are single-level.
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
mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
(( h1 dom h2 ) and ( l2 eq h2 ));
mlsconstrain { db_tuple } { insert relabelto }
(( h1 dom h2 ) and ( l2 eq h2 ));
# Access control for any database objects based on MCS rules.
mlsconstrain db_database { drop getattr setattr relabelfrom access install_module load_module get_param set_param }
( h1 dom h2 );
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
mlsconstrain db_language { drop getattr setattr relabelfrom execute }
( h1 dom h2 );
mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete use lock }
( h1 dom h2 );
mlsconstrain db_column { drop getattr setattr relabelfrom select update insert use }
( h1 dom h2 );
mlsconstrain db_tuple { relabelfrom select update delete use }
( h1 dom h2 );
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
mlsconstrain db_sequence { drop getattr setattr relabelfrom get_value next_value set_value }
( h1 dom h2 );
mlsconstrain db_view { drop getattr setattr relabelfrom expand }
( h1 dom h2 );
mlsconstrain db_procedure { drop getattr setattr relabelfrom execute install }
( h1 dom h2 );
mlsconstrain db_language { drop getattr setattr relabelfrom execute }
( h1 dom h2 );
mlsconstrain db_blob { drop getattr setattr relabelfrom read write import export }
( h1 dom h2 );
2005-09-16 13:36:26 +00:00
') dnl end enable_mcs