Re: [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[Andy Warner <warner@rubix.com>]

[-- Attachment #1: Type: text/plain, Size: 8457 bytes --]



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@tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>>     
>
>
>   

[-- Attachment #2: Type: text/html, Size: 9520 bytes --]