As we have discussed for the recent week, I have a plan to rework
some of security policy for SE-PostgreSQL.
The attached patch adds the significan changes, as follows.
Could you give me any suggestion, approval or opposition?
New object classes and permissions
----------------------------------
* db_catalog class
It shows the top level namespace in the database, and has a capability
to store a set of schemas. Some of implementation does not support
catalogs. In this case, we simply ignore this class and any schemas
are placed under the db_database directly.
It defines the following four permissions and inherited ones:
{ search add_object remove_object associate }
Client should have db_catalog:{search} on the catalog when he refers
any schemas under the catalog, and he should also have
db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
when he tries to add or remove a shema within the catalog.
These permissions are an analogy of dir object class.
The db_catalog:{associate}, which I've not introduced yet but noticed
its necessity, is also checked when we create or relabel a schema
within the catalog, and the schema should have db_catalog:{associate}
on the catalog. It is an analogy of filesystem:{associate}.
It prevents a schema is labeled unexpectedly.
* db_schema class
It shows the second level namespace in the database, but it may be
the top level one in some of implementation (like PostgreSQL).
It has a capability to store a set of database objects (tables,
procedures and so on).
It defines the following four permissions and inherited ones:
{ search add_object remove_object associate }
Their meanings are similar to ones in db_catalog class except for
the schema to be replaced by database objects.
Its security context can be computed with TYPE_TRANSITION between
the client as a subject and the database (or catalog, if availabel)
as a target.
* db_sequence class
It shows the sequential number generator objects. We can also use
them as a communication channel between two domains, so it is
necessary to apply security policy.
It inherits common database and defines the following two permissions:
{ get_value set_value }
Client should have db_sequence:{get_value} when he fetch a value from
the sequence generator, and db_sequence:{set_value} when he set a
discretionary value. When he fetch a value from the sequence object,
it implicitly increments internal counter, but it is covered by the
get_value permission.
Its security context can be computed with TYPE_TRANSITION between
the client as a subject and the schema as a target.
Change definition of object classes
-----------------------------------
* db_database class
The db_database:{get_param set_param} is removed because these two
permissions are nonsense.
The db_database:{superuser} is newly added. It is checked when
client perform as database superuser. Stephen suggested it can
be separated to more finer grained privileges. It makes sense,
but this kind of separation which focuses on PostgreSQL makes
hard to port the concept for other database management systems.
* db_table/db_column/db_tuple:{use} permission
The db_xxx:{use} permission is integrated into db_xxx:{select}
permission, because it can hide the risk to infer invisible
information easily with well considered WHERE clauses.
user_sepgsql_xxxx_t types
-------------------------
* Currently, sepgsql_proc_t is assigned to the procedures created
by unprivileged and unprefixed clients, like httpd_t.
But I would like to handle it as a procedure created or relabeled
by database administrator.
Basically, we consider user defined procedures are untrusted, so
it should be checked before it becomes available for all the clients.
So, we don't allow to install them as system internal entities, and
don't allow unconfined domains to execute them directly.
My preference is the user_sepgsql_xxxx_t is also assigned to
procedures created by unprivileged and unprfixed client.
A schema for temporary obejcts
------------------------------
* The sepgsql_schema_t is the default type for schema objects, and
rest of database objects within the schema is labeled with the chain
of TYPE_TRANSITION rules.
We have a characteristic scheme named as "pg_temp_*". Any database
objects within the schema are cleared after the session closed,
so its contents are always session local. We would like to assign
special types on the temporary schema and delivered database objects
withing the schema. In addition, users can create and use these
database objects independently from the sepgsql_enable_users_ddl.
Booelean behavior: sepgsql_enable_users_ddl
-------------------------------------------
* Because the current design does not care about actions on schema
objects, we need to assign separated label (sepgsql_sysobj_t) on
system informations and apply checks as row-level controls.
But db_schema object class enables to control user's DDLs in
the schema level checks mainly, so now sepgsql_enable_user_ddl
focuses on db_schema class permissions and {create drop setattr}
for any other database objects.
The attached patch allows users to modify tuples with sepgsql_sysobj_t
but not allows columns/tables. It means user can define database
objects with proper way (like CREATE TABLE), but prevents to
manipulate system information by hand.
In addition, this boolean controls only user_sepgsql_xxxx_t.
The unprefixed types are always not allowed to modify its definition
by unprivileges users.
db_table:{lock} for reader actions
----------------------------------
* db_table:{lock} is also necessary for reader side actions due to the
implementation reason.
In PostgreSQL, FK constraints are implemented as trigger functions.
It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
and run a secondary query to check whether the action satisfies
FK constraints or not.
This query is described as:
SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
The "FOR SHARE" clause means explicit table lock and requires
db_table:{lock} permission. If we don't allow unpriv clients to
lock read-only tables, it disables to set up FK constraint which
refers read-only tables.
Miscellaneous changes
---------------------
* The security context of a new database is decided via type_transition
on the server process's context. It enables to avoid conflicts when
we have multiple DBMSs in a system.
* It allows postgresql_t domain to write out messages to system audit.
* sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
* db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
because we don't need to run trusted procedure implicitly.
* Most of postgresql_role() are shared with postgresql_unpriv_client(),
except for "role $1 types sepgsql_trusted_proc_t;"
* /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-rework.2.patch
Type: text/x-patch
Size: 24841 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/9d0579be/attachment-0001.bin
looks good to me.
One minor comment. For the superuser permission, this may be common use
of DBMS's but I believe is not a standard SQL feature. RUBIX has no such
concept, so we would generally ignore that permission. Also, it is
unclear to me what abilities the superuser should have (in the general
sense, not necessarily within sepostgresql). Is this just a permission
to override SQL DAC, or does it also give administrative abilities like
setting audit configurations, or "all the above." I think you said
before that it would not allow MAC override, correct?
RUBIX currently has four privileged "roles":
Database Administrator: DAC override
Security Administrator: MAC override, to some degree. With SELinux much
of this can be done with discrete rules.
Audit Administrator: administer audit trail and criteria
Database Operator: do the normal day-today administrative DBMS tasks,
like backup.
I am curious, if the intended use of the db_database superuser
permission would be an encapsulation of our all of our roles, excluding
the Security Administrator.
As a side note, without knowing too much about the intent of the
superuser permission, I would think the categories of "roles" RUBIX uses
would be general enough for just about any database. Thus, providing
equivalent permissions might be useful (excluding the Security
Administrator, which I am guessing the community would say is not needed
because MAC override mechanisms exist within SELinux already) .
KaiGai Kohei wrote:
> As we have discussed for the recent week, I have a plan to rework
> some of security policy for SE-PostgreSQL.
>
> The attached patch adds the significan changes, as follows.
> Could you give me any suggestion, approval or opposition?
>
> New object classes and permissions
> ----------------------------------
> * db_catalog class
> It shows the top level namespace in the database, and has a capability
> to store a set of schemas. Some of implementation does not support
> catalogs. In this case, we simply ignore this class and any schemas
> are placed under the db_database directly.
>
> It defines the following four permissions and inherited ones:
> { search add_object remove_object associate }
>
> Client should have db_catalog:{search} on the catalog when he refers
> any schemas under the catalog, and he should also have
> db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
> when he tries to add or remove a shema within the catalog.
> These permissions are an analogy of dir object class.
>
> The db_catalog:{associate}, which I've not introduced yet but noticed
> its necessity, is also checked when we create or relabel a schema
> within the catalog, and the schema should have db_catalog:{associate}
> on the catalog. It is an analogy of filesystem:{associate}.
> It prevents a schema is labeled unexpectedly.
>
> * db_schema class
> It shows the second level namespace in the database, but it may be
> the top level one in some of implementation (like PostgreSQL).
> It has a capability to store a set of database objects (tables,
> procedures and so on).
>
> It defines the following four permissions and inherited ones:
> { search add_object remove_object associate }
> Their meanings are similar to ones in db_catalog class except for
> the schema to be replaced by database objects.
>
> Its security context can be computed with TYPE_TRANSITION between
> the client as a subject and the database (or catalog, if availabel)
> as a target.
>
> * db_sequence class
> It shows the sequential number generator objects. We can also use
> them as a communication channel between two domains, so it is
> necessary to apply security policy.
>
> It inherits common database and defines the following two permissions:
> { get_value set_value }
> Client should have db_sequence:{get_value} when he fetch a value from
> the sequence generator, and db_sequence:{set_value} when he set a
> discretionary value. When he fetch a value from the sequence object,
> it implicitly increments internal counter, but it is covered by the
> get_value permission.
>
> Its security context can be computed with TYPE_TRANSITION between
> the client as a subject and the schema as a target.
>
> Change definition of object classes
> -----------------------------------
> * db_database class
> The db_database:{get_param set_param} is removed because these two
> permissions are nonsense.
> The db_database:{superuser} is newly added. It is checked when
> client perform as database superuser. Stephen suggested it can
> be separated to more finer grained privileges. It makes sense,
> but this kind of separation which focuses on PostgreSQL makes
> hard to port the concept for other database management systems.
>
> * db_table/db_column/db_tuple:{use} permission
> The db_xxx:{use} permission is integrated into db_xxx:{select}
> permission, because it can hide the risk to infer invisible
> information easily with well considered WHERE clauses.
>
> user_sepgsql_xxxx_t types
> -------------------------
> * Currently, sepgsql_proc_t is assigned to the procedures created
> by unprivileged and unprefixed clients, like httpd_t.
> But I would like to handle it as a procedure created or relabeled
> by database administrator.
> Basically, we consider user defined procedures are untrusted, so
> it should be checked before it becomes available for all the clients.
> So, we don't allow to install them as system internal entities, and
> don't allow unconfined domains to execute them directly.
>
> My preference is the user_sepgsql_xxxx_t is also assigned to
> procedures created by unprivileged and unprfixed client.
>
> A schema for temporary obejcts
> ------------------------------
> * The sepgsql_schema_t is the default type for schema objects, and
> rest of database objects within the schema is labeled with the chain
> of TYPE_TRANSITION rules.
> We have a characteristic scheme named as "pg_temp_*". Any database
> objects within the schema are cleared after the session closed,
> so its contents are always session local. We would like to assign
> special types on the temporary schema and delivered database objects
> withing the schema. In addition, users can create and use these
> database objects independently from the sepgsql_enable_users_ddl.
>
> Booelean behavior: sepgsql_enable_users_ddl
> -------------------------------------------
> * Because the current design does not care about actions on schema
> objects, we need to assign separated label (sepgsql_sysobj_t) on
> system informations and apply checks as row-level controls.
> But db_schema object class enables to control user's DDLs in
> the schema level checks mainly, so now sepgsql_enable_user_ddl
> focuses on db_schema class permissions and {create drop setattr}
> for any other database objects.
> The attached patch allows users to modify tuples with sepgsql_sysobj_t
> but not allows columns/tables. It means user can define database
> objects with proper way (like CREATE TABLE), but prevents to
> manipulate system information by hand.
> In addition, this boolean controls only user_sepgsql_xxxx_t.
> The unprefixed types are always not allowed to modify its definition
> by unprivileges users.
>
> db_table:{lock} for reader actions
> ----------------------------------
> * db_table:{lock} is also necessary for reader side actions due to the
> implementation reason.
> In PostgreSQL, FK constraints are implemented as trigger functions.
> It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
> and run a secondary query to check whether the action satisfies
> FK constraints or not.
> This query is described as:
> SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
>
> The "FOR SHARE" clause means explicit table lock and requires
> db_table:{lock} permission. If we don't allow unpriv clients to
> lock read-only tables, it disables to set up FK constraint which
> refers read-only tables.
>
> Miscellaneous changes
> ---------------------
> * The security context of a new database is decided via type_transition
> on the server process's context. It enables to avoid conflicts when
> we have multiple DBMSs in a system.
> * It allows postgresql_t domain to write out messages to system audit.
> * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
> * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
> because we don't need to run trusted procedure implicitly.
> * Most of postgresql_role() are shared with postgresql_unpriv_client(),
> except for "role $1 types sepgsql_trusted_proc_t;"
> * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
>
> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/8207c5eb/attachment.html
Andy Warner wrote:
> looks good to me.
>
> One minor comment. For the superuser permission, this may be common use
> of DBMS's but I believe is not a standard SQL feature. RUBIX has no such
> concept, so we would generally ignore that permission. Also, it is
> unclear to me what abilities the superuser should have (in the general
> sense, not necessarily within sepostgresql).
It is a request from the pgsql-hackers.
In addition, the permission is well symmetrical with root capability
on operating system.
In PostgreSQL, database users with superuser privilege are allowed
various kind of operating, such as ignoring DAC policy, ignoring
ownership of database objects, installing shared libraries and so on.
The db_database:{superuser} enables to control these capabilities.
> Is this just a permission
> to override SQL DAC, or does it also give administrative abilities like
> setting audit configurations, or "all the above." I think you said
> before that it would not allow MAC override, correct?
SELinux does not allow anyone to override MAC.
The unconfined domain is allowed anything in the result of access controls.
> RUBIX currently has four privileged "roles":
> Database Administrator: DAC override
> Security Administrator: MAC override, to some degree. With SELinux much
> of this can be done with discrete rules.
> Audit Administrator: administer audit trail and criteria
> Database Operator: do the normal day-today administrative DBMS tasks,
> like backup.
>
> I am curious, if the intended use of the db_database superuser
> permission would be an encapsulation of our all of our roles, excluding
> the Security Administrator.
My preference is to adopt common design *as far as possible*.
If you need finer-grained privileges, please propose it as a characteristic
part for Trusted RUBIX, as if we did on db_catalog class.
Anyway, I cannot believe the pgsql-hackers accepts its design changes due
to the RUBIX's design.
Thanks,
--
KaiGai Kohei <[email protected]>
KaiGai Kohei wrote:
> Andy Warner wrote:
>
>> looks good to me.
>>
>> One minor comment. For the superuser permission, this may be common use
>> of DBMS's but I believe is not a standard SQL feature. RUBIX has no such
>> concept, so we would generally ignore that permission. Also, it is
>> unclear to me what abilities the superuser should have (in the general
>> sense, not necessarily within sepostgresql).
>>
>
> It is a request from the pgsql-hackers.
>
> In addition, the permission is well symmetrical with root capability
> on operating system.
> In PostgreSQL, database users with superuser privilege are allowed
> various kind of operating, such as ignoring DAC policy, ignoring
> ownership of database objects, installing shared libraries and so on.
> The db_database:{superuser} enables to control these capabilities.
>
>
Sounds like our DBA role. Basically, its just a different name. I agree
that the superuser is a common concept in OS's, but note that its use is
often discouraged. I'm note sure introducing it for databases is a great
idea. But, as I said before, we would just ignore it as primarily its
there to satisfy postgresql.
>> Is this just a permission
>> to override SQL DAC, or does it also give administrative abilities like
>> setting audit configurations, or "all the above." I think you said
>> before that it would not allow MAC override, correct?
>>
>
> SELinux does not allow anyone to override MAC.
> The unconfined domain is allowed anything in the result of access controls.
>
I am referring to things like:
mlsconstrain { db_tuple } { use select }
(( l1 dom l2 ) or
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsdbread ) or
( t2 == mlstrustedobject ));
where t1 == mlsdbread seems to imply an object is trusted to read
strictly dominating objects. Unless I am missing the meaning here, I
would call this a MAC override. I realize there is no concept of a TE
override, but MLS is part of MAC, no? And, this violates B&L rules. This
is something we would control with a Security Administrator "role". Or,
is this mlsdbread something that is impossible to give to a domain in a
DBMS policy?
>
>> RUBIX currently has four privileged "roles":
>> Database Administrator: DAC override
>> Security Administrator: MAC override, to some degree. With SELinux much
>> of this can be done with discrete rules.
>> Audit Administrator: administer audit trail and criteria
>> Database Operator: do the normal day-today administrative DBMS tasks,
>> like backup.
>>
>> I am curious, if the intended use of the db_database superuser
>> permission would be an encapsulation of our all of our roles, excluding
>> the Security Administrator.
>>
>
> My preference is to adopt common design *as far as possible*.
> If you need finer-grained privileges, please propose it as a characteristic
> part for Trusted RUBIX, as if we did on db_catalog class.
> Anyway, I cannot believe the pgsql-hackers accepts its design changes due
> to the RUBIX's design.
>
> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/25855cfc/attachment.html
KaiGai Kohei wrote:
>> I am referring to things like:
>>
>> mlsconstrain { db_tuple } { use select }
>> (( l1 dom l2 ) or
>> (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
>> ( t1 == mlsdbread ) or
>> ( t2 == mlstrustedobject ));
>>
>
> I noticed the db_xxx:{use} permission remained here. :-)
>
The example I used above is from an older version of the reference policy.
>
>> where t1 == mlsdbread seems to imply an object is trusted to read
>> strictly dominating objects. Unless I am missing the meaning here, I
>> would call this a MAC override. I realize there is no concept of a TE
>> override, but MLS is part of MAC, no? And, this violates B&L rules. This
>> is something we would control with a Security Administrator "role". Or,
>> is this mlsdbread something that is impossible to give to a domain in a
>> DBMS policy?
>>
>
> It is different from my usage of terms.
> Some of domains are allowed to access the tuple, and others are
> disallowed as the result of access controls using the security
> policy.
>
> I understood the term of "MAC override" to express what actions
> are allowed without any checks based on security policy, as if
> root stuff can ignore DAC checks.
>
Ya, definitions, definitions :-) Coming from an MLS world, MAC override
meant superseding the B&L policy. In a general sense we use special
authorizations for that (our Security Admin role), while SELinux has a
built in mechanism (mlsdbread)
> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090331/1bdb4cb0/attachment.html
Chris,
What is your opinion about this reworks?
If its scale is too large to commit at once, I can separate it
into several pieces.
Thanks,
KaiGai Kohei wrote:
> As we have discussed for the recent week, I have a plan to rework
> some of security policy for SE-PostgreSQL.
>
> The attached patch adds the significan changes, as follows.
> Could you give me any suggestion, approval or opposition?
>
> New object classes and permissions
> ----------------------------------
> * db_catalog class
> It shows the top level namespace in the database, and has a capability
> to store a set of schemas. Some of implementation does not support
> catalogs. In this case, we simply ignore this class and any schemas
> are placed under the db_database directly.
>
> It defines the following four permissions and inherited ones:
> { search add_object remove_object associate }
>
> Client should have db_catalog:{search} on the catalog when he refers
> any schemas under the catalog, and he should also have
> db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
> when he tries to add or remove a shema within the catalog.
> These permissions are an analogy of dir object class.
>
> The db_catalog:{associate}, which I've not introduced yet but noticed
> its necessity, is also checked when we create or relabel a schema
> within the catalog, and the schema should have db_catalog:{associate}
> on the catalog. It is an analogy of filesystem:{associate}.
> It prevents a schema is labeled unexpectedly.
>
> * db_schema class
> It shows the second level namespace in the database, but it may be
> the top level one in some of implementation (like PostgreSQL).
> It has a capability to store a set of database objects (tables,
> procedures and so on).
>
> It defines the following four permissions and inherited ones:
> { search add_object remove_object associate }
> Their meanings are similar to ones in db_catalog class except for
> the schema to be replaced by database objects.
>
> Its security context can be computed with TYPE_TRANSITION between
> the client as a subject and the database (or catalog, if availabel)
> as a target.
>
> * db_sequence class
> It shows the sequential number generator objects. We can also use
> them as a communication channel between two domains, so it is
> necessary to apply security policy.
>
> It inherits common database and defines the following two permissions:
> { get_value set_value }
> Client should have db_sequence:{get_value} when he fetch a value from
> the sequence generator, and db_sequence:{set_value} when he set a
> discretionary value. When he fetch a value from the sequence object,
> it implicitly increments internal counter, but it is covered by the
> get_value permission.
>
> Its security context can be computed with TYPE_TRANSITION between
> the client as a subject and the schema as a target.
>
> Change definition of object classes
> -----------------------------------
> * db_database class
> The db_database:{get_param set_param} is removed because these two
> permissions are nonsense.
> The db_database:{superuser} is newly added. It is checked when
> client perform as database superuser. Stephen suggested it can
> be separated to more finer grained privileges. It makes sense,
> but this kind of separation which focuses on PostgreSQL makes
> hard to port the concept for other database management systems.
>
> * db_table/db_column/db_tuple:{use} permission
> The db_xxx:{use} permission is integrated into db_xxx:{select}
> permission, because it can hide the risk to infer invisible
> information easily with well considered WHERE clauses.
>
> user_sepgsql_xxxx_t types
> -------------------------
> * Currently, sepgsql_proc_t is assigned to the procedures created
> by unprivileged and unprefixed clients, like httpd_t.
> But I would like to handle it as a procedure created or relabeled
> by database administrator.
> Basically, we consider user defined procedures are untrusted, so
> it should be checked before it becomes available for all the clients.
> So, we don't allow to install them as system internal entities, and
> don't allow unconfined domains to execute them directly.
>
> My preference is the user_sepgsql_xxxx_t is also assigned to
> procedures created by unprivileged and unprfixed client.
>
> A schema for temporary obejcts
> ------------------------------
> * The sepgsql_schema_t is the default type for schema objects, and
> rest of database objects within the schema is labeled with the chain
> of TYPE_TRANSITION rules.
> We have a characteristic scheme named as "pg_temp_*". Any database
> objects within the schema are cleared after the session closed,
> so its contents are always session local. We would like to assign
> special types on the temporary schema and delivered database objects
> withing the schema. In addition, users can create and use these
> database objects independently from the sepgsql_enable_users_ddl.
>
> Booelean behavior: sepgsql_enable_users_ddl
> -------------------------------------------
> * Because the current design does not care about actions on schema
> objects, we need to assign separated label (sepgsql_sysobj_t) on
> system informations and apply checks as row-level controls.
> But db_schema object class enables to control user's DDLs in
> the schema level checks mainly, so now sepgsql_enable_user_ddl
> focuses on db_schema class permissions and {create drop setattr}
> for any other database objects.
> The attached patch allows users to modify tuples with sepgsql_sysobj_t
> but not allows columns/tables. It means user can define database
> objects with proper way (like CREATE TABLE), but prevents to
> manipulate system information by hand.
> In addition, this boolean controls only user_sepgsql_xxxx_t.
> The unprefixed types are always not allowed to modify its definition
> by unprivileges users.
>
> db_table:{lock} for reader actions
> ----------------------------------
> * db_table:{lock} is also necessary for reader side actions due to the
> implementation reason.
> In PostgreSQL, FK constraints are implemented as trigger functions.
> It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
> and run a secondary query to check whether the action satisfies
> FK constraints or not.
> This query is described as:
> SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
>
> The "FOR SHARE" clause means explicit table lock and requires
> db_table:{lock} permission. If we don't allow unpriv clients to
> lock read-only tables, it disables to set up FK constraint which
> refers read-only tables.
>
> Miscellaneous changes
> ---------------------
> * The security context of a new database is decided via type_transition
> on the server process's context. It enables to avoid conflicts when
> we have multiple DBMSs in a system.
> * It allows postgresql_t domain to write out messages to system audit.
> * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
> * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
> because we don't need to run trusted procedure implicitly.
> * Most of postgresql_role() are shared with postgresql_unpriv_client(),
> except for "role $1 types sepgsql_trusted_proc_t;"
> * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
>
> Thanks,
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
> I am referring to things like:
>
> mlsconstrain { db_tuple } { use select }
> (( l1 dom l2 ) or
> (( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
> ( t1 == mlsdbread ) or
> ( t2 == mlstrustedobject ));
I noticed the db_xxx:{use} permission remained here. :-)
> where t1 == mlsdbread seems to imply an object is trusted to read
> strictly dominating objects. Unless I am missing the meaning here, I
> would call this a MAC override. I realize there is no concept of a TE
> override, but MLS is part of MAC, no? And, this violates B&L rules. This
> is something we would control with a Security Administrator "role". Or,
> is this mlsdbread something that is impossible to give to a domain in a
> DBMS policy?
It is different from my usage of terms.
Some of domains are allowed to access the tuple, and others are
disallowed as the result of access controls using the security
policy.
I understood the term of "MAC override" to express what actions
are allowed without any checks based on security policy, as if
root stuff can ignore DAC checks.
Thanks,
--
KaiGai Kohei <[email protected]>
Chris,
The attached patch also reworks and fixes a few bugs in MLS/MCS policy
for SE-PostgreSQL. Could you check it please?
List of updates:
* db_catalog, db_schema, db_sequence classes are newly constrained.
* Removed permissions (db_database:{get_param set_param} and
db_xxx:{use}) have gone away.
* bugfix: MCS didn't constrain db_xxx:{getattr} permission.
* bugfix: MCS didn't constrain db_procedure:{ drop getattr
setattr relabelfrom } permission.
* bugfix: MLS didn't constrain writer permission in db_procedure class.
Thanks,
KaiGai Kohei wrote:
> As we have discussed for the recent week, I have a plan to rework
> some of security policy for SE-PostgreSQL.
>
> The attached patch adds the significan changes, as follows.
> Could you give me any suggestion, approval or opposition?
>
> New object classes and permissions
> ----------------------------------
> * db_catalog class
> It shows the top level namespace in the database, and has a capability
> to store a set of schemas. Some of implementation does not support
> catalogs. In this case, we simply ignore this class and any schemas
> are placed under the db_database directly.
>
> It defines the following four permissions and inherited ones:
> { search add_object remove_object associate }
>
> Client should have db_catalog:{search} on the catalog when he refers
> any schemas under the catalog, and he should also have
> db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
> when he tries to add or remove a shema within the catalog.
> These permissions are an analogy of dir object class.
>
> The db_catalog:{associate}, which I've not introduced yet but noticed
> its necessity, is also checked when we create or relabel a schema
> within the catalog, and the schema should have db_catalog:{associate}
> on the catalog. It is an analogy of filesystem:{associate}.
> It prevents a schema is labeled unexpectedly.
>
> * db_schema class
> It shows the second level namespace in the database, but it may be
> the top level one in some of implementation (like PostgreSQL).
> It has a capability to store a set of database objects (tables,
> procedures and so on).
>
> It defines the following four permissions and inherited ones:
> { search add_object remove_object associate }
> Their meanings are similar to ones in db_catalog class except for
> the schema to be replaced by database objects.
>
> Its security context can be computed with TYPE_TRANSITION between
> the client as a subject and the database (or catalog, if availabel)
> as a target.
>
> * db_sequence class
> It shows the sequential number generator objects. We can also use
> them as a communication channel between two domains, so it is
> necessary to apply security policy.
>
> It inherits common database and defines the following two permissions:
> { get_value set_value }
> Client should have db_sequence:{get_value} when he fetch a value from
> the sequence generator, and db_sequence:{set_value} when he set a
> discretionary value. When he fetch a value from the sequence object,
> it implicitly increments internal counter, but it is covered by the
> get_value permission.
>
> Its security context can be computed with TYPE_TRANSITION between
> the client as a subject and the schema as a target.
>
> Change definition of object classes
> -----------------------------------
> * db_database class
> The db_database:{get_param set_param} is removed because these two
> permissions are nonsense.
> The db_database:{superuser} is newly added. It is checked when
> client perform as database superuser. Stephen suggested it can
> be separated to more finer grained privileges. It makes sense,
> but this kind of separation which focuses on PostgreSQL makes
> hard to port the concept for other database management systems.
>
> * db_table/db_column/db_tuple:{use} permission
> The db_xxx:{use} permission is integrated into db_xxx:{select}
> permission, because it can hide the risk to infer invisible
> information easily with well considered WHERE clauses.
>
> user_sepgsql_xxxx_t types
> -------------------------
> * Currently, sepgsql_proc_t is assigned to the procedures created
> by unprivileged and unprefixed clients, like httpd_t.
> But I would like to handle it as a procedure created or relabeled
> by database administrator.
> Basically, we consider user defined procedures are untrusted, so
> it should be checked before it becomes available for all the clients.
> So, we don't allow to install them as system internal entities, and
> don't allow unconfined domains to execute them directly.
>
> My preference is the user_sepgsql_xxxx_t is also assigned to
> procedures created by unprivileged and unprfixed client.
>
> A schema for temporary obejcts
> ------------------------------
> * The sepgsql_schema_t is the default type for schema objects, and
> rest of database objects within the schema is labeled with the chain
> of TYPE_TRANSITION rules.
> We have a characteristic scheme named as "pg_temp_*". Any database
> objects within the schema are cleared after the session closed,
> so its contents are always session local. We would like to assign
> special types on the temporary schema and delivered database objects
> withing the schema. In addition, users can create and use these
> database objects independently from the sepgsql_enable_users_ddl.
>
> Booelean behavior: sepgsql_enable_users_ddl
> -------------------------------------------
> * Because the current design does not care about actions on schema
> objects, we need to assign separated label (sepgsql_sysobj_t) on
> system informations and apply checks as row-level controls.
> But db_schema object class enables to control user's DDLs in
> the schema level checks mainly, so now sepgsql_enable_user_ddl
> focuses on db_schema class permissions and {create drop setattr}
> for any other database objects.
> The attached patch allows users to modify tuples with sepgsql_sysobj_t
> but not allows columns/tables. It means user can define database
> objects with proper way (like CREATE TABLE), but prevents to
> manipulate system information by hand.
> In addition, this boolean controls only user_sepgsql_xxxx_t.
> The unprefixed types are always not allowed to modify its definition
> by unprivileges users.
>
> db_table:{lock} for reader actions
> ----------------------------------
> * db_table:{lock} is also necessary for reader side actions due to the
> implementation reason.
> In PostgreSQL, FK constraints are implemented as trigger functions.
> It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
> and run a secondary query to check whether the action satisfies
> FK constraints or not.
> This query is described as:
> SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
>
> The "FOR SHARE" clause means explicit table lock and requires
> db_table:{lock} permission. If we don't allow unpriv clients to
> lock read-only tables, it disables to set up FK constraint which
> refers read-only tables.
>
> Miscellaneous changes
> ---------------------
> * The security context of a new database is decided via type_transition
> on the server process's context. It enables to avoid conflicts when
> we have multiple DBMSs in a system.
> * It allows postgresql_t domain to write out messages to system audit.
> * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
> * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
> because we don't need to run trusted procedure implicitly.
> * Most of postgresql_role() are shared with postgresql_unpriv_client(),
> except for "role $1 types sepgsql_trusted_proc_t;"
> * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
>
> Thanks,
>
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-mls-fixes.patch
Type: text/x-patch
Size: 7575 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090401/c475e053/attachment-0001.bin