2011/8/31 Joshua Brindle <method@xxxxxxxxxxxxxxx>:
> Kohei KaiGai wrote:
>>
>> The reason why we check process:{transition} permission on invocation
>> of trusted procedures is an analogy to execution of program with
>> domain transition.
>>
>> In the case of domain transition, it checks process:{transition}
>> permission on a pair of source and target domain, and it also checks
>> file:{entrypoint execute} permission on the security label of the file
>> to be launched.
>>
>
> I think I hit the exact reason why this bothers me today. As
> staff_t:SystemLow-SystemHigh I wanted a stored procedure that ran at
> sepgsql_trusted_proc_t:SystemHigh (so that it could read a SystemHigh column
> and fuzz the results).
>
> Because of the current process constraint:
> mlsconstrain process transition
> (( h1 dom h2 ) and
> (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
> (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
>
> it isn't possible unless staff_t is part of privrangetrans and
> sepgsql_trusted_proc_t is part of mlsrangetrans. I don't mind the latter but
> the former is clearly a violation of how MLS is suppose to work on
> multi-level SELinux systems (in general, unprivileged users should not be
> able to change their level without going through newrole or logging out and
> back in).
>
> If there was a different object class for procedures-while-executing, akin
> to process but called something different we could have a different
> constraint that made more sense for this use case.
>
Hmm. I'd like to consider this matter for more details.
One other point I'm considering is what security label should be delivered to
when a database client want to invoke a remote procedure call using functions
installed to PostgreSQL. This feature is called 'foreign-data-wrapper' being
already merged at v9.1.
If we assign a subject entity that performs as an agent of client a security
label that is not a part of domain attribute, I'm not certain whether it is an
appropriate manner, or not.
BTW, Please don't hope to get this new object class into the upcoming v9.1,
because its feature freeze had done 9 months ago.
Thanks,
--
KaiGai Kohei <kaigai@xxxxxxxxxxxx>
--
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.
