Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> Folks,
>>
>> Do you have any opinion, question, approval or opposition for the new
>> permission to db_procedure class?
>>
>> KaiGai Kohei wrote:
>>>> Changes to object classes need to be discussed on the SELinux list.
>>> OK, I send the patch again for folks in selinux-list only.
>>>
>>>>>> The attached patch add a new permission named as "install" to db_procedure.
>>>>>>
>>>>>> The purpose of this permission is to prevent malicious functions are invoked
>>>>>> as a part of server's internal tasks.
>>>>>>
>>>>>> PostgreSQL allows user-defined functions to use its internal tasks.
>>>>>> For example, it can be used to implement an output/input handler of new data
>>>>>> types, an index access method, implementation of operator classes and so on.
>>>>>>
>>>>>> When we defines a new type, it requires to specify its output/input handler
>>>>>> at least. No need to say, these functions should not be malicious ones,
>>>>>> because user implicitly invokes these function when he uses the type.
>>>>>> This permission is checked when we defines a new system catalog entry which
>>>>>> has a possibility to invoke user defined functions.
>>> A supplement:
>>> PostgreSQL allows user to define his own data type, like "struct xxx" in C
>>> language, and he can also define its input/output handler. The input/output
>>> handler is invoked when user send a text representation, to translate it
>>> into internal data structure, implicitly. For example, a function similar
>>> to atoi() is configured for INTEGER type in default.
>>>
>>> I'm worrying about a malicious one secretly installs a malicious function
>>> which leaks given information to somewhere as a implementation of type
>>> input/output handler, in typical scenario.
>>>
>>> In addition, it allows to install user-defined functions to implement
>>> database index access methods, multibyte encoding conversions, operator
>>> classes and so on.
>>>
>>>>>> In the attached patch, only sepgsql_proc_t is allowed to { install }, because
>>>>>> any other user defined functions are not checked by DBA, so it is not safe to
>>>>>> use it as a part of internal/common processes.
>>>>>> If DBA want to apply user defined functions as a part of internal task, he has
>>>>>> to confirm its safeness and relabel to sepgsql_proc_t at first.
>>>>>>
>>>>>> Please apply it, if no matter.
>>> Thanks,
>
> Chris asked me to look at this and it seems reasonable to me, no
> objections here.
Chris,
If we have no specific objections here, I want the new permission
to be included.
Thanks,
--
KaiGai Kohei <[email protected]>
On Fri, 2009-01-23 at 07:29 +0900, KaiGai Kohei wrote:
> Joshua Brindle wrote:
> > KaiGai Kohei wrote:
> >> Folks,
> >>
> >> Do you have any opinion, question, approval or opposition for the new
> >> permission to db_procedure class?
> >>
> >> KaiGai Kohei wrote:
> >>>> Changes to object classes need to be discussed on the SELinux list.
> >>> OK, I send the patch again for folks in selinux-list only.
> >>>
> >>>>>> The attached patch add a new permission named as "install" to db_procedure.
> >>>>>>
> >>>>>> The purpose of this permission is to prevent malicious functions are invoked
> >>>>>> as a part of server's internal tasks.
> >>>>>>
> >>>>>> PostgreSQL allows user-defined functions to use its internal tasks.
> >>>>>> For example, it can be used to implement an output/input handler of new data
> >>>>>> types, an index access method, implementation of operator classes and so on.
> >>>>>>
> >>>>>> When we defines a new type, it requires to specify its output/input handler
> >>>>>> at least. No need to say, these functions should not be malicious ones,
> >>>>>> because user implicitly invokes these function when he uses the type.
> >>>>>> This permission is checked when we defines a new system catalog entry which
> >>>>>> has a possibility to invoke user defined functions.
> >>> A supplement:
> >>> PostgreSQL allows user to define his own data type, like "struct xxx" in C
> >>> language, and he can also define its input/output handler. The input/output
> >>> handler is invoked when user send a text representation, to translate it
> >>> into internal data structure, implicitly. For example, a function similar
> >>> to atoi() is configured for INTEGER type in default.
> >>>
> >>> I'm worrying about a malicious one secretly installs a malicious function
> >>> which leaks given information to somewhere as a implementation of type
> >>> input/output handler, in typical scenario.
> >>>
> >>> In addition, it allows to install user-defined functions to implement
> >>> database index access methods, multibyte encoding conversions, operator
> >>> classes and so on.
> >>>
> >>>>>> In the attached patch, only sepgsql_proc_t is allowed to { install }, because
> >>>>>> any other user defined functions are not checked by DBA, so it is not safe to
> >>>>>> use it as a part of internal/common processes.
> >>>>>> If DBA want to apply user defined functions as a part of internal task, he has
> >>>>>> to confirm its safeness and relabel to sepgsql_proc_t at first.
> >>>>>>
> >>>>>> Please apply it, if no matter.
> >>> Thanks,
> >
> > Chris asked me to look at this and it seems reasonable to me, no
> > objections here.
>
> Chris,
> If we have no specific objections here, I want the new permission
> to be included.
Merged.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150