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 <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql.1.patch
Type: text/x-patch
Size: 30699 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101210/06e9b492/attachment-0001.bin
On 12/10/2010 10:49 AM, KaiGai Kohei wrote:
> 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.
>From my point of view, as a rubix folk, I see no disadvantage in using
the db_schema class for catalogs. As we are now overloading the dir
object class, using the db_schema for both schemata and catalogs is an
improvement. For us in the foreseeable future, there is no functional
distinction.
I do think that the SQL spec does allow things to be associated with a
named schema that may not be associated with a catalog. For instance, a
character set. But, don't quote me on that:-)
Forgive me for my ignorance, but when a patch like this is submitted to
the refpolicy, will it eventually make it into Fedora and/or RHEL 6?
> 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,
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101210/eccd8e4e/attachment.html
(2010/12/10 21:18), Andy Warner wrote:
>
>
> On 12/10/2010 10:49 AM, KaiGai Kohei wrote:
>> 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.
>
> From my point of view, as a rubix folk, I see no disadvantage in using
> the db_schema class for catalogs. As we are now overloading the dir object
> class, using the db_schema for both schemata and catalogs is an improvement.
> For us in the foreseeable future, there is no functional distinction.
>
> I do think that the SQL spec does allow things to be associated with
> a named schema that may not be associated with a catalog. For instance,
> a character set. But, don't quote me on that:-)
>
If we would need a special permission to set a character set, we may
provide individual object classes. But it seems to me 'setattr' permission
covers this case, at least.
> Forgive me for my ignorance, but when a patch like this is submitted to
> the refpolicy, will it eventually make it into Fedora and/or RHEL 6?
>
Next to the getting merged, the reference policy (with the patch) will be
integrated to Fedora. However, I don't think RHEL6 applies new features
any more from now, except for bug fixes. It was feature frozen long before.
Thanks,
>> 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,
>>
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
KaiGai Kohei <[email protected]>
How about getting inclusion of this patch?
These new object classes and corresponding rules are necessary
to run SE-PostgreSQL based on the upcoming v9.1.
Because I gave the highest priority to upstream the feature,
it will have a limited functionality set in this version.
But several facilities to support label based mandatory access
control have been upstreamed (such as SECURITY LABEL statement).
It is quite worthful to run this version on the default security
policy.
Thanks,
(2010/12/10 18:49), KaiGai Kohei wrote:
> 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 <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/14/2011 01:19 AM, KaiGai Kohei wrote:
> How about getting inclusion of this patch?
>
> These new object classes and corresponding rules are necessary
> to run SE-PostgreSQL based on the upcoming v9.1.
>
> Because I gave the highest priority to upstream the feature,
> it will have a limited functionality set in this version.
> But several facilities to support label based mandatory access
> control have been upstreamed (such as SECURITY LABEL statement).
> It is quite worthful to run this version on the default security
> policy.
>
> Thanks,
>
> (2010/12/10 18:49), KaiGai Kohei wrote:
>> 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, I believe we have your patches in Fedora and RHEL6, If not
please ping me to add them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0wV6wACgkQrlYvE4MpobPLHQCfciB+vT9o1Vab6CQYy3N2THgY
6p8AoJHU8wl1B1XnkG48Su6kfLXI4UFM
=+aaW
-----END PGP SIGNATURE-----
On 12/10/10 04:49, KaiGai Kohei wrote:
> The attached patch adds a few database object classes, as follows:
Merged. I moved one tunable block, and added missing object class
dependencies in postgresql.te.
> * 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.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
>> How about getting inclusion of this patch?
>>
>> These new object classes and corresponding rules are necessary
>> to run SE-PostgreSQL based on the upcoming v9.1.
>>
:
> KaiGai, I believe we have your patches in Fedora and RHEL6, If not
> please ping me to add them.
I'm not certain about the latest RHEL6 policy, because I don't know
the way to reference its repository.
However, these new object classes are not included within the latest
Fedora policy right now. I checked it using "fedpkg co selinux-policy".
Do I see the same tree with you, don't I?
Thanks,
--
KaiGai Kohei <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/15/2011 07:48 AM, Kohei KaiGai wrote:
>>> How about getting inclusion of this patch?
>>>
>>> These new object classes and corresponding rules are necessary
>>> to run SE-PostgreSQL based on the upcoming v9.1.
>>>
> :
>> KaiGai, I believe we have your patches in Fedora and RHEL6, If not
>> please ping me to add them.
>
> I'm not certain about the latest RHEL6 policy, because I don't know
> the way to reference its repository.
> However, these new object classes are not included within the latest
> Fedora policy right now. I checked it using "fedpkg co selinux-policy".
> Do I see the same tree with you, don't I?
>
> Thanks,
Please send me your latest patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk00XjgACgkQrlYvE4MpobMefQCg4dQ7Ly32ED1hGfxlsc8EVqSQ
/vUAn1cMj5jooXAiwm3+McKnI53ypM0I
=FmtN
-----END PGP SIGNATURE-----
(2011/01/18 0:20), Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/15/2011 07:48 AM, Kohei KaiGai wrote:
>>>> How about getting inclusion of this patch?
>>>>
>>>> These new object classes and corresponding rules are necessary
>>>> to run SE-PostgreSQL based on the upcoming v9.1.
>>>>
>> :
>>> KaiGai, I believe we have your patches in Fedora and RHEL6, If not
>>> please ping me to add them.
>>
>> I'm not certain about the latest RHEL6 policy, because I don't know
>> the way to reference its repository.
>> However, these new object classes are not included within the latest
>> Fedora policy right now. I checked it using "fedpkg co selinux-policy".
>> Do I see the same tree with you, don't I?
>>
>> Thanks,
> Please send me your latest patch.
>
The attached two are for RHEL6 and Fedora. These patches are made up
based on selinux-policy-3.7.19-29.el6 and selinux-policy-3.9.12-7.fc15.
Don't forget to add the following line in %fileList macro of the specfile
%config %{_sysconfdir}/selinux/%1/contexts/sepgsql_contexts \
Thanks,
--
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: selinux-policy-sepgsql.rhel6.patch
Type: application/octect-stream
Size: 39879 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110118/362c949e/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: selinux-policy-sepgsql.fedora.patch
Type: application/octect-stream
Size: 40240 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110118/362c949e/attachment-0003.bin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/18/2011 01:03 AM, KaiGai Kohei wrote:
> (2011/01/18 0:20), Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/15/2011 07:48 AM, Kohei KaiGai wrote:
>>>>> How about getting inclusion of this patch?
>>>>>
>>>>> These new object classes and corresponding rules are necessary
>>>>> to run SE-PostgreSQL based on the upcoming v9.1.
>>>>>
>>> :
>>>> KaiGai, I believe we have your patches in Fedora and RHEL6, If not
>>>> please ping me to add them.
>>>
>>> I'm not certain about the latest RHEL6 policy, because I don't know
>>> the way to reference its repository.
>>> However, these new object classes are not included within the latest
>>> Fedora policy right now. I checked it using "fedpkg co selinux-policy".
>>> Do I see the same tree with you, don't I?
>>>
>>> Thanks,
>> Please send me your latest patch.
>>
> The attached two are for RHEL6 and Fedora. These patches are made up
> based on selinux-policy-3.7.19-29.el6 and selinux-policy-3.9.12-7.fc15.
>
> Don't forget to add the following line in %fileList macro of the specfile
> %config %{_sysconfdir}/selinux/%1/contexts/sepgsql_contexts \
>
> Thanks,
It looks like your stuff is now in
selinux-policy-3.9.13-2.fc15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk01ogoACgkQrlYvE4MpobNSjACgmPqSmScrwalpoWA/zTtQiB8n
/JIAoJQFKt9X/06JBWHQz/MPGFXhpJnV
=qfaA
-----END PGP SIGNATURE-----
On 01/18/2011 02:22 PM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/18/2011 01:03 AM, KaiGai Kohei wrote:
>> (2011/01/18 0:20), Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 01/15/2011 07:48 AM, Kohei KaiGai wrote:
>>>>>> How about getting inclusion of this patch?
>>>>>>
>>>>>> These new object classes and corresponding rules are necessary
>>>>>> to run SE-PostgreSQL based on the upcoming v9.1.
>>>>>>
>>>> :
>>>>> KaiGai, I believe we have your patches in Fedora and RHEL6, If not
>>>>> please ping me to add them.
>>>> I'm not certain about the latest RHEL6 policy, because I don't know
>>>> the way to reference its repository.
>>>> However, these new object classes are not included within the latest
>>>> Fedora policy right now. I checked it using "fedpkg co selinux-policy".
>>>> Do I see the same tree with you, don't I?
>>>>
>>>> Thanks,
>>> Please send me your latest patch.
>>>
>> The attached two are for RHEL6 and Fedora. These patches are made up
>> based on selinux-policy-3.7.19-29.el6 and selinux-policy-3.9.12-7.fc15.
>>
>> Don't forget to add the following line in %fileList macro of the specfile
>> %config %{_sysconfdir}/selinux/%1/contexts/sepgsql_contexts \
>>
>> Thanks,
> It looks like your stuff is now in
> selinux-policy-3.9.13-2.fc15
Yes, it should be there.
Regards,
Miroslav
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk01ogoACgkQrlYvE4MpobNSjACgmPqSmScrwalpoWA/zTtQiB8n
> /JIAoJQFKt9X/06JBWHQz/MPGFXhpJnV
> =qfaA
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>> It looks like your stuff is now in
>> selinux-policy-3.9.13-2.fc15
> Yes, it should be there.
>
Thanks for your quick job.
How about backporting it to RHEL6?
Thanks,
--
KaiGai Kohei <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/18/2011 09:40 AM, Kohei KaiGai wrote:
>>> It looks like your stuff is now in
>>> selinux-policy-3.9.13-2.fc15
>> Yes, it should be there.
>>
> Thanks for your quick job.
>
> How about backporting it to RHEL6?
>
> Thanks,
Yes I think that we should get it into RHEL6 also.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk01uSMACgkQrlYvE4MpobNPjQCgwFg5MTGcWzv4UmaRChMh02l+
vOwAnA2tNe+b4cOP7CBS6OhFHqBAtTBW
=bNLZ
-----END PGP SIGNATURE-----