From: "Christopher J. PeBenito" <cpebenito@tresys.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: refpolicy@oss.tresys.com, SELinux Mail List <selinux@tycho.nsa.gov>
Subject: Re: [refpolicy] [PATCH] Add a new permission to db_procedure
Date: Tue, 20 Jan 2009 09:31:11 -0500 [thread overview]
Message-ID: <1232461874.10460.1.camel@gorn> (raw)
In-Reply-To: <49758904.2070303@ak.jp.nec.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH] Add a new permission to db_procedure
Date: Tue, 20 Jan 2009 09:31:11 -0500 [thread overview]
Message-ID: <1232461874.10460.1.camel@gorn> (raw)
In-Reply-To: <49758904.2070303@ak.jp.nec.com>
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
next prev parent reply other threads:[~2009-01-20 14:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-18 15:11 [refpolicy] [PATCH] Add a new permission to db_procedure KaiGai Kohei
2009-01-20 8:19 ` KaiGai Kohei
2009-01-20 14:31 ` Christopher J. PeBenito [this message]
2009-01-20 14:31 ` Christopher J. PeBenito
2009-01-20 15:11 ` KaiGai Kohei
2009-01-20 15:11 ` KaiGai Kohei
2009-01-21 22:28 ` KaiGai Kohei
2009-01-21 22:28 ` KaiGai Kohei
2009-01-22 19:58 ` Joshua Brindle
2009-01-22 22:29 ` KaiGai Kohei
2009-01-22 22:29 ` KaiGai Kohei
2009-01-23 20:07 ` Christopher J. PeBenito
2009-01-23 20:07 ` Christopher J. PeBenito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1232461874.10460.1.camel@gorn \
--to=cpebenito@tresys.com \
--cc=kaigai@ak.jp.nec.com \
--cc=refpolicy@oss.tresys.com \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.