Re: [PATCH] SE-PostgreSQL Security Policy

[Joshua Brindle <method@manicmethod.com>]

Christopher J. PeBenito wrote:
> On Wed, 2008-02-27 at 17:00 +0900, Kohei KaiGai wrote:
>   
>> The attached patch provides security policies related to
>> SE-PostgreSQL.
>>
>> The followings are updates/unchanges from the previous version
>> submitted
>> at two weeks ago. These updates replaced most of the part in the
>> previous
>> one.
>>
>> - The targets of this patch are moved to services/postgresql.*,
>>    although the previous one added new entries.
>>     
>
>   
>> +tunable_policy(`sepgsql_enable_auditallow',`
>> +       auditallow domain sepgsql_database_type  : db_database all_db_database_perms;
>> +       auditallow domain sepgsql_table_type     : db_table all_db_table_perms;
>> +       auditallow domain sepgsql_table_type     : db_column all_db_column_perms;
>> +       auditallow domain sepgsql_procedure_type : db_procedure all_db_procedure_perms;
>> +       auditallow domain sepgsql_blob_type      : db_blob all_db_blob_perms;
>> +       auditallow domain sepgsql_server_type    : db_blob { import export };
>> +       auditallow domain sepgsql_module_type    : db_database { install_module };
>> +')
>>     


A couple questions about the install_module and load_module permissions. 
First they seem here to be refering to sepgsql_module_type as the object 
which currently are lib_t and textrel_shlib_t, file types. So the object 
class of db_database seems to be inaccurate.

Also, after looking at the code I don't see why install_module and 
load_module need to be different permissions, granted they are a 
privileged operation but why not collapse them into a single access vector?

Also, why are blobs a separate object class? How is it a privileged 
operation to use blobs in a table? As far as reading and writing them 
they should be treated like any other column, shouldn't they?

And one more question. I see you have a type transition for 
sepgsql_proc_t but I never saw sepgsql_proc_t as the subject of any 
rules, which I don't understand. The hooks appear to always use the 
client_sid as the subject but for stored procedures to be useful they 
may need to access data that the client wouldn't be able to, or did I 
miss something?


--
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.