Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost 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 'secur
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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_ p
Stephen Frost 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 places,
* 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 result
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_Abstrac
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
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 th
On Mon, Aug 3, 2009 at 10:19 PM, 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-No
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
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
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 CommitFe
Robert Haas wrote:
> 2009/8/3 KaiGai Kohei :
>> 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
> st
2009/8/3 KaiGai Kohei :
> 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 is what I understan
gt; - Original Message
> From: KaiGai Kohei
> To: Stephen Frost
> Cc: KaiGai Kohei ; Robert Haas ;
> pgsql-hackers@postgresql.org; Greg Williamson ; Sam
> Mason ; Joshua Brindle
> Sent: Monday, August 3, 2009 12:09:45 AM
> Subject: Re: [HACKERS] SE-PostgreSQL Specif
mson ; Sam
Mason ; Joshua Brindle
Sent: Monday, August 3, 2009 12:09:45 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
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.
>&
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:
>>
>> http://wiki.post
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,
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 thes
* 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 i
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 mo
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
patch
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
>>>
On Fri, Jul 31, 2009 at 5:13 PM, 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:ATExecC
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.
> > Patc
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.
>>
>> http://wiki.postgresql.org/wiki/SEPostgreS
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 doin
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 days
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) definition
ve a few paragraphs done so you can check it and see
> if you approve.
>
> Apologies for top-posting -- lame mailer.
>
> Greg W.
>
>
>
>
> - Original Message
> From: KaiGai Kohei
> To: KaiGai Kohei
> Cc: Sam Mason ; pgsql-hackers@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 outs
Apologies for top-posting -- lame mailer.
Greg W.
- Original Message
From: KaiGai Kohei
To: KaiGai Kohei
Cc: Sam Mason ; pgsql-hackers@postgresql.org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specif
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 l
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 in the initial
version" -- do you
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 requi
- Original Message
From: KaiGai Kohei
To: KaiGai Kohei
Cc: Sam Mason ; 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 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
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 "m
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
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 plac
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 tr
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 unf
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 proc
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
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 back
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
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
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
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 t
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 se
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 it
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 Mason 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 real
On Sat, Jul 25, 2009 at 7:49 PM, 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 Mason 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.
>
Robert Haas wrote:
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Kohei 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 t
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Kohei 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 the database pr
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 understan
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason 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 really accu
On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason 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 MAC was tha
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 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 any
On Jul 25, 2009, at 11:06 AM, Tom Lane wrote:
Sam Mason 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
Sam Mason 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 superusers. O
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 s
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_
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 a
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
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)
- SECURITY_LABE
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 =
On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frost 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 right now due to
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 u
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 t
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
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
To: Robert Haas
Cc:
72 matches
Mail list logo
