selinux-refpolicy/policy/mcs

201 lines
6.4 KiB
Plaintext
Raw Normal View History

2005-09-16 13:36:26 +00:00
ifdef(`enable_mcs',`
#
2016-12-06 12:28:10 +00:00
# Define sensitivities
2005-09-16 13:36:26 +00:00
#
# 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.
mlsconstrain dir_file_class_set { open read ioctl lock write setattr append create unlink link rename relabelfrom relabelto }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain file { execute execute_no_trans }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain dir { search add_name remove_name rmdir }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
# New filesystem object labels must be dominated by the relabeling subject
# clearance, also the objects are single-level.
mlsconstrain { file lnk_file fifo_file } { create relabelto }
((( h1 dom h2 ) and ( l2 eq h2 )) or
( t1 != mcs_constrained_type ));
2005-09-16 13:36:26 +00:00
#
# MCS policy for process classes
#
mlsconstrain process { transition dyntransition ptrace sigkill sigstop signal getsession getattr getsched setsched getrlimit setrlimit getpgid setpgid getcap setcap share setexec setfscreate setcurrent setsockcreate }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
#
# MCS policy for socket classes
#
mlsconstrain socket_class_set { create ioctl read write setattr append bind connect getopt setopt shutdown }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain stream_socket_class_set { listen accept }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain { tcp_socket udp_socket rawip_socket sctp_socket } node_bind
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain unix_stream_socket connectto
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain unix_dgram_socket sendto
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
#
# MCS policy for key class
#
mlsconstrain key { create link read search setattr view write }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
#
# MCS policy for SysV IPC
#
mlsconstrain { ipc sem msgq shm } { create destroy setattr read unix_read write unix_write }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain msg { send receive }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain msgq enqueue
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain shm lock
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
#
# MCS policy for context class
#
mlsconstrain context contains
((( h1 dom h2 ) and ( l1 domby l2 )) or ( t1 != mcs_constrained_type ));
#
# MCS policy for network classes
#
# The node recvfrom/sendto ops, the recvfrom permission is a "write" operation
# because the subject in this particular case is the remote domain which is
# writing data out the network node which is acting as the object
mlsconstrain { node } { recvfrom sendto }
(( l1 dom l2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain { packet peer } { recv }
(( l1 dom l2 ) or
(( t1 != mcs_constrained_type ) and ( t2 != mcs_constrained_type )));
# The netif ingress/egress ops, the ingress permission is a "write" operation
# because the subject in this particular case is the remote domain which is
# writing data out the network interface which is acting as the object
mlsconstrain { netif } { egress ingress }
(( l1 dom l2 ) or ( t1 != mcs_constrained_type ));
#
# 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 )) or ( t1 != mcs_constrained_type ));
mlsconstrain { db_tuple } { insert relabelto }
((( h1 dom h2 ) and ( l2 eq h2 )) or ( t1 != mcs_constrained_type ));
# 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 ) or ( t1 != mcs_constrained_type ));
mlsconstrain db_schema { drop getattr setattr relabelfrom search }
(( h1 dom h2 ) or ( t1 != mcs_constrained_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
mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete lock }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain db_column { drop getattr setattr relabelfrom select update insert }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain db_tuple { relabelfrom select update delete use }
(( h1 dom h2 ) or ( t1 != mcs_constrained_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
mlsconstrain db_sequence { drop getattr setattr relabelfrom get_value next_value set_value }
(( h1 dom h2 ) or ( t1 != mcs_constrained_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
mlsconstrain db_view { drop getattr setattr relabelfrom expand }
(( h1 dom h2 ) or ( t1 != mcs_constrained_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
mlsconstrain db_procedure { drop getattr setattr relabelfrom execute install entrypoint }
(( h1 dom h2 ) or ( t1 != mcs_constrained_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
mlsconstrain db_language { drop getattr setattr relabelfrom execute }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
mlsconstrain db_blob { drop getattr setattr relabelfrom read write import export }
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
2005-09-16 13:36:26 +00:00
') dnl end enable_mcs