Commit Graph

15 Commits

Author SHA1 Message Date
Jason Zaman 09ae441706 mls mcs: Add constraints for key class
Taken from fedoras policy
https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/policy/mls
https://github.com/fedora-selinux/selinux-policy/blob/rawhide-base/policy/mcs
2017-11-04 14:00:56 -04:00
cgzones d8cb498284 remove trailing whitespaces 2016-12-06 13:45:13 +01:00
Dominick Grift c2f056b2f6 Implement mcs_constrained_type
This process is not allowed to interact with subjects or operate on
objects that it would otherwise be able to interact with or operate on
respectively.

This is, i think, to make sure that specified processes cannot interact
with subject or operate on objects regardless of its mcs range.

It is used by svirt and probably also by sandbox

Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
2012-11-28 16:12:25 -05:00
Chris PeBenito c5114fef5e SEPostgresql changes from Kohei KaiGai.
* fix bugs in MLS/MCS
* add connection pooling server support
* foreign data wrapper support
* Add temporary objects support
* redefinition of use permission onto system objects
2012-05-18 09:28:18 -04:00
Chris PeBenito 515889b13c Pull in mcs constraint changes from Fedora. 2011-03-31 08:28:01 -04:00
KaiGai Kohei 82c32d5cf4 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(-)
2011-01-14 10:02:50 -05:00
Chris PeBenito 808341bb9b revise MCS constraints to use only MCS-specific attributes. 2009-10-07 11:48:14 -04:00
Chris PeBenito 350ed89156 se-postgresql update from kaigai
- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
    db_database:{getattr}
    db_table:{getattr lock}
    db_column:{getattr}
    db_procedure:{drop getattr setattr}
    db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
  impossible to refer read-only table with foreign-key constraint.
  (FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
  on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
  It should allow them on sepgsql_trusted_proc_exec_t.
  I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
  such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
  sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
  procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
  but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
2009-05-07 12:35:32 +00:00
Chris PeBenito 466e22a8ba trunk: Add db_procedure install permission from KaiGai Kohei. 2009-01-23 19:49:36 +00:00
Chris PeBenito 9760cbec2d trunk: Database userspace object manager classes from KaiGai Kohei. 2007-08-09 13:15:07 +00:00
Chris PeBenito e070dd2df0 - Move range transitions to modules.
- Make number of MLS sensitivities, and number of MLS and MCS
  categories configurable as build options.
2006-10-04 17:25:34 +00:00
Chris PeBenito 8708d9bef2 patch from dan Wed, 20 Sep 2006 12:12:49 -0400 2006-09-22 17:14:35 +00:00
Chris PeBenito a9e03b3752 * add a macro for generating category declarations
* fix userdom_search_all_users_home_content() to use search_dir_perms;
* change ssh daemon macro to use userdom_search_all_users_home_dirs() instead of _home_content()
2006-09-21 15:48:15 +00:00
Chris PeBenito 46551033aa patch from dan Wed, 26 Jul 2006 14:42:46 -0400 2006-07-28 15:13:58 +00:00
Chris PeBenito 17de1b790b remove extra level of directory 2006-07-12 20:32:27 +00:00