Andy Warner wrote:
>
>
> KaiGai Kohei wrote:
>> As I noted in the previous message, SE-PostgreSQL is postponed to
>> the PostgreSQL v8.5 after the long discussion in the pgsql-hackers
>> list, unfortunately.
>> However, it also mean a good chance to revise its design because
>> we have a few months before v8.5 development cycle launched.
>>
>> 1. Changes in object classes and access vectors
>> - add db_database:{superuser} permission
>>
>> - remove db_database:{get_param set_param} permission
>> - remove db_table/db_column/db_tuple:{use} permission
>>
>> Please refer the previous messages for them.
>>
>> - add new object class "db_schema"
>> As Andy noted, we directly put database objects under the
>> db_database class directly. But, some of database objects
>> are created under a schema object.
>> In other word, RDBMS's design has three level hierachy as:
>> <database> (<-- some DBMSs calls it as <catalog>)
>> + <schema>
>> + <tables>, <procedures>, ...
>>
>> Now, we control user's DDL statement via permissions on
>> the sepgsql_sysobj_t type as row-level controls.
>> But I think db_schema object class here is meaningful
>> to match SQL's design and analogy to the dir class.
>>
>> The new db_schema object class inherits six permissions
>> from common database objects, and defines three its own
>> permissions: add_object, remove_object, usage
>>
> I would suggest that the SQL catalog object should also be supported.
> Though not common in implementation, it is part of the SQL spec. Our
> DBMS (Trusted RUBIX) supports it, and for us it is basically another
> level in the naming. (database.catalog.schema.table). I would suggest
> that a db_catalog object be included with the same basic semantics as
> the db_schema object.
>
Is there more information available about how Trusted RUBIX uses SELinux? I see
on the webpage a brief mention of it but no detailed page like the other access
control models, nor in the security policy manager data sheet.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
