[refpolicy] [PATCH] Add a new permission to db_procedure

[refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

Hi,

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.

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,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-db_procedure.patch
Type: application/octect-stream
Size: 1994 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090119/db92cc45/attachment.bin 

[refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

This is just an aside, I would like to make a rapid conclusion due to
the current (v8.4) PostgreSQL development cycle, if possible.

  http://wiki.postgresql.org/wiki/CommitFestInProgress

KaiGai Kohei wrote:
> Hi,
> 
> 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.
> 
> 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,

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

Re: [refpolicy] [PATCH] Add a new permission to db_procedure

[Christopher J. PeBenito]

On Tue, 2009-01-20 at 17:19 +0900, KaiGai Kohei wrote:
> This is just an aside, I would like to make a rapid conclusion due to
> the current (v8.4) PostgreSQL development cycle, if possible.
> 
>   http://wiki.postgresql.org/wiki/CommitFestInProgress
> 
> KaiGai Kohei wrote:
> > 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.
> > 
> > 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.

Changes to object classes need to be discussed on the SELinux list.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

[refpolicy] [PATCH] Add a new permission to db_procedure

[Christopher J. PeBenito]

On Tue, 2009-01-20 at 17:19 +0900, KaiGai Kohei wrote:
> This is just an aside, I would like to make a rapid conclusion due to
> the current (v8.4) PostgreSQL development cycle, if possible.
> 
>   http://wiki.postgresql.org/wiki/CommitFestInProgress
> 
> KaiGai Kohei wrote:
> > 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.
> > 
> > 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.

Changes to object classes need to be discussed on the SELinux list.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Re: [refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

> 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,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

[-- Attachment #2: refpolicy-db_procedure.patch --]
[-- Type: application/octect-stream, Size: 1995 bytes --]

[refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

> 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,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-db_procedure.patch
Type: application/octect-stream
Size: 1994 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090121/ac13cb20/attachment.bin 

Re: [refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

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,


-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

[refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

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,


-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Re: [refpolicy] [PATCH] Add a new permission to db_procedure

[Joshua Brindle]

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.


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

Re: [refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

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 <kaigai@kaigai.gr.jp>

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

[refpolicy] [PATCH] Add a new permission to db_procedure

[KaiGai Kohei]

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 <kaigai@kaigai.gr.jp>

Re: [refpolicy] [PATCH] Add a new permission to db_procedure

[Christopher J. PeBenito]

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


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

[refpolicy] [PATCH] Add a new permission to db_procedure

[Christopher J. PeBenito]

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