Limitations in modular policy

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

Is there any good reason why the current modular policy doesn't, cannot
or shouldn't support to contain definitions of object classes and its
access vectors except for the base policy?

For example, it seems to me reasonable to have the following statement
to support experimental object classes and access vectors.
--------------------------------
policy_module(sepostgresql-devel, 1.23)

gen_require(`
    class db_database all_db_database_perms;
    attribute sepgsql_unconfined_type;
    type sepgsql_db_t;
')

## 1. Add an experimental access vector
class db_database { superuser };

## 2. Add an experimental object class
class db_schema
inherits database
{
	search
	add_name
	remove_name
};

## 3. Add an experimental MLS/MCS rules
ifdef(`enable_mcs',`
	mlsconstrain db_database { superuser }
		( h1 dom h2 );
	mlsconstrain db_schema { create relabelto }
		(( h1 dom h2 ) and ( l2 eq h2 ));
	mlsconstrain db_schema { drop getattr setattr relabelfrom search add_name remove_name }
		( h1 dom h2 );
')
ifdef(`enable_mls`,`
	  :
	<snip>
	  :
')
## 4. avtab rules currently supported
type sepgsql_schema_t;

allow sepgsql_unconfined_type sepgsql_db_t : db_database *;
allow sepgsql_unconfined_type sepgsql_schema_t : db_schema *;
--------------------------------

Currently, SE-PostgreSQL has several experimental object classes and access
vectors (such as db_schema class and db_database:{superuser}), but we will
need more several months to fix its specifications at least, because progress
in the pgsql-hackers too slow.
So, we must replace the standard selinux-policy package to run it with full
functionalities, but it will get troubled for each "yum update".

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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