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