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:
http://www.postgresql.org/mail
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 <[EMAI
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
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,
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 def
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 accoun
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.
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
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:
> 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 | | ze
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
>> 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 consid
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
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 wo
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 t
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 loo
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
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 doe
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 pre-requ
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 h
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
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 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 opinio
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.
Aft
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 o
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
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 -
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 volum
"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 tr
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 pa
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 var
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 tentat
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 (
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
intere
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] sepostgresq
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 porin
Josh Berkus wrote:
> 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 kn
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
multilev
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 g
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 P
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 SE
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 in
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
(SE-Postgr
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 it
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
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 bi
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 limi
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
50 matches
Mail list logo
