Are you saying the performance penalty when full functionalities are
enabled?
(The meaning of bells and whistles is unclear for me.)
Yes, that's what I meant. (Sorry.)
We can show it on the page.22 of my presentation in PGcon2008.
* Robert Haas [EMAIL PROTECTED] [080924 00:15]:
But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux.
Actually, I'ld go one stroke farther, and ask:
Aidan Van Dyk wrote:
* Robert Haas [EMAIL PROTECTED] [080924 00:15]:
But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux.
Actually, I'ld go one
KaiGai Kohei wrote:
Aidan Van Dyk wrote:
* Robert Haas [EMAIL PROTECTED] [080924 00:15]:
But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux.
KaiGai Kohei wrote:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Multilevel frameworks have concepts of data hiding and data substitution
based on labels. That is, if a user doesn't have permissions on data,
he's not merely supposed to be denied access to it, he's not even
Aidan Van Dyk wrote:
* Robert Haas [EMAIL PROTECTED] [080924 00:15]:
But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux.
Actually, I'ld go one
Peter Eisentraut wrote:
Aidan Van Dyk wrote:
* Robert Haas [EMAIL PROTECTED] [080924 00:15]:
But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running
Peter Eisentraut [EMAIL PROTECTED] writes:
Aidan Van Dyk wrote:
Actually, I'ld go one stroke farther, and ask:
Does it make sense to introduce a bunch of features that are only
usable to people *able to write proper SELinux policy sets* (or whatever
they are called).
I consider this a valid
On Wed, 24 Sep 2008 11:58:58 -0400
Tom Lane [EMAIL PROTECTED] wrote:
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to
discuss just how
Joshua Drake wrote:
On Wed, 24 Sep 2008 11:58:58 -0400
Tom Lane [EMAIL PROTECTED] wrote:
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not
Bruce Momjian wrote:
Peter, I am confused how the above statement relates to a posting you
made a week ago:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php
Now these items are arguably useful and welcome features in their own
right. Unfortunately, this
Joshua Drake wrote:
I know of no one that really uses SELinux because it is a nightmare. On
the other hand, this type of security is required to get into certain
scary tin foil hat producing institutions.
Yeah, but do we even have the slightest bit of information about what
exactly would be
Peter,
Yeah, but do we even have the slightest bit of information about what
exactly would be required to achieve the required levels? And whether
this patch does it? And whether there would be alternative, more
desirable ways to achieve a similar level?
Actually, I have some direct
On Wed, 24 Sep 2008 11:38:36 -0700
Josh Berkus [EMAIL PROTECTED] wrote:
Peter,
Yeah, but do we even have the slightest bit of information about
what exactly would be required to achieve the required levels? And
whether this patch does it? And whether there would be
alternative, more
On Sep 24, 2008, at 2:38 PM, Josh Berkus wrote:
Peter,
Yeah, but do we even have the slightest bit of information about
what exactly would be required to achieve the required levels? And
whether this patch does it? And whether there would be
alternative, more desirable ways to achieve
Josh Berkus wrote:
Peter,
Yeah, but do we even have the slightest bit of information about what
exactly would be required to achieve the required levels? And whether
this patch does it? And whether there would be alternative, more
desirable ways to achieve a similar level?
Josh Berkus [EMAIL PROTECTED] writes:
Peter,
Yeah, but do we even have the slightest bit of information about what
exactly would be required to achieve the required levels? And whether
this patch does it? And whether there would be alternative, more
desirable ways to achieve a similar
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to discuss
just how large that set might be while we debate whether to accept the
patch.
Robert Haas wrote:
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to discuss
just how large that set might be while we debate whether to
Tom,
Does that mean that they have looked at this specific patch and
concluded that it meets their requirements? Or just that SELinux
is a checkbox item for them?
That it was a checkbox item for them, and it led to them evaluating
PostgreSQL when they otherwise wouldn't have. I don't know
Peter Eisentraut wrote:
I am not arguing for or against this patch now, but I would like to know
whether someone has an agenda for it. Without an agenda, future
maintenance will be difficult. Reference to standards or other public
documents would work best to define that agenda.
It is a
Bruce Momjian wrote:
Robert Haas wrote:
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to discuss
just how large that set might be while we
Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
In addition, these are invoked via security hooks which are declared
as inline functions. So, I think it does not give us additional loss of
performances when you don't add the compile time option explicitly.
That is
Robert Haas wrote:
Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
In addition, these are invoked via security hooks which are declared
as inline functions. So, I think it does not give us additional loss of
performances when you don't add the compile time option
Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
KaiGai Kohei wrote:
[1] Make a consensus that different security mechanisms have differences
in its decision making, its gulanuality and its scope
I think it is the most straightforward answer.
As operating system doing, DAC and MAC based access controls should be
independently
Bruce,
I think the community's priorities are to add security at the SQL
level, and then we can see clearly what SE-PostgreSQL requires. This
has been discussed before so it should not come as a surprise.
Well, I'm not that clear on exactly the SE implementation, but I spent a
fair amount
Josh Berkus wrote:
Bruce,
I think the community's priorities are to add security at the SQL
level, and then we can see clearly what SE-PostgreSQL requires. This
has been discussed before so it should not come as a surprise.
Well, I'm not that clear on exactly the SE implementation,
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've been sitting for years on the per-row
privilege stuff, and
Alvaro Herrera wrote:
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've been sitting for years on the
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've been sitting
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've
Josh Berkus [EMAIL PROTECTED] writes:
Multilevel frameworks have concepts of data hiding and data substitution
based on labels. That is, if a user doesn't have permissions on data,
he's not merely supposed to be denied access to it, he's not even supposed
to know that the data exists. In
Well, does it make sense to add column-level privileges just for
SE-Linux?
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about
Robert Haas wrote:
I think the answer is yes, because (as others have said) if we ever want
to have SQL-level per-row permissions, then we can implement them with
no change to the patch currently in discussion.
If that's true, it weighs somewhat in favor of accepting this patch,
but how
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Multilevel frameworks have concepts of data hiding and data substitution
based on labels. That is, if a user doesn't have permissions on data,
he's not merely supposed to be denied access to it, he's not even supposed
to know that the
Yeah, that's what I keep hearing that the spooks think they want.
I can't imagine how it would play nice with SQL-standard integrity
constraints. Data that apparently violates a foreign-key constraint,
for example, would give someone a pretty good clue that there's
something there he's not
Robert Haas [EMAIL PROTECTED] writes:
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about per-column, not per-row.
There's a
Bruce Momjian wrote:
Robert Haas wrote:
I think the answer is yes, because (as others have said) if we ever want
to have SQL-level per-row permissions, then we can implement them with
no change to the patch currently in discussion.
If that's true, it weighs somewhat in favor of accepting this
Robert Haas [EMAIL PROTECTED] writes:
I don't think there's much point in second-guessing the NSA: they are
smart and have thought about this more than we have.
No doubt, but have they told us what we'd need to know to make a
non-broken implementation? I haven't seen anything about how a SQL
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about per-column, not
[1] Make a consensus that different security mechanisms have differences
in its decision making, its gulanuality and its scope
I think it is the most straightforward answer.
As operating system doing, DAC and MAC based access controls should be
independently applied on accesses from users,
[2] Make a new implementation of OS-independent fine grained access control
If it is really really necessary, I may try to implement a new separated
fine-grained access control mechanism due to the CommitFest:Nov.
However, we don't have enough days to develop one more new feature from
the
Robert Haas wrote:
[2] Make a new implementation of OS-independent fine grained access control
If it is really really necessary, I may try to implement a new separated
fine-grained access control mechanism due to the CommitFest:Nov.
However, we don't have enough days to develop one more new
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
have to have same
Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
have to
On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these
A.M. wrote:
On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why
At the CommitFest:Sep, I got several comments about SE-PostgreSQL from Peter.
(Thanks for your comments.)
He asked me several questions about its concept, then I replied for them.
However, it seems to me there is a difference in our opinions.
In my opinion, it is quite natural that different
Greg Smith wrote:
On Wed, 17 Sep 2008, Peter Eisentraut wrote:
System-wide consistency in access controls could be nice to have in
some cases. But is it really achievable? In the typical three-tier
web application scenario, do you really have system-wide consistency?
Can you configure
KaiGai Kohei wrote:
Peter, thanks for your comments.
Let's review:
*) System-wide consistency in access controls could be nice to have in
some cases. But is it really achievable? In the typical three-tier web
application scenario, do you really have system-wide consistency? Can
KaiGai Kohei wrote:
Could you tell me the current status of reviewing process in the
CommitFest:Sep?
Well ... I have analyzed this patch several times now. The
implementation appears to be pretty straightforward, and when the time
comes, we can discuss some of the low-level details.
At
On Wed, 17 Sep 2008, Peter Eisentraut wrote:
System-wide consistency in access controls could be nice to have in some
cases. But is it really achievable? In the typical three-tier web
application scenario, do you really have system-wide consistency? Can
you configure your application
Peter, thanks for your comments.
Let's review:
*) System-wide consistency in access controls could be nice to have in
some cases. But is it really achievable? In the typical three-tier web
application scenario, do you really have system-wide consistency? Can
you configure your
Peter, Abhijit,
Could you tell me the current status of reviewing process in the CommitFest:Sep?
I can understand the patches contain several new concept and a bit large,
and it is a tough work to review them comprehensively.
I'm not unconcern anything even if reviwing comments are partial one.
Hello,
The latest SE-PostgreSQL patches are updated here:
[1/4]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1005.patch
[2/4]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1005.patch
[3/4]
The following SE-PostgreSQL patches are updated.
It contains rebasing to the lastest CVS and fixes at invocation of trusted
procedures via operators. Rest of parts are unchanged.
[1/4]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r980.patch
[2/4]
57 matches
Mail list logo
