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.
|
|
|
|
|
2006-10-04 17:25:34 +00:00
|
|
|
gen_sens(1)
|
2005-09-16 13:36:26 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Define the categories
|
|
|
|
#
|
2006-10-04 17:25:34 +00:00
|
|
|
# Generate declarations
|
2006-09-21 15:48:15 +00:00
|
|
|
|
2006-10-04 17:25:34 +00:00
|
|
|
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.
|
|
|
|
#
|
2006-10-04 17:25:34 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
#
|
2009-10-07 15:48:14 +00:00
|
|
|
# Note:
|
|
|
|
# - getattr on dirs/files is not constrained.
|
|
|
|
|
2022-06-20 14:54:46 +00:00
|
|
|
mlsconstrain dir_file_class_set { open read ioctl lock write setattr append create unlink link rename relabelfrom relabelto }
|
2021-10-13 15:26:23 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2006-02-16 19:32:13 +00:00
|
|
|
|
2022-06-20 14:54:46 +00:00
|
|
|
mlsconstrain file { execute execute_no_trans }
|
2021-10-13 15:26:23 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2009-10-07 15:48:14 +00:00
|
|
|
|
2022-06-20 14:54:46 +00:00
|
|
|
mlsconstrain dir { search add_name remove_name rmdir }
|
2021-10-13 15:26:23 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2006-09-22 17:14:35 +00:00
|
|
|
|
2006-04-17 17:32:54 +00:00
|
|
|
# New filesystem object labels must be dominated by the relabeling subject
|
|
|
|
# clearance, also the objects are single-level.
|
2021-10-14 14:21:48 +00:00
|
|
|
mlsconstrain { file lnk_file fifo_file } { create relabelto }
|
2021-10-13 15:26:23 +00:00
|
|
|
((( h1 dom h2 ) and ( l2 eq h2 )) or
|
|
|
|
( t1 != mcs_constrained_type ));
|
2005-09-16 13:36:26 +00:00
|
|
|
|
2022-06-23 19:29:50 +00:00
|
|
|
#
|
|
|
|
# MCS policy for process classes
|
|
|
|
#
|
2022-06-23 19:06:27 +00:00
|
|
|
mlsconstrain process { transition dyntransition ptrace sigkill sigstop signal getsession getattr getsched setsched getrlimit setrlimit getpgid setpgid getcap setcap share setexec setfscreate setcurrent setsockcreate }
|
2012-11-27 16:59:19 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
|
|
|
|
2022-06-23 19:29:50 +00:00
|
|
|
#
|
|
|
|
# MCS policy for socket classes
|
|
|
|
#
|
2022-06-20 18:50:20 +00:00
|
|
|
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 ));
|
|
|
|
|
2018-03-19 09:59:54 +00:00
|
|
|
mlsconstrain { tcp_socket udp_socket rawip_socket sctp_socket } node_bind
|
2012-11-27 16:59:19 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
|
|
|
|
2022-06-20 18:50:20 +00:00
|
|
|
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 ));
|
|
|
|
|
2022-06-23 19:29:50 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# MCS policy for key class
|
|
|
|
#
|
2017-11-02 17:30:45 +00:00
|
|
|
mlsconstrain key { create link read search setattr view write }
|
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
|
|
|
|
2022-06-23 19:29:50 +00:00
|
|
|
#
|
|
|
|
# MCS policy for SysV IPC
|
|
|
|
#
|
2022-06-20 14:52:30 +00:00
|
|
|
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
|
2021-10-13 15:58:45 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
|
|
|
|
2022-06-23 19:29:50 +00:00
|
|
|
#
|
|
|
|
# MCS policy for context class
|
|
|
|
#
|
2021-11-09 18:56:27 +00:00
|
|
|
mlsconstrain context contains
|
|
|
|
((( h1 dom h2 ) and ( l1 domby l2 )) or ( t1 != mcs_constrained_type ));
|
|
|
|
|
2022-06-23 19:29:50 +00:00
|
|
|
#
|
|
|
|
# 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 ));
|
|
|
|
|
2007-08-09 13:15:07 +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 }
|
2021-11-09 18:59:08 +00:00
|
|
|
((( h1 dom h2 ) and ( l2 eq h2 )) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
|
|
|
mlsconstrain { db_tuple } { insert relabelto }
|
2021-11-09 18:59:08 +00:00
|
|
|
((( h1 dom h2 ) and ( l2 eq h2 )) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
|
|
|
# Access control for any database objects based on MCS rules.
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain db_database { drop getattr setattr relabelfrom access install_module load_module get_param set_param }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
mlsconstrain db_schema { drop getattr setattr relabelfrom search }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( 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
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete lock }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
mlsconstrain db_column { drop getattr setattr relabelfrom select update insert }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
|
|
|
mlsconstrain db_tuple { relabelfrom select update delete use }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +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
|
|
|
mlsconstrain db_sequence { drop getattr setattr relabelfrom get_value next_value set_value }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( 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 }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( 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
|
|
|
|
2012-05-18 13:28:18 +00:00
|
|
|
mlsconstrain db_procedure { drop getattr setattr relabelfrom execute install entrypoint }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( 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 }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain db_blob { drop getattr setattr relabelfrom read write import export }
|
2021-11-09 18:59:08 +00:00
|
|
|
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
|
2007-08-09 13:15:07 +00:00
|
|
|
|
2005-09-16 13:36:26 +00:00
|
|
|
') dnl end enable_mcs
|