>> It seems that if the user template is instantiated, then it should
>> already have all the access that a client might have. I'm still
>> thinking about it, but we might want to just drop the type transition
>> out of the unconfined section and just require that something that is
>> unconfined should be either a client or userdom too, to make the the
>> type_transitions are correct.
>
> In this policy, sepgsql_client_type is also given minimum set of permissions
>
> +interface(`postgresql_unconfined',`
> + gen_require(`
> + attribute sepgsql_unconfined_type;
> + attribute sepgsql_client_type;
> + ')
> + typeattribute $1 sepgsql_unconfined_type;
> + typeattribute $1 sepgsql_client_type;
> +')
>
> It is a relic when unconfined domain is conditional, unnecessary now.
> It does not need to invoke trusted procedure when unconfined domain
> is persistent, and unconfined domain will not need to be within userdom
> because its does not create objects with any user prefix.
>
>> This whole section should probably just go into postgresql_client() and
>> then the attribute could be dropped.
>
> However, I want remain sepgsql_client_type to mark domains as a client
> of SE-PostgreSQL, with separating from minimum set of permissions.
> It enables to describe user defined policy easier.
> (Like auditallow switch for debugging.)
Oops, if whole of section is moved to postgresql_client(), we have to put
sepgsql_enable_users_ddl tunable section within interface.
How do you think the following idea?
1. type_transition rules are moved to postgresql_client() or
postgresql_userdom_template().
(sepgsql_db_t is an exception. It's common for any client)
2. a new attribute sepgsql_unpriv_client_type gives a set of
baseline permissions, including sepgsql_enable_users_ddl
tunable.
--> It means any client domain belongs to sepgsql_client_type
and either sepgsql_unconfined_type or sepgsql_unpriv_client_type.
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.
