Joshua Brindle wrote:
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.
Is it appropriate to define a new permission in file class to associate
a database with a library file?
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?
load_module is a permission to associate a database and a loadable module,
like filesystem:associate permission.
When we tries to load a shared library module, the following permissins
are required.
(Client) (Shared Library) : db_database install_module;
(Client) (Database) : db_database install_module;
(Database) (Shared Library) : db_database load_module;
`install_module' defines a relationship between a client and database/library.
`load_module' defines a relationship between a database and library.
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?
In MySQL, blob is one of the data types, and it can be stored in a table.
However, blob is a set of tuples stored in pg_largeobject system catalog
in PostgreSQL. To separate large binary object into small blocks improves
ramdam access performance, but dameges to consistency in access control.
It is the reason why SE-PostgreSQL need special care for blobs.
http://www.postgresql.org/docs/8.3/static/catalog-pg-largeobject.html
BTW, current PostgreSQL does not have any access controls mechanism
in large object. :(
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?
When a sepgsql_client_domain invokes sepgsql_trusted_proc_t, the client_sid
is transted into sepgsql_trusted_domain_t.
However, domain transition is kept in invokations for another procedure type.
sepgsql_proc_t is always a object type, as postgresql_exex_t is always a file
type, not a domain.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
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.
