Andy Warner wrote:
>
> KaiGai Kohei wrote:
>> The attached patch is the first one in the series of reworks for
>> the SE-PostgreSQL security policy.
>>
>> It updates the following items.
>>
>> * Changes in the definition of object classes
>>
>> This patch add new three object classes and modifies the definition
>> of a few object classes.
>> - db_database:{get_param set_param} is removed due to nonsense.
>> - db_database:{superuser} is added to restrict privileges of
>> database superuser.
>> - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>> - New object classes: db_catalog, db_schema and db_sequence are added.
>>
>>
> In the RUBIX policy I used the db_table use permission (could be called
> open) to have a simple way to control access to the table as a whole,
> much like a file open permission. While not absolutely necessary, I
> think it is valuable. The other uses of the use permission I did not
> use. Also, see my related comment below on the catalog/schema object
> permissions.
It is incorrect use of use permission.
The use permission was used when we refer the table, but its contents
were not read directly, like:
SELECT count(*) FROM t WHERE x > 0;
This query refers the table t and column t.x, but its contents are
consumed by backend internally. But it was pointed out such kind of
discrimination is nonsense in pgsql-hackers.
If you need something like "open" permission on the db_table class,
what you should do is submitting a proposition for a new permission.
It is not a right way to apply existing one for another purpose.
If SE-PostgreSQL does not care about, it simply ignore the permission
like as db_catalog class.
>> In the previous design, we have the following object hierarchy:
>> [db_database]
>> + [db_table]
>> | + [db_column]
>> | + [db_tuple]
>> + [db_procedure]
>> + [db_blob]
>>
>> The newly added db_schema should be placed between the db_database and
>> the db_table and others. TYPE_TRANSITION rules follows the revised design.
>>
>> [db_database]
>> + [db_schema]
>> | + [db_table]
>> | | + [db_column]
>> | | + [db_tuple]
>> | + [db_procedure]
>> | + [db_sequence] (newly added object class)
>> + [db_blob]
>>
>> (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
>> although it can be used to communicate channel between multiple
>> domains. So, it needs to be placed under the database.
>>
>> Currently, SE-PostgreSQL does not use db_catalog class, but it can be
>> used for other DBMS's.
>>
>> In addition, this patch changes something.
>>
>> o The trusted procedure (sepgsql_trusted_proc_t) lost the
>> db_database:{superuser} privilege, because it is invoked by
>> unprived users to over the MAC restriction for a certain
>> purpose, but it does not need to allow superpower in DAC.
>>
> Is it intended that the superuser privilege give only DAC override or
> both MAC and DAC? Specifically, is it intended to override MLS or Type
> enforcement?
If the client does not have db_database:{superuser} privilege,
he cannot perform as database superuser, even if the DAC policy
allows. Please note that MAC stuff does not have a concept of
superuser. All the player need to be checked by the reference
monitor and its security policy.
>> o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
>> db_procedure:{install} privilege, because once installed procedure
>> as a system internal entity can be invoked implicitly.
>> We should not install trusted procedures for the purpose.
>>
>> o The db_schema:{add_object remove_object} newly added are controled
>> via the "sepgsql_enable_users_ddl" boolean.
>> Now we control user's DDLs on uncategorized objects as row-level
>> checks on sepgsql_sysobj_t, but it can be revised with adding
>> db_schema object class.
>>
> I think this also needs the equivalent of a "search" permission (or
> open, or use). This gives a nice way to control some access to an entire
> schema. That is, we want to use the schema (and catalog) as a mechanism
> to cut off users from entire subtrees. This helps to ensure that a user
> does not gain access to a newly created subordinate object. So, if a
> user does not have search for a schema (or catalog), there is no way
> they can access any present or future object in that schema (or
> catalog). Analogous to a directory. Without this search control I would
> continue to use the dir object class.
This boolean controls the capability of DDL statement from unpriv
users. They should access existing objects via DML, even if they
cannot modify the definition of tables and so on.
I don't think your suggestion is correct one.
>> o type_transition for user_sepgsql_XXXX_t is moved to outside of
>> tunable_policy(`...'). IIRC, I said these should be inside of
>> the tunable, but unprive ones cannot create/drop tables labeled
>> as sepgsql_XXX_t anyway when the boolean is disabled.
>> So, I reconsidered it should be placed out of the tunable.
>>
>> o {create drop setattr} permission for user_sepgsql_XXX is moved
>> to inside of the tunable_policy, even if it is db_procedure
>> class. I wonder why we didn't control CREATE FUNCTION statement
>> by unpriv domains.
>>
>> o db_blob:{import export} on user_sepgsql_blob_t is allowed to
>> unpriv domains. It seems to me a strange behavior that it is
>> not allowed on the object created by unpriv domain itself.
>>
>> * Remaining items
>> o When we allows an unpriv domain to access SE-PostgreSQL using
>> postgresql_unpriv_client(), its default labeling behavior is
>> same as unconfined domains. For example, functions created by
>> them are labeled as "sepgsql_proc_t".
>> Now I'm considering it should be user_sepgsql_XXXX_t, because
>> I would like to handle unprefixed types as an object created
>> by database administrator (unconfined domains).
>> It helps correctness of db_procedure:{install} permission.
>>
>> o Because of db_schema object class, we can control user's DDLs
>> without ad-hoc using row-level security on sepgsql_sysobj_t
>> class. Now I think its purpose should be changed to prevent
>> users accesses system catalogs directly.
>>
> Are you implying here the need for something like a search or open
> permissions as I suggested above? If so, please disregard my previous
> comment:-)
>> Thanks,
>>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
--
KaiGai Kohei <[email protected]>
KaiGai Kohei wrote:
> Andy Warner wrote:
>
>> KaiGai Kohei wrote:
>>
>>> The attached patch is the first one in the series of reworks for
>>> the SE-PostgreSQL security policy.
>>>
>>> It updates the following items.
>>>
>>> * Changes in the definition of object classes
>>>
>>> This patch add new three object classes and modifies the definition
>>> of a few object classes.
>>> - db_database:{get_param set_param} is removed due to nonsense.
>>> - db_database:{superuser} is added to restrict privileges of
>>> database superuser.
>>> - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>>> - New object classes: db_catalog, db_schema and db_sequence are added.
>>>
I guess I should have asked before, is there is any proposed permission
set for the three new object classes mentioned above?
>>>
>>>
>> In the RUBIX policy I used the db_table use permission (could be called
>> open) to have a simple way to control access to the table as a whole,
>> much like a file open permission. While not absolutely necessary, I
>> think it is valuable. The other uses of the use permission I did not
>> use. Also, see my related comment below on the catalog/schema object
>> permissions.
>>
>
> It is incorrect use of use permission.
> The use permission was used when we refer the table, but its contents
> were not read directly, like:
>
> SELECT count(*) FROM t WHERE x > 0;
>
> This query refers the table t and column t.x, but its contents are
> consumed by backend internally. But it was pointed out such kind of
> discrimination is nonsense in pgsql-hackers.
>
> If you need something like "open" permission on the db_table class,
> what you should do is submitting a proposition for a new permission.
> It is not a right way to apply existing one for another purpose.
>
> If SE-PostgreSQL does not care about, it simply ignore the permission
> like as db_catalog class.
>
I understand now and then the intent of the use permission. If I need
functionality from the database object classes that is not provided,
then I have little option other than use something in a way that is not
"correct". Such as my use of the dir object class to account for not
having object classes for schemata and catalog. And, from a user's point
of view, a permission called "use" works well with being to (or not) use
a table. So, I think it was quite reasonable to use it for my purposes.
I'm not sure what the official means of proposing a new permission is,
but I thought this thread was a discussion of any changes that may need
to made to the database policy, and since you are removing the use
permission, I thought it relevant. Call the permission "use" or call if
"open", the intent of my comment was to suggest that policy support for
the semantics of how I used the use permission would be good.
>
>>> In the previous design, we have the following object hierarchy:
>>> [db_database]
>>> + [db_table]
>>> | + [db_column]
>>> | + [db_tuple]
>>> + [db_procedure]
>>> + [db_blob]
>>>
>>> The newly added db_schema should be placed between the db_database and
>>> the db_table and others. TYPE_TRANSITION rules follows the revised design.
>>>
>>> [db_database]
>>> + [db_schema]
>>> | + [db_table]
>>> | | + [db_column]
>>> | | + [db_tuple]
>>> | + [db_procedure]
>>> | + [db_sequence] (newly added object class)
>>> + [db_blob]
>>>
>>> (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
>>> although it can be used to communicate channel between multiple
>>> domains. So, it needs to be placed under the database.
>>>
>>> Currently, SE-PostgreSQL does not use db_catalog class, but it can be
>>> used for other DBMS's.
>>>
>>> In addition, this patch changes something.
>>>
>>> o The trusted procedure (sepgsql_trusted_proc_t) lost the
>>> db_database:{superuser} privilege, because it is invoked by
>>> unprived users to over the MAC restriction for a certain
>>> purpose, but it does not need to allow superpower in DAC.
>>>
>>>
>> Is it intended that the superuser privilege give only DAC override or
>> both MAC and DAC? Specifically, is it intended to override MLS or Type
>> enforcement?
>>
>
> If the client does not have db_database:{superuser} privilege,
> he cannot perform as database superuser, even if the DAC policy
> allows. Please note that MAC stuff does not have a concept of
> superuser. All the player need to be checked by the reference
> monitor and its security policy.
>
>
>>> o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
>>> db_procedure:{install} privilege, because once installed procedure
>>> as a system internal entity can be invoked implicitly.
>>> We should not install trusted procedures for the purpose.
>>>
>>> o The db_schema:{add_object remove_object} newly added are controled
>>> via the "sepgsql_enable_users_ddl" boolean.
>>> Now we control user's DDLs on uncategorized objects as row-level
>>> checks on sepgsql_sysobj_t, but it can be revised with adding
>>> db_schema object class.
>>>
>>>
>> I think this also needs the equivalent of a "search" permission (or
>> open, or use). This gives a nice way to control some access to an entire
>> schema. That is, we want to use the schema (and catalog) as a mechanism
>> to cut off users from entire subtrees. This helps to ensure that a user
>> does not gain access to a newly created subordinate object. So, if a
>> user does not have search for a schema (or catalog), there is no way
>> they can access any present or future object in that schema (or
>> catalog). Analogous to a directory. Without this search control I would
>> continue to use the dir object class.
>>
>
> This boolean controls the capability of DDL statement from unpriv
> users. They should access existing objects via DML, even if they
> cannot modify the definition of tables and so on.
> I don't think your suggestion is correct one.
>
I think you misunderstood me. I was not commenting on the boolean at
all. I was commenting on the reference to "db_schema:{add_object
remove_object}" thinking (assuming) that add_object and remove_object
were the only two permission given to the db_schema object class. Is
this the intent? I did not see anywhere in the email that defined the
set of permissions the db_schema (or db_catalog) would have.
>
>>> o type_transition for user_sepgsql_XXXX_t is moved to outside of
>>> tunable_policy(`...'). IIRC, I said these should be inside of
>>> the tunable, but unprive ones cannot create/drop tables labeled
>>> as sepgsql_XXX_t anyway when the boolean is disabled.
>>> So, I reconsidered it should be placed out of the tunable.
>>>
>>> o {create drop setattr} permission for user_sepgsql_XXX is moved
>>> to inside of the tunable_policy, even if it is db_procedure
>>> class. I wonder why we didn't control CREATE FUNCTION statement
>>> by unpriv domains.
>>>
>>> o db_blob:{import export} on user_sepgsql_blob_t is allowed to
>>> unpriv domains. It seems to me a strange behavior that it is
>>> not allowed on the object created by unpriv domain itself.
>>>
>>> * Remaining items
>>> o When we allows an unpriv domain to access SE-PostgreSQL using
>>> postgresql_unpriv_client(), its default labeling behavior is
>>> same as unconfined domains. For example, functions created by
>>> them are labeled as "sepgsql_proc_t".
>>> Now I'm considering it should be user_sepgsql_XXXX_t, because
>>> I would like to handle unprefixed types as an object created
>>> by database administrator (unconfined domains).
>>> It helps correctness of db_procedure:{install} permission.
>>>
>>> o Because of db_schema object class, we can control user's DDLs
>>> without ad-hoc using row-level security on sepgsql_sysobj_t
>>> class. Now I think its purpose should be changed to prevent
>>> users accesses system catalogs directly.
>>>
>>>
>> Are you implying here the need for something like a search or open
>> permissions as I suggested above? If so, please disregard my previous
>> comment:-)
>>
>>> Thanks,
>>>
>>>
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090327/823bbafa/attachment.html
Andy Warner wrote:
>
>
> KaiGai Kohei wrote:
>> Andy Warner wrote:
>>
>>> KaiGai Kohei wrote:
>>>
>>>> The attached patch is the first one in the series of reworks for
>>>> the SE-PostgreSQL security policy.
>>>>
>>>> It updates the following items.
>>>>
>>>> * Changes in the definition of object classes
>>>>
>>>> This patch add new three object classes and modifies the definition
>>>> of a few object classes.
>>>> - db_database:{get_param set_param} is removed due to nonsense.
>>>> - db_database:{superuser} is added to restrict privileges of
>>>> database superuser.
>>>> - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>>>> - New object classes: db_catalog, db_schema and db_sequence are added.
>>>>
>
> I guess I should have asked before, is there is any proposed permission
> set for the three new object classes mentioned above?
In the attached patch:
--------
+# More database stuff
+class db_catalog
+inherits database
+{
+ search
+ add_object
+ remove_object
+}
+
+class db_schema
+inherits database
+{
+ search
+ add_object
+ remove_object
+}
+
+class db_sequence
+inherits database
+{
+ get_value
+ set_value
+}
--------
The db_catalog, db_schema and db_sequence inherit six permissions
from common database object.
create ... should be checked when the object is created
drop ... should be checked when the object is dropped
getattr ... should be checked when its metadata is changed
setattr ... should be checked when its metadata is changed
relabelfrom ... should be checked when its security context is changed
relabelto ... same as relabelfrom
And these object class has its own permission:
search ... should be checked when a object under the namespace
is refered.
add_object ... should be checked when we add a object under the namespace
remove_object ... should be checked when we remove a object under the namespace
(*) namespace means catalog or schema, here.
get_value ... should be checked when we fetch a value from the sequence
set_value ... should be checked when we reset the sequence
> I understand now and then the intent of the use permission. If I need
> functionality from the database object classes that is not provided,
> then I have little option other than use something in a way that is not
> "correct". Such as my use of the dir object class to account for not
> having object classes for schemata and catalog. And, from a user's point
> of view, a permission called "use" works well with being to (or not) use
> a table. So, I think it was quite reasonable to use it for my purposes.
> I'm not sure what the official means of proposing a new permission is,
> but I thought this thread was a discussion of any changes that may need
> to made to the database policy, and since you are removing the use
> permission, I thought it relevant. Call the permission "use" or call if
> "open", the intent of my comment was to suggest that policy support for
> the semantics of how I used the use permission would be good.
I don't intend you to force my opinion.
However, it's not unclear the purpose of your "use" permission on
db_table class. If you prevent users to access the tabel, it can
be controled via select, update, delete, insert and other permission.
I can understand "search" permission on the db_catalog and db_schema
as an analogy of directory.
But it is not suitable for tables, procedures or others, because it
does not intend to hide existence of these object.
For example, when "cat.schm.tbl_A" is invisible, I can try to create
a table with same name then get an error. It enables us to know
existence of the table, so such kind of permission is nonsense.
>>>> o The db_schema:{add_object remove_object} newly added are controled
>>>> via the "sepgsql_enable_users_ddl" boolean.
>>>> Now we control user's DDLs on uncategorized objects as row-level
>>>> checks on sepgsql_sysobj_t, but it can be revised with adding
>>>> db_schema object class.
>>>>
>>>>
>>> I think this also needs the equivalent of a "search" permission (or
>>> open, or use). This gives a nice way to control some access to an entire
>>> schema. That is, we want to use the schema (and catalog) as a mechanism
>>> to cut off users from entire subtrees. This helps to ensure that a user
>>> does not gain access to a newly created subordinate object. So, if a
>>> user does not have search for a schema (or catalog), there is no way
>>> they can access any present or future object in that schema (or
>>> catalog). Analogous to a directory. Without this search control I would
>>> continue to use the dir object class.
>>>
>>
>> This boolean controls the capability of DDL statement from unpriv
>> users. They should access existing objects via DML, even if they
>> cannot modify the definition of tables and so on.
>> I don't think your suggestion is correct one.
>>
> I think you misunderstood me. I was not commenting on the boolean at
> all. I was commenting on the reference to "db_schema:{add_object
> remove_object}" thinking (assuming) that add_object and remove_object
> were the only two permission given to the db_schema object class. Is
> this the intent? I did not see anywhere in the email that defined the
> set of permissions the db_schema (or db_catalog) would have.
As I noted above, the db_schema object class has 9 permissions in total.
It also includes "search" permission.
Thanks,
--
KaiGai Kohei <[email protected]>