* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
David Fetter wrote:
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
Just generally, access control is a great way to describe what's
actually happening here. That people conflate access control with
security has resulted in a
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.
pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
use in a number of other
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.
pg_ac_? Still shorter than 'security_', uses the
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.
pg_ac_? Still shorter than
Kohei kai...@kaigai.gr.jp; Robert Haas robertmh...@gmail.com;
pgsql-hackers@postgresql.org; Greg Williamson gwilliamso...@yahoo.com; Sam
Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com
Sent: Monday, August 3, 2009 12:09:45 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com:
I now plans to submit two patches for the next commit fest.
The one is implementation of the abstraction layer.
The other is basic implementation of the SE-PostgreSQL.
Is this a good idea, or would it be better to focus on the aclcheck
stuff (which
Robert Haas wrote:
2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com:
I now plans to submit two patches for the next commit fest.
The one is implementation of the abstraction layer.
The other is basic implementation of the SE-PostgreSQL.
Is this a good idea, or would it be better to focus on the
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
So, we may be able to modify the development plan as follows:
* 2nd CommitFest (15-Sep)
- security abstraction layer
(- largeobject permission)
* 3rd CommitFest (15-Nov)
- basic functionality of SE-PostgreSQL
* 4th CommitFest
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
So, we may be able to modify the development plan as follows:
* 2nd CommitFest (15-Sep)
- security abstraction layer
(- largeobject permission)
* 3rd CommitFest (15-Nov)
- basic functionality of SE-PostgreSQL
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
I began to describe the list of abstraction layer functions (but not
completed yet):
http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
I'm not really a huge fan of 'security_' as a prefix for these
functions, but I don't have a
On Mon, Aug 3, 2009 at 10:19 PM, Stephen Frostsfr...@snowman.net wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
So, we may be able to modify the development plan as follows:
* 2nd CommitFest (15-Sep)
- security abstraction layer
(- largeobject permission)
* 3rd CommitFest
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
I began to describe the list of abstraction layer functions (but not
completed yet):
http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
I'm not really a huge fan of 'security_' as a prefix for these
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
I began to describe the list of abstraction layer functions (but not
completed yet):
http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
I'm not really a huge
David Fetter wrote:
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
I began to describe the list of abstraction layer functions (but not
completed yet):
http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
I'm not
Stephen Frost wrote:
I think what I should do on the next is ...
- To check up whether it is really possible to implement SELinux's model.
- To describe the list of the security functions in the new abstraction
layer.
- To discuss the list of permission at:
robertmh...@gmail.com;
pgsql-hackers@postgresql.org; Greg Williamson gwilliamso...@yahoo.com; Sam
Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com
Sent: Monday, August 3, 2009 12:09:45 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote:
I think what I
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Please note that all we need to focus on is not pg_xxx_aclcheck() routines
in other words.
I agree, there may be other things which need to move to aclchk.c, and
that routine is a good example of something which would be appropriate
to move,
As Peter Eisentraut pointed out, we are not on the phase
to discuss about user documentations yet.
It is a reasonable idea to discuss correct specifications
of SE-PostgreSQL from the viewpoint of the developers.
Then, it will the a good source for the upcoming user docs.
For the recent a few
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
For the recent a few days, I've worked to write and edit
the specification (partially copied from the draft of user
documentation) for the development purpose.
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development
Thanks for doing
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
For the recent a few days, I've worked to write and edit
the specification (partially copied from the draft of user
documentation) for the development purpose.
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
Strategy for code changes:
Patch #1: Move permissions checks currently implemented in other parts
of the code (eg: tablecmds.c:ATExecChangeOwner()) into
aclchk.c.
Patch #2:
On Fri, Jul 31, 2009 at 5:13 PM, Stephen Frostsfr...@snowman.net wrote:
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
Strategy for code changes:
Patch #1: Move permissions checks currently implemented in other parts
of the code (eg:
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
Strategy for code changes:
Patch #1: Move permissions checks currently implemented in other parts
of the code (eg: tablecmds.c:ATExecChangeOwner()) into
Robert Haas wrote:
FWIW, pretty much +1 from me on everything in here; I think this is
definitely going in the right direction. It's not the size of the
patches that matter; it's the complexity and difficulty of verifying
that they don't break anything. And it's not cumulative: three easy
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
It seems to me your suggestion is similar to the idea of PGACE framework.
It is, but it's being done as incremental changes to the existing
structures, and working with them, instead of ignoring that they exist.
Let's consider the matter
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
As I noted in the reply to Stephen Frost, what should be controled
(e.g, ALTER TABLE) and how to check it (e.g, ownership based control)
are different things.
If we go on the direction to restructure the current aclcheck mechanism
and to integrate
Stephen Frost wrote:
For example:
void pg_security_alter_table(Oid relid)
{
if (!pg_class_ownercheck(relid, GetUserId())
aclcheck_error(...);
if (!sepgsqlCheckTableSetattr(relid))
selinux_error(...);
}
Right, something along these lines, where the
Peter Eisentraut wrote:
On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
security context, security policy and
On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and because SE-PG isn't self contained I really think you
need to link to them.
This is
...@ak.jp.nec.com
To: KaiGai Kohei kai...@kaigai.gr.jp
Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
On Mon, Jul 27, 2009 at 01:53:07PM -0400, Chris Browne wrote:
s...@samason.me.uk (Sam Mason) writes:
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
Robert Haas wrote:
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements
...@kaigai.gr.jp
Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org
Sent: Tuesday, July 28, 2009 1:20:29 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Thanks for the updates.
I might suggest a couple of small changes:
a) a section that explains comments like This is not supported
Peter Eisentraut wrote:
On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and because SE-PG isn't self contained I really think you
need to
, July 28, 2009 1:20:29 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Thanks for the updates.
I might suggest a couple of small changes:
a) a section that explains comments like This is not supported in the initial
version -- do you
mean in the first Beta release of SE-PostgreSQL
On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and
To: KaiGai Kohei kai...@kaigai.gr.jp
Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
s...@samason.me.uk (Sam Mason) writes:
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
Robert Haas wrote:
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements also.
OK, so there is some other trusted entity that has unfettered
Chris Browne wrote:
s...@samason.me.uk (Sam Mason) writes:
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
Robert Haas wrote:
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements also.
OK, so there is some other trusted entity
KaiGai --
I have a few suggestions which I will post in a bit, and some rather extensive
edits of the existing Wiki, mostly for syntax rather than content.
How do you want the latter ? I can email them offline as text, or you could set
me up with a login on the wiki and I could do them in
Greg Williamson wrote:
KaiGai --
I have a few suggestions which I will post in a bit, and some
rather extensive edits of the existing Wiki, mostly for syntax
rather than content.
How do you want the latter ? I can email them offline as text,
or you could set me up with a login on the
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
Robert Haas wrote:
Sam Mason wrote:
The traditional approach would be to maintain multiple physically
separate databases; in this setup it's obvious that when you perform a
backup of one of these databases you're only seeing a
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
Indeed, the draft used the term of security context with minimum
introductions, but not enough friendliness for database folks.
The purpose of security context is an identifier of any subject and
object to describe them in the
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called unconfined.
However, it is also *possible* to define a new special process privilege
for backup and restore tools. For example, it can access
Sam Mason wrote:
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
Indeed, the draft used the term of security context with minimum
introductions, but not enough friendliness for database folks.
The purpose of security context is an identifier of any subject and
object to describe
Andrew Dunstan wrote:
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called unconfined.
However, it is also *possible* to define a new special process privilege
for backup and restore tools. For
KaiGai Kohei wrote:
Andrew Dunstan wrote:
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called
unconfined.
However, it is also *possible* to define a new special process
privilege
for
Robert Haas wrote:
If you want to store intelligence data about the war in Iraq and
intelligence data about the war in Afghanistan, it might not be too
bad to store them in separate databases, though storing them in the
same database might also make things simpler for users who have access
to
Andrew Dunstan wrote:
KaiGai Kohei wrote:
Andrew Dunstan wrote:
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called
unconfined.
However, it is also *possible* to define a new special
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:
CREATE OR REPLACE FUNCTION show_customers
Sam Mason wrote:
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:
CREATE OR REPLACE FUNCTION
Sam Mason s...@samason.me.uk writes:
Yes, that seems reasonable. The fact that you're still talking about
confined users is slightly worrying and would seem to imply that
there is still a superuser/normal user divide--it's probably just a
terminology thing though.
There had better still be
On Jul 25, 2009, at 11:06 AM, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
Yes, that seems reasonable. The fact that you're still talking about
confined users is slightly worrying and would seem to imply that
there is still a superuser/normal user divide--it's probably just a
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
Sorry for using the undefined terminology.
I think this is the largest missing part of the docs at the moment;
there is a whole new world of definitions that need to be understood
before the SE-PG stuff is understandable/usable by
On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
There had better still be superusers. Or do you want the correctness
of your backups to depend on whether your SELinux policy is correct?
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote:
On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
There had better still be superusers. Or do you want the correctness
of your backups to depend on whether your SELinux policy is correct?
I thought the whole point of
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote:
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the power they currently do.
It's been billed that way, but it's not
Sam Mason wrote:
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
Sorry for using the undefined terminology.
I think this is the largest missing part of the docs at the moment;
there is a whole new world of definitions that need to be understood
before the SE-PG stuff is
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote:
| Access control is conceptually to decide a set of allowed (or denied)
| actions between a certain subject (such as a database client) and an
| object (such as a table), and to apply the decision on user's requests.
| At
Robert Haas wrote:
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote:
| Access control is conceptually to decide a set of allowed (or denied)
| actions between a certain subject (such as a database client) and an
| object (such as a table), and to apply the decision on
On Sat, Jul 25, 2009 at 7:49 PM, Sam Masons...@samason.me.uk wrote:
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote:
I thought the whole point of MAC was that superusers don't exist any
more--at least not with
Sam Mason wrote:
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote:
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the power they currently do.
It's been billed that
Robert Haas wrote:
If superusers DON'T exist, that would be making the opposite
statement, namely, that there isn't ANY WAY to get a backup that you
can be sure DOES contain all of the objects.
The traditional approach would be to maintain multiple physically
separate databases; in this setup
Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got
some non-work related issues which may keep from giving this a good look until
the weekend (FWIW). I'll post any questions I have.
Thanks,
Greg W.
- Original Message
From: KaiGai Kohei kai...@ak.jp.nec.com
On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really obvious language stuff and an
Martijn van Oosterhout wrote:
On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Thanks for this, it really does help, I believe. I've been reviewing it
and am also planning on helping refine and improve
On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frostsfr...@snowman.net wrote:
Thanks for this, it really does help, I believe. I've been reviewing it
and am also planning on helping refine and improve upon it. I'd like to
spend time working on the patch as well but I'm hesitant to commit to
that
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
Thanks, but I found an incorrect change at the trusted procedure section.
Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
- SECURITY_LABEL =
Sam Mason wrote:
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
Thanks, but I found an incorrect change at the trusted procedure section.
Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
-
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have a row
in the
Sam Mason wrote:
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
I've described it from the scratch again with paying attention
for the people knowing nothing about SELinux.
In some points, it uses comparison between the database privilege
mechanism
73 matches
Mail list logo
