Tom Lane wrote:
> Ron Mayer writes:
>> As far as I can tell, the community feels interested in the
>> feature set; but relatively unable to contribute since none
>> of the people have that much of a security background. It
>> seems the best way to fix that would be to get more people
>> with a se
Hannu Krosing wrote:
>> If we compile it with --enable-selinux, it has two working modes
>> controled by a guc option: sepostgresql (bool).
>> If it is disabled, all the sepgsql() invocations returns at
>> the head of themself without doing anything.
>>
>> I believe this behavior follows the pr
On Tue, 2009-03-10 at 11:44 -0700, Joshua D. Drake wrote:
> We would do the same thing with SE-Postgres.
No, no. I already experienced this with --integer-datetimes sets, and I
don't ever want to maintain another set. It is horrible.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org
Ron Mayer writes:
> As far as I can tell, the community feels interested in the
> feature set; but relatively unable to contribute since none
> of the people have that much of a security background. It
> seems the best way to fix that would be to get more people
> with a security background more
On Tue, 2009-03-10 at 14:59 -0400, Tom Lane wrote:
>
> > Which is exactly why we have two types of RPMS, --integer-datetimes
> and
> > not.
>
> Maybe Devrim is doing that, but nobody else is.
It is only available *if* yum repo conf file is specially configured and
if the distro is Fedora 10 an
On Tue, 2009-03-10 at 14:59 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Tue, 2009-03-10 at 14:14 -0400, Tom Lane wrote:
> >> You're just putting the hard decision onto packagers, who have no more
> >> knowledge than you do about what their users want, and (probably)
> >> considerably
"Joshua D. Drake" writes:
> On Tue, 2009-03-10 at 14:14 -0400, Tom Lane wrote:
>> You're just putting the hard decision onto packagers, who have no more
>> knowledge than you do about what their users want, and (probably)
>> considerably less understanding of the benefits/risks of some new
>> conf
On Tue, 2009-03-10 at 14:14 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Tue, 2009-03-10 at 14:47 -0300, Alvaro Herrera wrote:
> >> It was said upthread that SEPostgres is already packaged for Fedora.
>
> You're just putting the hard decision onto packagers, who have no more
> knowl
On Tue, 2009-03-10 at 10:49 -0700, Joshua D. Drake wrote:
> > It was said upthread that SEPostgres is already packaged for Fedora.
>
> Yes for but not by, AFAIK it is not actually included with Fedora.
It is, with the names "sepostgresql*".
> Essentially it is packaged like the PGSQLRPMS are pa
Tom Lane wrote:
> "Joshua D. Drake" writes:
>> I know we are a little uncomfortable here but KaiGai-San (forgive me if
>> I type that wrong) has proven to be a contributor in his own right,
>
> Not to put too fine a point on it, but: no, he hasn't. Show me one
> significant patch he's contribute
"Joshua D. Drake" writes:
> On Tue, 2009-03-10 at 14:47 -0300, Alvaro Herrera wrote:
>> It was said upthread that SEPostgres is already packaged for Fedora.
> Yes for but not by, AFAIK it is not actually included with Fedora.
"Included with Fedora" is an extremely loose concept. You can get it
On Tue, 2009-03-10 at 14:47 -0300, Alvaro Herrera wrote:
> Joshua D. Drake escribió:
>
> > Yes but I am also offering an opportunity for others to show up. Which
> > denying the patch does not do. If we provide SE support (even with
> > marking it experimental), I would wager that some Linux distr
Joshua D. Drake escribió:
> Yes but I am also offering an opportunity for others to show up. Which
> denying the patch does not do. If we provide SE support (even with
> marking it experimental), I would wager that some Linux distributions
> would begin to test it themselves which would allow us i
On Tue, 2009-03-10 at 13:08 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > I think you misunderstand me. I have watched this thread very closely
> > because it has specific strategic interest. For the record:
>
> > * This patch does scare me
> > * With great risk comes great reward
>
>
"Joshua D. Drake" writes:
> I think you misunderstand me. I have watched this thread very closely
> because it has specific strategic interest. For the record:
> * This patch does scare me
> * With great risk comes great reward
... or great failure. My key concern is that we are setting ourse
On Mon, 2009-03-09 at 20:55 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > I know we are a little uncomfortable here but KaiGai-San (forgive me if
> > I type that wrong) has proven to be a contributor in his own right,
>
> Perhaps it would help you calibrate the problem if I stated that
On Tue, Mar 10, 2009 at 08:02:05PM +0900, KaiGai Kohei wrote:
> Please wait for a while.
With all due respect to your hard work, waiting for this patch, even
one more hour, is exactly what we shouldn't do for 8.4. Sad as it is,
even if this patch were causing no controversy in its design, it woul
Heikki Linnakangas writes:
> If we drop the goal of trying to restrict what a superuser can do, is
> the patch still useful?
> One idea is to add a single "is superuser" permission to sepgsql.
The agreement back in January was that what we'd consider for 8.4 is
a patch that adds SELinux-driven
KaiGai Kohei writes:
> Heikki Linnakangas wrote:
>> If we drop the goal of trying to restrict what a superuser can do, is the
>> patch still useful?
>
> I want to keep permission checks on files specified by users, because
> the "superuser" permission affects very wide scope, and all or nothing
>
Heikki Linnakangas wrote:
This seems to be a recurring theme with this patch. We stripped
row-level permissions, now we have SET/SHOW and the "function
installation" permissions. And the read/write file permissions. To make
progress, we need to consider each new feature like that separately, as
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Heikki Linnakangas writes:
KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
The patch adds permission checks to SET/SHOW. If that's useful
functionality, it would be nice to see that as a separate
Hannu Krosing wrote:
> On Tue, 2009-03-10 at 09:56 +0900, KaiGai Kohei wrote:
>> Joshua D. Drake wrote:
> ...
>>> Is there any possibility of having it be enabled at compile time? The
>>> default would be know but those distributions that would like to make
>>> use of it could?
>> It was the design
On Tue, 2009-03-10 at 09:56 +0900, KaiGai Kohei wrote:
> Joshua D. Drake wrote:
...
> > Is there any possibility of having it be enabled at compile time? The
> > default would be know but those distributions that would like to make
> > use of it could?
>
> It was the design a half year ago, but Br
Heikki Linnakangas wrote:
+ void
+ sepgsqlCheckProcedureInstall(Relation rel, HeapTuple newtup,
HeapTuple oldtup)
+ {
[snip]
+ + case AccessMethodRelationId:
+ CHECK_PROC_INSTALL_PERM(pg_am, aminsert, newtup, oldtup);
+ CHECK_PROC_INSTALL_PERM(pg_am, ambeginscan, newtup,
Tom Lane wrote:
> Despite all that arm-waving, no one besides KaiGai-san has really
> stepped up to work on it. That leaves me not only with worries about
> the patch itself, but with an extremely low estimate of the community's
> interest in it. And it is too big, complicated, and risky to go in
Josh Berkus writes:
>> Frankly, what we have here is a large patch, with insanely difficult
>> correctness requirements, written by a Postgres newbie. If it doesn't
>> scare you, you haven't been paying attention. We have a long track
>> record of problems with patches written by people who thou
Tom,
Frankly, what we have here is a large patch, with insanely difficult
correctness requirements, written by a Postgres newbie. If it doesn't
scare you, you haven't been paying attention. We have a long track
record of problems with patches written by people who thought they were
ready to do
Jaime Casanova wrote:
On Mon, Mar 9, 2009 at 1:52 AM, KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
[3
On Mon, Mar 9, 2009 at 1:52 AM, KaiGai Kohei wrote:
> As I promised last week, SE-PostgreSQL patches are revised here:
>
> [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
> [3/5] http://sepgs
> Perhaps it would help you calibrate the problem if I stated that
> I wouldn't trust a patch for this purpose written by myself, let
> alone somebody who hasn't been hacking the backend for ten years.
> (Where "this purpose" means the type of control KaiGai-san seems
> to hope to enforce, as oppos
Joshua D. Drake wrote:
> On Mon, 2009-03-09 at 19:45 -0400, Tom Lane wrote:
>> Hannu Krosing writes:
>>> Can't it be kept separately maintained release for a version or two, so
>>> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
>>> easy way to compare both correctness and per
"Joshua D. Drake" writes:
> I know we are a little uncomfortable here but KaiGai-San (forgive me if
> I type that wrong) has proven to be a contributor in his own right,
Not to put too fine a point on it, but: no, he hasn't. Show me one
significant patch he's contributed before/beside this one.
On Mon, 2009-03-09 at 20:31 -0400, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > http://www.nsa.gov/applications/search/index.cfm?q=se-postgresql
> >
> > It is also part of the Secure OS project out of Japan (as far as I can
> > tell).
> >
> > I know we are a little uncomfortable here but Kai
Hannu Krosing wrote:
> Can't it be kept separately maintained release for a version or two, so
> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
> easy way to compare both correctness and performance ?
>
> Anyone remember how did Linux implement/introduce SE Linux ?
SELinux h
Joshua D. Drake wrote:
> http://www.nsa.gov/applications/search/index.cfm?q=se-postgresql
>
> It is also part of the Secure OS project out of Japan (as far as I can
> tell).
>
> I know we are a little uncomfortable here but KaiGai-San (forgive me if
> I type that wrong) has proven to be a contrib
On Mon, 2009-03-09 at 20:05 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Is there any possibility of having it be enabled at compile time?
>
> That's been assumed right along (unless you think it's okay for Postgres
> to stop working on every non-SELinux platform).
Good point.
> The
"Joshua D. Drake" writes:
> Is there any possibility of having it be enabled at compile time?
That's been assumed right along (unless you think it's okay for Postgres
to stop working on every non-SELinux platform). The problem here is
mostly about whether we have enough confidence in the code to
On Mon, 2009-03-09 at 19:45 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Can't it be kept separately maintained release for a version or two, so
> > that we will have both PostgreSQL and SE-PostgreSQL and thus have an
> > easy way to compare both correctness and performance ?
>
> Actually,
Hannu Krosing writes:
> Can't it be kept separately maintained release for a version or two, so
> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
> easy way to compare both correctness and performance ?
Actually, KaiGai-san has been distributing a patched SEPostgres on
Fedora
On Mon, 2009-03-09 at 16:39 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Mar 9, 2009 at 4:04 PM, Tom Lane wrote:
> >> Now it's not really KaiGai-san's fault;
> >> the fundamental problem IMHO is that no one else is taking very much
> >> interest in the patch. But that in itself speaks
Robert Haas writes:
> On Mon, Mar 9, 2009 at 4:04 PM, Tom Lane wrote:
>> Now it's not really KaiGai-san's fault;
>> the fundamental problem IMHO is that no one else is taking very much
>> interest in the patch. But that in itself speaks volumes about whether
>> we actually want this patch or sho
On Mon, Mar 9, 2009 at 4:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane wrote:
>>> I've been convinced for awhile that the sepostgres project is going
>>> off the rails, and these last couple of exchanges just confirm the fear.
>
>> I'm not sure what you
Robert Haas writes:
> On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane wrote:
>> I've been convinced for awhile that the sepostgres project is going
>> off the rails, and these last couple of exchanges just confirm the fear.
> I'm not sure what you mean by "going off the rails". I think we are
> still
On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane wrote:
> KaiGai Kohei writes:
>> Yes, the purpose of sepgsqlCheckProcedureInstall() is to prevent users
>> to invoke functions installed by other malicious/untrusted one, typically
>> known as trojan-horse.
>> ...
>> We should not assume only C-functions c
KaiGai Kohei writes:
> Yes, the purpose of sepgsqlCheckProcedureInstall() is to prevent users
> to invoke functions installed by other malicious/untrusted one, typically
> known as trojan-horse.
> ...
> We should not assume only C-functions can be installed on pg_conversion
> (and other internal s
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
I think I now understand what sepgsqlCheckProcedureInstall is trying to
achieve. It's trying to stop attacks where you trick another user to run
your malicious code. We had a seriou
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Heikki Linnakangas writes:
> > KaiGai Kohei wrote:
> >> As I promised last week, SE-PostgreSQL patches are revised here:
>
> > The patch adds permission checks to SET/SHOW. If that's useful
> > functionality, it would be nice to see that as a separate patc
Heikki Linnakangas writes:
> KaiGai Kohei wrote:
>> As I promised last week, SE-PostgreSQL patches are revised here:
> The patch adds permission checks to SET/SHOW. If that's useful
> functionality, it would be nice to see that as a separate patch, not
> requiring SE-Linux.
My goodness. This pa
KaiGai Kohei wrote:
> As I promised last week, SE-PostgreSQL patches are revised here:
The patch adds permission checks to SET/SHOW. If that's useful
functionality, it would be nice to see that as a separate patch, not
requiring SE-Linux.
I think it's leaking because current_setting(), set_config
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> As I promised last week, SE-PostgreSQL patches are revised here:
>
> There's checks for reading/writing files with COPY, in
> sepgsqlCheckFileRead sepgsqlCheckFileWrite). Doesn't the OS do similar
> checks when the process tries to invoke the read
KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
I think I now understand what sepgsqlCheckProcedureInstall is trying to
achieve. It's trying to stop attacks where you trick another user to run
your malicious code. We had a serious vulnerability of that kin
KaiGai Kohei wrote:
> As I promised last week, SE-PostgreSQL patches are revised here:
There's checks for reading/writing files with COPY, in
sepgsqlCheckFileRead sepgsqlCheckFileWrite). Doesn't the OS do similar
checks when the process tries to invoke the read()/write()? Is that not
enough?
--
As I promised last week, SE-PostgreSQL patches are revised here:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1704.patch
[4
53 matches
Mail list logo
