Bruce, KaiGai,
Is PGACE ready for CommitFest, now?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus wrote:
Bruce, KaiGai,
Is PGACE ready for CommitFest, now?
--Josh
Yes, it's ready now.
See the following message:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00980.php
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00840.php
Thanks,
--
KaiGai Kohei
KaiGai Kohei wrote:
Josh Berkus wrote:
Bruce, KaiGai,
Is PGACE ready for CommitFest, now?
--Josh
Yes, it's ready now.
OK, added to CommitFest.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Added to TODO:
* Improve server security options
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01875.php
http://archives.postgresql.org/pgsql-hackers/2008-05/msg0.php
---
KaiGai Kohei wrote:
I updated
On Wed, May 7, 2008 at 7:52 AM, KaiGai Kohei [EMAIL PROTECTED] wrote:
Tom, Thanks for your reviewing.
The patch hasn't got a mode in which SELinux support is compiled in but
not active. This is a good way to ensure that no one will ever ship
standard RPMs with the feature compiled in, because
Tom Lane wrote:
The idea of input functions that alter system tables scares me.
An example:
SELECT 'system_u:object_r:sepgsql_table_t:SystemHigh'::security_label;
can insert a new tuple into pg_security, but it is not a desirable behavior.
To fix this, I'll remove security_label type and
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, I remember those. What needs to be looked at here is *why* the
output is changing. For a patch that allegedly does not touch the
planner, it's fairly disturbing that you don't get the same results.
SE-PostgreSQL
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Some of the test fails contains minor differences from expected results,
like:
| SELECT '' AS xxx, *
| FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
|xxx | a | b | c | d
| -+---+---+--+---
| - |
KaiGai Kohei [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, I remember those. What needs to be looked at here is *why* the
output is changing. For a patch that allegedly does not touch the
planner, it's fairly disturbing that you don't get the same results.
SE-PostgreSQL does not touch
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, I remember those. What needs to be looked at here is *why* the
output is changing. For a patch that allegedly does not touch the
planner, it's fairly disturbing that you don't get the same results.
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. Is that really a good idea, compared to hard-wiring the checks
into nodeSeqscan and friends?
My eyebrows went up when I read this too. Presumably, if it's hardwired
like you suggest then the planner can't take any account of the
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Tom Lane wrote:
* It does not come close to passing the regression tests. I saw a lot of
! ERROR: unrecognized node type: 903
which suggests that something's been screwed up about parse analysis
(903 = T_A_Const, which shouldn't get
KaiGai Kohei [EMAIL PROTECTED] writes:
Some of the test fails contains minor differences from expected results, like:
| SELECT '' AS xxx, *
| FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
|xxx | a | b | c | d
| -+---+---+--+---
| - | 0 | | zero |
|
The whole early security business looks like a mess :-(. I suspect
you should rip all that out of the backend and add a step to initdb
that fills in those tables.
I also think early security codes are ad-hoc. :-(
Pushing it into initdb seems me a good idea.
I'll try to consider whether it
Tom Lane wrote:
After that, and a whole bunch of foolery with manually putting the right
security labels on files (because the contrib module is unhelpful for
test installations with nonstandard PREFIXes), I managed to get a
version that worked well enough to test. What I found out:
I'll
On Wed, May 07, 2008 at 12:01:21AM -0400, Greg Smith wrote:
It may be the case that clean row and column filtering at the SQL layer are
pre-requisites for a clean SELinux implementation, where the only
difference is that the permission checks are handled by asking SELinux
instead of
KaiGai Kohei [EMAIL PROTECTED] writes:
Tom Lane wrote:
* It does not come close to passing the regression tests. I saw a lot of
! ERROR: unrecognized node type: 903
which suggests that something's been screwed up about parse analysis
(903 = T_A_Const, which shouldn't get further than parse
In a digest for Tue, 2008-05-06 at 22:57 -0300, Tom Lane wrote:
...[discussion of SE-PostgreSQL patch deleted]...
(And of course the next question after that is why we should want to
depend on SELinux at all, rather than implementing row filtering
in the framework of SQL permissions...)
I
Andrew, Marc,
FWIW, I support and think important the row- and column- level access
controls this seems to be proposing, at least in principle. Whether
that's a support that will extend to 2x overhead on everything is
rather a different matter. Also, I am more than prepared to trade
away some
I wrote:
I tried to do a bit of testing of this, but it does not work on current
Fedora 8, because the policy module doesn't build:
I got past that by commenting out the last few lines of sepostgresql.te,
which apparently are intended for some SELinux feature that's not
shipped yet in F8.
On Tue, May 06, 2008 at 02:56:41PM -0400, Tom Lane wrote:
AFAICS the only thing left that really needs to be discussed more during
this commit-fest is the business about whether it's sane to be trying to
apply selinux restrictions in simple_heap_update and friends.
I don't have any opinion
Andrew Sullivan [EMAIL PROTECTED] writes:
I don't have any opinion about the patches, obviously, but I'm
wondering whether there is, somewhere, an outline of what the _goals_
of this system are.
The only documentation I've seen is
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL
On Tue, May 06, 2008 at 03:28:25PM -0400, Tom Lane wrote:
The only documentation I've seen is
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL
which contains only examples of enforcing restrictions on *user*
queries and tables.
I agree that, having just read that, anything that
Andrew Sullivan [EMAIL PROTECTED] writes:
There is an issue in most high-security systems having to do with
side-channel leakage of supposedly sensitive data. So, the mere
exsistence of certain tables, columns, or users might be regarded as
security-sensitive data. I'm not sure I see how to
On Tue, 6 May 2008, Tom Lane wrote:
And of course the next question after that is why we should want to
depend on SELinux at all, rather than implementing row filtering in the
framework of SQL permissions...
It may be the case that clean row and column filtering at the SQL layer
are
Tom, Thanks for your reviewing.
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
I updated the series of SE-PostgreSQL patches for the latest pgsql-8.4devel
tree.
I tried to do a bit of testing of this, but it does not work on current
Fedora 8, because the policy module doesn't
KaiGai Kohei [EMAIL PROTECTED] writes:
I updated the series of SE-PostgreSQL patches for the latest pgsql-8.4devel
tree.
I tried to do a bit of testing of this, but it does not work on current
Fedora 8, because the policy module doesn't build:
[EMAIL PROTECTED] sepgsql-policy]$ make
make -f
On Mon, 5 May 2008, Tom Lane wrote:
elog() should not be used for user-facing errors. I couldn't easily
tell just which of the messages are likely to be seen by users and
which ones should be can't happen cases, but certainly there are
a whole lot of these that need to be ereport()s. Likely
Josh Berkus [EMAIL PROTECTED] writes:
For hackers who don't understand security frameworks, I'm going to make a
strong case for KaiGai's patch.
...
So it would be much better to have this functionality be mainstream
rather than a fork. If it does get bounced, please do it becuase of code
On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer volume here, this is the
Greg Smith [EMAIL PROTECTED] writes:
The approach taken here is to put all the #ifdef logic into the underlying
ACE interface (see patch [2/4]), so that the caller doesn't have to care. If
SELinux support is off then the calls turns into
void x(y) {} or
bool a(b) { return true; }
Greg Smith wrote:
On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer
I updated the series of SE-PostgreSQL patches for the latest pgsql-8.4devel
tree.
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
[2/4]
Folks,
For hackers who don't understand security frameworks, I'm going to make a
strong case for KaiGai's patch. Because of my current presentation
series, I've been talking to PostgreSQL users about security features
around the world for the last several months, and there's a *lot* of
Josh Berkus wrote:
Folks,
So it would be much better to have this functionality be mainstream
rather than a fork. If it does get bounced, please do it becuase of code
quality and not because nobody is asking for this.
+1
Joshua D. Drake
--
Sent via pgsql-hackers mailing list
On 01/05/2008, Josh Berkus [EMAIL PROTECTED] wrote:
Further, I've asked the TrustedSolaris folks to take a look at KaiGai's
implementation to see if it was generic enough for them to build on as a
test of whether SE-Postgres was too specific to SE-Linux; the answer has
been a tentative
On Thu, 1 May 2008, Andrej Ricnik-Bay wrote:
Not a hacker, just a curious reader ... are there equivalent frameworks
for the other supported platforms? E.g. MacOS, *BSD, Windows?
SELinux is a Linux implementation of ideas from an earlier NSA project
named Flask. There is port of another
KaiGai,
NSA and SUN announces a new project launched which tries to port FLASK
security architecture, it is named as FMAC.
It can be a good candidate to host multilevel database security.
(SELinux is also based on FLASK security architecture.)
SEBSD project is also known. It is a poring of
For easier reviewing, the most fundamental patch to implement PGACE (PostgreSQL
Access Control Extension) was separated into thress parts.
I want to start discussion about PGACE security framework at first.
Any comments are welcome.
[1/3] PGACE core features
Zdenek Kotala wrote:
Kohei KaiGai napsal(a):
It seems to me some of SE-PostgreSQL patches are not delivered yet,
although [3/4] and [4/4] were already done.
Does anti-spam system caught my previous three messages?
If necessary, I will send them again.
There is a file size limitation. If
Kohei KaiGai napsal(a):
It seems to me some of SE-PostgreSQL patches are not delivered yet,
although [3/4] and [4/4] were already done.
Does anti-spam system caught my previous three messages?
If necessary, I will send them again.
There is a file size limitation. If your patch is too big (I
Alvaro Herrera wrote:
Kohei KaiGai wrote:
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of patches
yet.
Please refer the pointed URL, as follows.
--
The series of patches are the proposal of Security-Enhanced PostgreSQL
Kohei KaiGai wrote:
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD terms?
All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push SE-PostgreSQL into
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD terms?
All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push
On Mon, 17 Mar 2008, KaiGai Kohei wrote:
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of patches
yet.
This is actually what you should have done from the beginning. And it
only should
KaiGai,
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Since I'm (Finally!) expecting the TrustedSolaris folks to put some work into
PostgreSQL as well this year, I'm going to ask them to look over
Josh Berkus wrote:
KaiGai,
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Since I'm (Finally!) expecting the TrustedSolaris folks to put some work into
PostgreSQL as well this year, I'm going to
Greg Smith wrote:
On Mon, 17 Mar 2008, KaiGai Kohei wrote:
I'll submit the proposal of SE-PostgreSQL patches again, because some
of previous
messages are filtered due to attachment and I cannot provide whole of
patches yet.
This is actually what you should have done from the beginning. And
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Mar 2008 10:41:42 +0900
KaiGai Kohei [EMAIL PROTECTED] wrote:
GPL is a perfectly good license, but it's far from clear whether
code derived from it can be incorporated into PostgreSQL even if
you wrote all of it yourself. I just
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Mar 2008 10:41:42 +0900
KaiGai Kohei [EMAIL PROTECTED] wrote:
GPL is a perfectly good license, but it's far from clear whether
code derived from it can be incorporated into PostgreSQL even if
you wrote all of it
Joshua D. Drake [EMAIL PROTECTED] writes:
Everything that I read says that libselinux is GPL.
What exactly did you read? The LICENSE file in the source tarball
says
: This library (libselinux) is public domain software, i.e. not copyrighted.
:
: Warranty Exclusion
: --
: You
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 17 Mar 2008 22:45:14 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Everything that I read says that libselinux is GPL.
What exactly did you read? The LICENSE file in the source tarball
says
I was
KaiGai,
A flexible framework is worthwhile for both operating systems.
Please confirm it to the TS folks.
Yep, that's the idea. Glenn was fine with your stuff last year, I expect
it'll still be fine.
Other than SELinux and TrustedSolaris, does anyone know of other role-based or
It seems to me some of SE-PostgreSQL patches are not delivered yet,
although [3/4] and [4/4] were already done.
Does anti-spam system caught my previous three messages?
If necessary, I will send them again.
Thanks,
Kohei KaiGai wrote:
The series of patches are the proposal of Security-Enhanced
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
[1/4] sepostgresql-pgace-8.4devel-3.patch
provides PGACE (PostgreSQL Access Control Extension) framework
[2/4]
57 matches
Mail list logo
