subject:"\[HACKERS\] SE\-PostgreSQL Specifications"

Greg Williamson wrote:
 KaiGai --
 
 I was pulled away from any work on this for a few days ... what can I do
 to help, if anything ? (Keeping in mind that my knowledge of the internals
 of postgres is, alas, minimal.) ... I had a quick look at this new page and
 want to take another, more careful, look.

I got a few reasonable sugegstions at the last week.
The one is it is important to provide a design specification from the viewpoint
of developers to make clear what features are provided by SE-PostgreSQL, and
it will be a good source for the official documentation for users.
The other is a suggestion corresponding to the way to implement it. Its 
conclusion
was to inject an abstraction layer to support multiple security models at first.

I guess Robert concerned about my English quality in the documentation patch
contained in the proposed patch set at first. In same time, lack of design
specification was pointed out. It also should be provided prior to the patch
to make clear what is identical to/different from the native database privilege
mechanism.

Both of them are documentations. But these have their own purpose, target and
style to be required. It might be a causion of the confusion.

In my current opinion, we should have a discussion corresponding to the design
specifications and internals, and implement it prior to the user documentation.

So, I would like you to give me the time to conclude the design specifications
and to implement patches for the next commit fest.

 The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge
 a certain minimalism at first to prove that the concept works and doesn't 
 damage
 the core functionality at all when it is not used (fairly straight forward).
 Eventually rough measures of the performance hit when it is used will be 
 useful,
 but users will expect something of a slow-down, I suspect, in exchange foe the
 greater security.

Are you talking about what the user documentation should include, aren't you?
Indeed, I also think these items should be introduced.


 To that end, I am wondering if there is test data yet designed ? Are there
 prescribed tests (I remember seeing some but they seem to be buried in
 months/threads that I have not yet re-dicsovered) ? I have some experience 
 doing
 QA and could perhaps also help in these, a little.

I also provided a patch for the testcases of SE-PostgreSQL.

For example:
  http://code.google.com/p/sepgsql/source/browse/tags/sepgsql/src/test/sepgsql

Thanks,

 And let me add, I am in awe of your efforts on this !
 
 G
 
 
 
 - Original Message 
 From: KaiGai Kohei kai...@ak.jp.nec.com
 To: Stephen Frost sfr...@snowman.net
 Cc: KaiGai 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
 
 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.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
 That sounds like a good approach.  As we define the security functions
 to go into the abstraction layer, I would also say we should identify
 the exact pieces of existing code which are going to move.
 
 I began to describe the list of abstraction layer functions (but not 
 completed yet):
   http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
 
 In my current impression, it indeed requires a few kilo lines of changes,
 but it is not impossible scale.
 
 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.
 
 So, I would like to fix external specification at least.
 
 The specifications for developer notes definitions of permissions:
   http://wiki.postgresql.org/wiki/SEPostgreSQL_Development
 
 As Robert suggested before, I plans to support access controls on the
 following database objects and permissions at the first stage.
 * databases
 * schemas
 * tables
 * columns
 * sequences
 * functions
 * tablespaces
 
 Do you have any comment for the directions?
 
 Thanks,


-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-03 Thread Robert Haas

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 is what I understand you to mean here by abstraction
layer) first?  You will be much happier getting one patch committed
than two patches not committed...  getting two patches of this size in
one CommitFest seems very unlikely, and I worry that the SE-PostgreSQL
patch will distract your time and reviewing time from the aclcheck
refactoring that must get done first, and well.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 aclcheck
 stuff (which is what I understand you to mean here by abstraction
 layer) first?  You will be much happier getting one patch committed
 than two patches not committed...  getting two patches of this size in
 one CommitFest seems very unlikely, and I worry that the SE-PostgreSQL
 patch will distract your time and reviewing time from the aclcheck
 refactoring that must get done first, and well.

Needless to say, the security abstraction layer shall have higher
priority than SE-PostgreSQL which depends on the layer.

If we can focus on the SE-PostgreSQL feature in the third commit fest,
it will be better than all the facilities from the scratch.
(BTW, I also have a WIP patch to support largeobject permissions.)

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 (15-Jan)
 - full functionality of SE-PostgreSQL
   (row-level controls, filesystem permissions, ...)

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-03 Thread Stephen Frost

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 (15-Jan)
  - full functionality of SE-PostgreSQL
(row-level controls, filesystem permissions, ...)

Not to throw water on this right from the get-go, but I think getting
the security abstraction and basic SE-PostgreSQL functionality (based on
existing PG permissions) into 8.5 will be enough of a stretch.
row-level security needs to be implement in PG proper first, before we
can add the SE-PG hooks for it.  That's going to be a serious amount of
work by itself, and is something which is extremely unlikely to make
sense to commit that late in the cycle.

Let's focus on improving aclchk.c to the point where SE-PG can be
easily added without dropping hooks all over the place.  If we can get
that into 8.5 it will be a huge success.  We can then work on row-level
permissions for 8.6, first as a PG-native feature, and then with SE-PG
hooks.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

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

 * 4th CommitFest (15-Jan)
  - full functionality of SE-PostgreSQL
(row-level controls, filesystem permissions, ...)
 
 Not to throw water on this right from the get-go, but I think getting
 the security abstraction and basic SE-PostgreSQL functionality (based on
 existing PG permissions) into 8.5 will be enough of a stretch.
 row-level security needs to be implement in PG proper first, before we
 can add the SE-PG hooks for it.  That's going to be a serious amount of
 work by itself, and is something which is extremely unlikely to make
 sense to commit that late in the cycle.

It seems to me it is a bit early to conclude what feature will be
included into 8.5 and what feature is not so.
The above plan is a very rough sketch.
Anyway, what I would like to say is I can agree to focus on the security
abstraction layer earlier than SE-PostgreSQL feature.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-03 Thread Stephen Frost

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 better suggestion right now.

The initial abstraction patch shouldn't include the security context
pieces.  I realize that will be needed eventually, but the patch to do
the abstraction and to formally move permissions checking to aclchk.c
needs to stand alone.  I'm also not sure that the API of having the
security context be returned as a Datum makes sense..

Doesn't security_table_permissions() need to know if the query is an
UPDATE or an INSERT?

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-03 Thread Robert Haas

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 (15-Nov)
  - basic functionality of SE-PostgreSQL

 * 4th CommitFest (15-Jan)
  - full functionality of SE-PostgreSQL
    (row-level controls, filesystem permissions, ...)

 Not to throw water on this right from the get-go, but I think getting
 the security abstraction and basic SE-PostgreSQL functionality (based on
 existing PG permissions) into 8.5 will be enough of a stretch.
 row-level security needs to be implement in PG proper first, before we
 can add the SE-PG hooks for it.  That's going to be a serious amount of
 work by itself, and is something which is extremely unlikely to make
 sense to commit that late in the cycle.

+1.  Optimism is good, realism is better.

 Let's focus on improving aclchk.c to the point where SE-PG can be
 easily added without dropping hooks all over the place.  If we can get
 that into 8.5 it will be a huge success.  We can then work on row-level
 permissions for 8.6, first as a PG-native feature, and then with SE-PG
 hooks.

Row-level security is going to be a very, very difficult feature to
implement properly.  A lot of thought is needed here to design
something good.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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
 functions, but I don't have a better suggestion right now.

If so, 'pgsec_' (PostGresql SECutiry) instead?

 The initial abstraction patch shouldn't include the security context
 pieces.  I realize that will be needed eventually, but the patch to do
 the abstraction and to formally move permissions checking to aclchk.c
 needs to stand alone.  I'm also not sure that the API of having the
 security context be returned as a Datum makes sense..

OK, I'll add pieces corresponding to the security context on the second
patch (SE-PostgreSQL patch).

 Doesn't security_table_permissions() need to know if the query is an
 UPDATE or an INSERT?

Either ACL_UPDATE or ACL_INSERT should be set on the required_perms.
Both of them are never set in same time.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-03 Thread David Fetter

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 fan of 'security_' as a prefix for these
 functions, but I don't have a better suggestion right now.

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 number of disasters :P

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 really a huge fan of 'security_' as a prefix for these
 functions, but I don't have a better suggestion right now.
 
 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 number of disasters :P

My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.
 - To describe the list of the security functions in the new abstraction 
 layer.
 - To discuss the list of permission at:
   
 http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
 
 That sounds like a good approach.  As we define the security functions
 to go into the abstraction layer, I would also say we should identify
 the exact pieces of existing code which are going to move.

I began to describe the list of abstraction layer functions (but not completed 
yet):
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction

In my current impression, it indeed requires a few kilo lines of changes,
but it is not impossible scale.

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.

So, I would like to fix external specification at least.

The specifications for developer notes definitions of permissions:
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

As Robert suggested before, I plans to support access controls on the
following database objects and permissions at the first stage.
 * databases
 * schemas
 * tables
 * columns
 * sequences
 * functions
 * tablespaces

Do you have any comment for the directions?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-03 Thread Greg Williamson


KaiGai --

I was pulled away from any work on this for a few days ... what can I do to 
help, if anything ? (Keeping in mind that my knowledge of the internals of 
postgres is, alas, minimal.) ... I had a quick look at this new page and want 
to take another, more careful, look.

The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge a 
certain minimalism at first to prove that the concept works and doesn't damage 
the core functionality at all when it is not used (fairly straight forward). 
Eventually rough measures of the performance hit when it is used will be 
useful, but users will expect something of a slow-down, I suspect, in exchange 
foe the greater security.

To that end, I am wondering if there is test data yet designed ? Are there 
prescribed tests (I remember seeing some but they seem to be buried in 
months/threads that I have not yet re-dicsovered) ? I have some experience 
doing QA and could perhaps also help in these, a little.

And let me add, I am in awe of your efforts on this !

G



- Original Message 
From: KaiGai Kohei kai...@ak.jp.nec.com
To: Stephen Frost sfr...@snowman.net
Cc: KaiGai 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

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.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
 
 That sounds like a good approach.  As we define the security functions
 to go into the abstraction layer, I would also say we should identify
 the exact pieces of existing code which are going to move.

I began to describe the list of abstraction layer functions (but not completed 
yet):
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction

In my current impression, it indeed requires a few kilo lines of changes,
but it is not impossible scale.

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.

So, I would like to fix external specification at least.

The specifications for developer notes definitions of permissions:
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

As Robert suggested before, I plans to support access controls on the
following database objects and permissions at the first stage.
* databases
* schemas
* tables
* columns
* sequences
* functions
* tablespaces

Do you have any comment for the directions?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



  

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-01 Thread Stephen Frost

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, abstract, and provide an SELinux hook for, in aclchk.c.

 The example is not dramatically different from the others, indeed.
 But, this code implicitly assume the database superuser can do anyhting,
 so the necessary checks are omitted from the code (because they always
 return allowed).

Yes, I realize that's a problem.  I don't know that it's a problem which
has to be addressed in the first round, but I do believe we will get
there.

 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.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls

That sounds like a good approach.  As we define the security functions
to go into the abstraction layer, I would also say we should identify
the exact pieces of existing code which are going to move.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

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, 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

I would like to have a discussion for its design specifications
and make clear anything unclear for pgsql folks (including the
quality of English).

Because this wikipage intends to provide the specifications
from the viewpoint of developers, it describes features more
detailed than the user visible documentation.

I intended to describe the features correctly, but it does not
mean perfect, needless to say.
Please feel free to ask / point out me, if something unclear or
not-easy understandable.

Thanks,


KaiGai Kohei wrote:
 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 and SE-PostgreSQL for easy understanding.
 
 Please point out, if ...
 - Its composition can be improved.
 - Here is not enough introductions for what user wants to know.
 - Here is too much explanations, more brief one will be available.
 - Here is not easy understandable for database folks.
 - Here is not enough English quality.
 - And so on...
 
 In addition, I would like to fix its specifications during the discussion.
 
 Thanks,


-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 this.  I've taken a quick glance through it and will
review it more later today.  The next step, I believe, is to document
the changes which need to be made to PG, at a high level, to support
this specification.  

I think the initial goal should be to make changes mainly to aclchk.c to
add the SELinux hooks.  I'd like to hear from some committers about this
idea: I think we should also be looking to move more of the permissions
checking which is done in other parts of the code (eg:
ATExecChangeOwner()) into aclchk.c, which is where I would argue it
belongs.  Doing so will make it much easier to add other hooks, should
the need arise, and would minimize the amount of code 'touched' to add
SELinux support.

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: Change the aclchk.c function APIs, if necessary, to add
additional information required for SELinux (eg: the 'old'
owner).
  Patch #3: Add SELinux hooks into aclchk.c functions.

This initial round, again, should focus on just those
controls/permissions which PostgreSQL already supports.  At this time,
do not stress over finding every if(superuser()) and moving it to
aclchk.c.  Let's deal with the clear situations, such as tablecmds.c
lines 6322-6342 (that entire block, including the if(!superuser()),
should be ripped out and made a function in aclchk.c which is called
with necessary args).  We can go back and clean up the other places
where we have explicit superuser() checks later, if necessary.

I've finally had a chance to look through the last set of proposed
patches some, and I've noticed some other issues that need to be
addressed:

- Let's avoid the changes to heaptuple.c for now.  That's really for
  much later down the road when we implement row-level security.
- I would expect the dependency system to be used to handle deleting
  things from pg_security, etc, when an object has been deleted (eg: a
  table was dropped).
- Conversly, when new entries need to be added to pg_security, they
  should be done at the same level as other items being added to the
  catalog.  In places like createdb(), where it's all one big function,
  I would recommend splitting out the existing catalog update into a
  separate function, which then makes it much clearer that the code is
  doing: update pg_database table, update pg_security table, update
  pg_dependency table.  That should be done as a separate patch, of
  course.  Remember, we're trying to make small incremental changes that
  make sense by themselves but at the same time will reduce the effort
  required to add SELinux later.
- In terms of cacheing the results, is there any way we could use
  SysCache for this?  And just handle the cacheing in the hooks, etc,
  from aclchk.c?  I dislike having the security labels added to
  every tuple until we actually implement row level security.  It adds
  alot of unnecessary complexity to the initial implementation.
  Note that I'm referring to the results from the kernel/syscalls, I
  realize you're using SysCache properly for the entries in pg_security
  already, and that's good.

Guess that's a start on the implementation design, which I feel is the
next step after specification.  Perhaps you could start a wiki page on
it which includes my comments?  I'm in meetings for the next couple of
hours, but will resume looking at this after lunch, US/Eastern time.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

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/SEPostgreSQL_Development
 
 Thanks for doing this.  I've taken a quick glance through it and will
 review it more later today.  The next step, I believe, is to document
 the changes which need to be made to PG, at a high level, to support
 this specification.  

Thanks for your help.

I also think it is necessary to describe what changes are needed on
the core pgsql except for security routines.

It is just an example:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#security_hooks_.28example.29

I believe such kind of specifications are necessary at the next.

 I think the initial goal should be to make changes mainly to aclchk.c to
 add the SELinux hooks.  I'd like to hear from some committers about this
 idea: I think we should also be looking to move more of the permissions
 checking which is done in other parts of the code (eg:
 ATExecChangeOwner()) into aclchk.c, which is where I would argue it
 belongs.  Doing so will make it much easier to add other hooks, should
 the need arise, and would minimize the amount of code 'touched' to add
 SELinux support.
 
 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: Change the aclchk.c function APIs, if necessary, to add
 additional information required for SELinux (eg: the 'old'
   owner).
   Patch #3: Add SELinux hooks into aclchk.c functions.

Thanks for your idea. However, it seems to me this approach eventually
requires bigger changeset than what the current security hooks doing.
In addition, it cannot solve the differences in behavior due to the
security model on which they stand.

For example, when we create a new table, the native database privilege
mechanism checks its permission on the schema object which the new
table blongs to. On the other hand, SELinux requires to check
db_table:{create} permission on the newly created table itself.

In my understanding, the purpose of the design specification is to make
clear for database folks what the security hooks doin and why the security
hooks are deployed here.

Linux kernel is a good case in success.
Needless to say, most of kernel developer are not security experts.
But they defined an explicit specification of the security hooks called
LSM, and put these hooks on the strategic points in the kernel.
(The very long source code comments describes what is the purpose of this
security hook, what arguments should be given and so on for each security
hooks.)

 This initial round, again, should focus on just those
 controls/permissions which PostgreSQL already supports.  At this time,
 do not stress over finding every if(superuser()) and moving it to
 aclchk.c.  Let's deal with the clear situations, such as tablecmds.c
 lines 6322-6342 (that entire block, including the if(!superuser()),
 should be ripped out and made a function in aclchk.c which is called
 with necessary args).  We can go back and clean up the other places
 where we have explicit superuser() checks later, if necessary.

At least, it works correctly as far as the native database privilege
mechanism. If the specification of the security hooks is clear, I think
the following manner is better than modifying DAC mechanism.

  if (!superuser())
  {
  if (pg_xxx_aclcheck() != ACLCHECK_OK)
  aclcheck_error();
  }
+ sepgsqlCheck();

 I've finally had a chance to look through the last set of proposed
 patches some, and I've noticed some other issues that need to be
 addressed:
 
 - Let's avoid the changes to heaptuple.c for now.  That's really for
   much later down the road when we implement row-level security.

Yes, I can agree to postpone pg_security and corresponding facilities
until row-level security.

 - I would expect the dependency system to be used to handle deleting
   things from pg_security, etc, when an object has been deleted (eg: a
   table was dropped).

In the patch for v8.4.x series (with fullset functionality), it is
already implemented. Any entries within pg_security referenced by the
dropped table is reclaimed, when we drop a table.
The matter of orphan entries are already solved.

 - Conversly, when new entries need to be added to pg_security, they
   should be done at the same level as other items being added to the
   catalog.  In places like createdb(), where it's all one big function,
   I would recommend splitting out the existing catalog update into a
   separate function, which then makes it much clearer that the code is
   doing: update pg_database table, update pg_security table, update
   pg_dependency table.  That should be

Re: [HACKERS] SE-PostgreSQL Specifications

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: Change the aclchk.c function APIs, if necessary, to add
  additional information required for SELinux (eg: the 'old'
  owner).
Patch #3: Add SELinux hooks into aclchk.c functions.
 
 Thanks for your idea. However, it seems to me this approach eventually
 requires bigger changeset than what the current security hooks doing.

Yes, it almost certainly will.  However, this is really the approach
that I think we need to take.  I think what we're beginning to
understand, collectivly, is something that some of the committers, etc,
have been saying all along- implementing SELinux in PG requires alot
more changes to PG than just sprinkling hooks all over the code.  This
is because we want to do it right, for PG, and for our users.

What this means is that we need to improve the PG code first.  Then,
when we're happy with those changes, we can add the SELinux hooks and be
comfortable that they will operate correctly, do what they're intended
to, and also allow us to extend the system further for the next big
privileges thing, if that happens some day.

 In addition, it cannot solve the differences in behavior due to the
 security model on which they stand.
 
 For example, when we create a new table, the native database privilege
 mechanism checks its permission on the schema object which the new
 table blongs to. On the other hand, SELinux requires to check
 db_table:{create} permission on the newly created table itself.

That's fine.  We implement a function in aclchk.c which is essentially
pg_createTablePriv(schema,newtable).  The logic for doing the check is
moved out of tablecmds.c (or where ever) and into that function.  We can
then easily add to that function the SELinux hook.  Is there some issue
here which I'm not seeing?  If so, can you please clarify?

Also, I don't see db_table:{create} in the documentation anywhere.
There is a db_schema:{add_name}, is that what you're referring to?
How would you check the permissions on an object (and how or why would
they be different than the default, unless that's also being handled at
the creation time) which is in the process of being created?

 In my understanding, the purpose of the design specification is to make
 clear for database folks what the security hooks doin and why the security
 hooks are deployed here.

I don't think we're going to have much buy-in or success sprinkling
these hooks all over the PG source code.  It would make maintenance a
real problem for the PG folks and for those of us trying to work with
SE.  The SELinux hooks really need to be folded into PG's existing
authentication system, and if that system needs to be improved or
expanded, then that's what it requires.

 Linux kernel is a good case in success.
 Needless to say, most of kernel developer are not security experts.
 But they defined an explicit specification of the security hooks called
 LSM, and put these hooks on the strategic points in the kernel.
 (The very long source code comments describes what is the purpose of this
 security hook, what arguments should be given and so on for each security
 hooks.)

Right, we have a number of these already, and they are represented by
the aclchk.c functions.  The problem that SELinux points out is that
we've not been consistant with having aclchk.c do the permissions
checking.  Specifically on the simple stuff where we currently require
owner rights.  What we need to do is improve PG by pulling those checks
out of the areas they are, spread all around the code, and consolidating
them into aclchk.c (or a new file if that is deisred).  We're not going
to get anywhere by trying to add on more hooks all over the code.

  This initial round, again, should focus on just those
  controls/permissions which PostgreSQL already supports.  At this time,
  do not stress over finding every if(superuser()) and moving it to
  aclchk.c.  Let's deal with the clear situations, such as tablecmds.c
  lines 6322-6342 (that entire block, including the if(!superuser()),
  should be ripped out and made a function in aclchk.c which is called
  with necessary args).  We can go back and clean up the other places
  where we have explicit superuser() checks later, if necessary.
 
 At least, it works correctly as far as the native database privilege
 mechanism. If the specification of the security hooks is clear, I think
 the following manner is better than modifying DAC mechanism.
 
   if (!superuser())
   {
   if (pg_xxx_aclcheck() != ACLCHECK_OK)
   aclcheck_error();
   }
 + sepgsqlCheck();

Again, this would mean dropping sepgsql() calls all over the code,
because we don't currently have all of these permission checks

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-31 Thread Robert Haas

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: tablecmds.c:ATExecChangeOwner()) into
                      aclchk.c.
    Patch #2: Change the aclchk.c function APIs, if necessary, to add
              additional information required for SELinux (eg: the 'old'
                      owner).
    Patch #3: Add SELinux hooks into aclchk.c functions.

 Thanks for your idea. However, it seems to me this approach eventually
 requires bigger changeset than what the current security hooks doing.

 Yes, it almost certainly will.  However, this is really the approach
 that I think we need to take.  I think what we're beginning to
 understand, collectivly, is something that some of the committers, etc,
 have been saying all along- implementing SELinux in PG requires alot
 more changes to PG than just sprinkling hooks all over the code.  This
 is because we want to do it right, for PG, and for our users.

 What this means is that we need to improve the PG code first.  Then,
 when we're happy with those changes, we can add the SELinux hooks and be
 comfortable that they will operate correctly, do what they're intended
 to, and also allow us to extend the system further for the next big
 privileges thing, if that happens some day.

 In addition, it cannot solve the differences in behavior due to the
 security model on which they stand.

 For example, when we create a new table, the native database privilege
 mechanism checks its permission on the schema object which the new
 table blongs to. On the other hand, SELinux requires to check
 db_table:{create} permission on the newly created table itself.

 That's fine.  We implement a function in aclchk.c which is essentially
 pg_createTablePriv(schema,newtable).  The logic for doing the check is
 moved out of tablecmds.c (or where ever) and into that function.  We can
 then easily add to that function the SELinux hook.  Is there some issue
 here which I'm not seeing?  If so, can you please clarify?

 Also, I don't see db_table:{create} in the documentation anywhere.
 There is a db_schema:{add_name}, is that what you're referring to?
 How would you check the permissions on an object (and how or why would
 they be different than the default, unless that's also being handled at
 the creation time) which is in the process of being created?

 In my understanding, the purpose of the design specification is to make
 clear for database folks what the security hooks doin and why the security
 hooks are deployed here.

 I don't think we're going to have much buy-in or success sprinkling
 these hooks all over the PG source code.  It would make maintenance a
 real problem for the PG folks and for those of us trying to work with
 SE.  The SELinux hooks really need to be folded into PG's existing
 authentication system, and if that system needs to be improved or
 expanded, then that's what it requires.

 Linux kernel is a good case in success.
 Needless to say, most of kernel developer are not security experts.
 But they defined an explicit specification of the security hooks called
 LSM, and put these hooks on the strategic points in the kernel.
 (The very long source code comments describes what is the purpose of this
 security hook, what arguments should be given and so on for each security
 hooks.)

 Right, we have a number of these already, and they are represented by
 the aclchk.c functions.  The problem that SELinux points out is that
 we've not been consistant with having aclchk.c do the permissions
 checking.  Specifically on the simple stuff where we currently require
 owner rights.  What we need to do is improve PG by pulling those checks
 out of the areas they are, spread all around the code, and consolidating
 them into aclchk.c (or a new file if that is deisred).  We're not going
 to get anywhere by trying to add on more hooks all over the code.

  This initial round, again, should focus on just those
  controls/permissions which PostgreSQL already supports.  At this time,
  do not stress over finding every if(superuser()) and moving it to
  aclchk.c.  Let's deal with the clear situations, such as tablecmds.c
  lines 6322-6342 (that entire block, including the if(!superuser()),
  should be ripped out and made a function in aclchk.c which is called
  with necessary args).  We can go back and clean up the other places
  where we have explicit superuser() checks later, if necessary.

 At least, it works correctly as far as the native database privilege
 mechanism. If the specification of the security hooks is clear, I think
 the following manner is better than modifying DAC mechanism.

   if (!superuser())
   {
       if (pg_xxx_aclcheck() != ACLCHECK_OK)
           aclcheck_error();
   }
 + sepgsqlCheck();

 Again, this would mean

Re: [HACKERS] SE-PostgreSQL Specifications

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
 aclchk.c.
   Patch #2: Change the aclchk.c function APIs, if necessary, to add
 additional information required for SELinux (eg: the 'old'
 owner).
   Patch #3: Add SELinux hooks into aclchk.c functions.
 Thanks for your idea. However, it seems to me this approach eventually
 requires bigger changeset than what the current security hooks doing.
 
 Yes, it almost certainly will.  However, this is really the approach
 that I think we need to take.  I think what we're beginning to
 understand, collectivly, is something that some of the committers, etc,
 have been saying all along- implementing SELinux in PG requires alot
 more changes to PG than just sprinkling hooks all over the code.  This
 is because we want to do it right, for PG, and for our users.
 
 What this means is that we need to improve the PG code first.  Then,
 when we're happy with those changes, we can add the SELinux hooks and be
 comfortable that they will operate correctly, do what they're intended
 to, and also allow us to extend the system further for the next big
 privileges thing, if that happens some day.

When I scraped the idea of PGACE framework, someone (IIRC, Robert Haas) asked
me whether it is possible to implement the native database privilege mechanism
on the PGACE, or not.
It seems to me your suggestion is similar to the idea of PGACE framework.
But, note that it does not mean I criticize your idea.

Let's consider the matter more using a few examples.

Example 1) ALTER TABLE xxx
The native database privilege mechanism checks the ownership of the target
table to control the ALTER TABLE. On the other hand, SE-PgSQL checks the
db_table:{setattr} permission on the target table to control the ALTER TABLE.

I believe you can notice both of checks have same purpose but differences are
on the criterions. It is the way to make their decisions in other word.

The pg_xxx_aclcheck() interfaces provide the way to make its access control
decision. The core PG code calls pg_xxx_aclcheck() to achieve its purpose
which is to apply access controls on ALTER TABLE.

Accordingly, if we avoid to put SE-PgSQL's security hooks on the tablecmd.c
directly, what we should do is to inject an abstraction layer between tablecmd.c
and aclchk.c.

For example:
  void pg_security_alter_table(Oid relid)
  {
  if (!pg_class_ownercheck(relid, GetUserId())
  aclcheck_error(...);

  if (!sepgsqlCheckTableSetattr(relid))
  selinux_error(...);
  }

Example 2) DROP TABLE xxx

The native database privilege mechanism also checks the ownership of the target
table to be dropped (except for cascaded deletion).
However, SELinux want to apply db_table:{drop} permission, instead of 
db_table:{setattr}.
It is obvious that pg_class_ownercheck() cannot be a caller of the SELinux's
security hook.

It should be:
  void pg_security_drop_table(Oid relid)
  {
  if (!pg_class_ownercheck(relid, GetUserId())
  ackcheck_error(...);

  if (!sepgsqlCheckTableDrop(relid))
  selinux_error(...);
  }

Example 3) ACL_EXECUTE

The ACL_EXECUTE permission is checked on the runtime and setup time.
The meaning of runtime is obvious. It should be checked when user's query tries 
to
execute a function.
For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to 
create
a new conversion. It is available for all the users.
However, SELinux want to apply different permissions for runtime and 
installation time.

On the runtime of the function, it applies db_procedure:{execute}.
On the installation time, it applies db_procedure:{install}.
Because a user defined function is installed as a part of system internals,
it is available for every users. SELinux considers it is fundamentally different
from a user can run a function defined myself.


Because the topic is a bit abstract, it is not clear whether I can introduce
what I want to say correctly, or not.
Please feel free to ask me, if something unclear.


 In addition, it cannot solve the differences in behavior due to the
 security model on which they stand.

 For example, when we create a new table, the native database privilege
 mechanism checks its permission on the schema object which the new
 table blongs to. On the other hand, SELinux requires to check
 db_table:{create} permission on the newly created table itself.
 
 That's fine.  We implement a function in aclchk.c which is essentially
 pg_createTablePriv(schema,newtable).  The logic for doing the check is
 moved out of tablecmds.c (or where ever) and into that function.  We can
 then easily add to that function the SELinux hook.  Is there some issue
 here which I'm not seeing?  If so, can you please clarify?

Re: [HACKERS] SE-PostgreSQL Specifications


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
patches are better than one hard one, as long as they're really
self-contained.

The idea of restructuring the aclcheck mechanism to support sepgsql
is, IMO, brilliant.


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 entry points of security features into a single file,
I really really want an implementation independent layer which focuses
on access controls.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 more using a few examples.
 
 Example 1) ALTER TABLE xxx
 The native database privilege mechanism checks the ownership of the target
 table to control the ALTER TABLE. On the other hand, SE-PgSQL checks the
 db_table:{setattr} permission on the target table to control the ALTER TABLE.
 
 I believe you can notice both of checks have same purpose but differences are
 on the criterions. It is the way to make their decisions in other word.
 
 The pg_xxx_aclcheck() interfaces provide the way to make its access control
 decision. The core PG code calls pg_xxx_aclcheck() to achieve its purpose
 which is to apply access controls on ALTER TABLE.
 
 Accordingly, if we avoid to put SE-PgSQL's security hooks on the tablecmd.c
 directly, what we should do is to inject an abstraction layer between 
 tablecmd.c
 and aclchk.c.
 
 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 function lives in aclchk.c
and is part of its overall API.  This also shows pretty clearly how, if
we needed to add other hooks into the permissions for this operation, we
could do so.  It also shows how we could *first* build:

void pg_security_alter_table(Oid relid)
{
if (!pg_class_ownercheck(relid, GetUserId())
aclcheck_error(...);
}

and make the corresponding changes in tablecmds.c, etc, and do that as a
separate patch.  Once that's done, we can review it, test it, etc, as
just an incremental change to PG.  This should be much easier/faster to
review as a patch as well, and to convince ourselves that we havn't
broken PG's current security (which is an extremely critical thing).
Additionally, when we then come back and add SELinux hooks, they will be
done in an isolated area and be additions to a system which has been
made to support such an extension.


 Example 2) DROP TABLE xxx
 
 The native database privilege mechanism also checks the ownership of the 
 target
 table to be dropped (except for cascaded deletion).
 However, SELinux want to apply db_table:{drop} permission, instead of 
 db_table:{setattr}.
 It is obvious that pg_class_ownercheck() cannot be a caller of the SELinux's
 security hook.
 
 It should be:
   void pg_security_drop_table(Oid relid)
   {
   if (!pg_class_ownercheck(relid, GetUserId())
   ackcheck_error(...);
 
   if (!sepgsqlCheckTableDrop(relid))
   selinux_error(...);
   }

Right.  Similar to above.

 Example 3) ACL_EXECUTE
 
 The ACL_EXECUTE permission is checked on the runtime and setup time.
 The meaning of runtime is obvious. It should be checked when user's query 
 tries to
 execute a function.
 For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to 
 create
 a new conversion. It is available for all the users.
 However, SELinux want to apply different permissions for runtime and 
 installation time.
 
 On the runtime of the function, it applies db_procedure:{execute}.
 On the installation time, it applies db_procedure:{install}.
 Because a user defined function is installed as a part of system internals,
 it is available for every users. SELinux considers it is fundamentally 
 different
 from a user can run a function defined myself.

I'm not sure I follow how this is dramatically different from the other
examples.  We have checks in place in PG already at both runtime of the
function (user has 'execute' privilege) and at creation time (functions
are created in schemas, after all).  If there are checks that PG doesn't
do today but which SELinux wants, those can be added too..  But as we've
discussed, that should be postponed until we get this initial structure
in place to allow PG to be extensible in this way.

 Because the topic is a bit abstract, it is not clear whether I can introduce
 what I want to say correctly, or not.
 Please feel free to ask me, if something unclear.

Yeah, I don't entirely get what you're trying to say here.  Perhaps you
could try and rephrase it?

 It is described at:
   
 http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Common_object_behavior
 
 When we create a new table, SELinux's mode requires all the following
 permissions individually.
  - db_schema:{add_name}, because a table is created under a certain schema
  - db_table:{create} due to the common object behavior
  - db_column:{create} for each columns, due to the common object behavior
 
 Note that the newly created object does not exist when SE-PgSQL checks its
 db_xxx:{create} permission.
 Accordingly, it computes a default security

Re: [HACKERS] SE-PostgreSQL Specifications

* 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 entry points of security features into a single file,
 I really really want an implementation independent layer which focuses
 on access controls.

I think that's what I'm advocating..  If, by that, you mean we should do
it in a separate file from aclchk.c, I'm not against that.  It would
likely mean moving some things *from* aclchk.c into it, and then just
using aclchk.c for helpers to support the PG permissions.  I'm not
sure which way would be easier to handle in terms of patch review,
etc..

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

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 function lives in aclchk.c
 and is part of its overall API.  This also shows pretty clearly how, if
 we needed to add other hooks into the permissions for this operation, we
 could do so.  It also shows how we could *first* build:
 
 void pg_security_alter_table(Oid relid)
 {
   if (!pg_class_ownercheck(relid, GetUserId())
   aclcheck_error(...);
 }
 
 and make the corresponding changes in tablecmds.c, etc, and do that as a
 separate patch.  Once that's done, we can review it, test it, etc, as
 just an incremental change to PG.  This should be much easier/faster to
 review as a patch as well, and to convince ourselves that we havn't
 broken PG's current security (which is an extremely critical thing).
 Additionally, when we then come back and add SELinux hooks, they will be
 done in an isolated area and be additions to a system which has been
 made to support such an extension.

Basically, I can agree this approach.
However, it is necessary to consider the idea deeply whether it is really
possible to implement the SELinux's model correctly, or not.

For example, ExecCheckRTEPerms() checks permissions on DML statement.
It allows users to access required table and columns, if he has appropriate
permissions on the table OR all the columns in use.
But SELinux requires the client needs to be allowed on the table AND all
the columns in use.

Please note that all we need to focus on is not pg_xxx_aclcheck() routines
in other words.

 Example 3) ACL_EXECUTE

 The ACL_EXECUTE permission is checked on the runtime and setup time.
 The meaning of runtime is obvious. It should be checked when user's query 
 tries to
 execute a function.
 For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to 
 create
 a new conversion. It is available for all the users.
 However, SELinux want to apply different permissions for runtime and 
 installation time.

 On the runtime of the function, it applies db_procedure:{execute}.
 On the installation time, it applies db_procedure:{install}.
 Because a user defined function is installed as a part of system internals,
 it is available for every users. SELinux considers it is fundamentally 
 different
 from a user can run a function defined myself.
 
 I'm not sure I follow how this is dramatically different from the other
 examples.  We have checks in place in PG already at both runtime of the
 function (user has 'execute' privilege) and at creation time (functions
 are created in schemas, after all).  If there are checks that PG doesn't
 do today but which SELinux wants, those can be added too..  But as we've
 discussed, that should be postponed until we get this initial structure
 in place to allow PG to be extensible in this way.

What I would like to say was how does the user defined function is used.
(However, it is the issue corresponding to the security model, not where
we should put the security hooks.)

For example, type input/output handlers are invoked without permission
checks on runtime. We never see an error due to the lack of permission
to execute textout() function. The native privilege model assumes type
input/output handlers can be trusted, because only superuser can set up
own types. (In fact, DefineType() checks superuser() at the head.)

So, rest of the routine does not check anything based on the assumption
of the superuser. See the #ifdef NOT_USER ... #endif block in DefineType().

It looks like the native database privilege mechanism does not check such
a permission, however, it implicitly assume ACL_EXECUTE permission is
always allowed for superuser.

Here, it seems to me ACL_EXECUTE has two different meanings here.
The one is obvious. It is a privilege a certain user to execute a certain
function in his query. The other is a privilege a certain user allows
everyone to execute a certain a part of the system internal stuff
(such as type input/output handlers).

The example is not dramatically different from the others, indeed.
But, this code implicitly assume the database superuser can do anyhting,
so the necessary checks are omitted from the code (because they always
return allowed).

I think it is also necessary to follow these implicit permission check.

 As I mentioned above, if (enhanced) PG's access control mechanism can
 contain all the needed SELinux hooks, I can agree to put security hooks
 inside the PG's security.
 However, note that I have a legitimate reason that we cannot put SELinux
 hooks inside the *current* pg_xxx_aclcheck() routines, to implement the
 security model of SELinux correctly.
 
 Sure, and that's fine.  I think the problem that you keep running into
 is this:  You don't want to touch the PG code too much for

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-30 Thread KaiGai Kohei

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
 things outside and because SE-PG isn't self contained I really think you
 need to link to them.
 This is not supposed to be user documentation.  It's supposed to be a
 feature specification that an implementation can be validated against.
 Hmm...
 What kind of descriptions are necessary for a feature specifications?
 
 It describes what the feature does and why.
 
 Currently, I guess the specification describes when/where the security
 hook should be invoked, what permission should be checked and what result
 should be returned for each security hooks.

 Is it correct? Or, do you expect any other stuffs?
 
 That is a pretty good start, but it's drifting into implementation details.
 
 Apart from that, user documentation is also necessary.
 If the specification should be described from completely different
 viewpoint, I'll provide it.
 
 Yes, user documentation will eventually also be necessary, and the original 
 specification may be usable as a source for that.  I'm just reacting to those 
 who commented whether or not references should be added and what reference 
 style the documentation uses.  We're not there yet.  The purpose of this 
 document is to explain what the feature does, not to teach users to use the 
 feature.

For a couple of days, I have paid my efforts to provide the design
specifications more than user documentations.
(But a few sections are under construction.)

http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

Some of sections are copied from the SEPostgreSQL_Draft and edited,
rest of sections are also revised to represent its feature and behavior
more correctly.

At the current moment, I can agree it is too early to discuss the style
for user documentation. So, I would like to freeze the efforts to the
user documentation for a while, and begin to discuss the design specification
which focuses on developers.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 mandatory access
  controls.
- Revised whole of the composition in the Brief overview section.
- Put an example of security policy rule.
- SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
  avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:
 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 them in the security policy. Because the security
 policy is common for operating system, databases, x-window and others,
 any managed database objects needs its security context.

 Anyway, I need to introduce them in the security model section.

 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 will be somewhat of a break from normal PG documentation because
 so far everything has been self contained, it's chosen its own
 interpretation of the SQL standard and it needs to document that.  SE-PG
 will be interacting with much more code from outside and showing which
 parts of these are PG specific vs. which parts are common to all SELinux
 seems important.

 If you try to document *everything* you're going to be writing for years
 and give the impression that everything is implemented in SE-PG.  A
 dividing line needs to be drawn between what is PG specific and what is
 SELinux (why not SEL?).
 
 It also seems to me reasonable suggestion.
 
 However, a reasonable amount (which should be adjusted under discussions)
 of description should be self-contained.
 For example, security context is a formatted short string is not enough
 to understand why it is necessary and what is the purpose.
 
 As Robert suggested, a few example and definition of technical terms
 will help database folks to understand what it is, even if self-contained
 explanation is not comprehensive from viewpoint of security folks.
 
 Thanks,


-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-28 Thread Peter Eisentraut

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 not supposed to be user documentation.  It's supposed to be a feature 
specification that an implementation can be validated against.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-28 Thread Greg Williamson


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, or not in the initial 
release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect 
it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure 
if postgres DB
hackers would care if is it is not to be included. How much do these compromise 
the design,
and if so, are there specific plans for implementing them ?

b) something which explains the differences between SELinux and SEPostgreSQL on 
the one
hand (for SE fans). You've done a good job of outlining the differences and 
similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB 
experience
can see the differences.

I am all in favor of external links if you can find good explanation of 
concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation 
details to another page --
basically everything from Installation on, with the exception of the 
overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).

I'll send mail when I have 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 kai...@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

- 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 mandatory access
  controls.
- Revised whole of the composition in the Brief overview section.
- Put an example of security policy rule.
- SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
  avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:
 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 them in the security policy. Because the security
 policy is common for operating system, databases, x-window and others,
 any managed database objects needs its security context.

 Anyway, I need to introduce them in the security model section.

 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 will be somewhat of a break from normal PG documentation because
 so far everything has been self contained, it's chosen its own
 interpretation of the SQL standard and it needs to document that.  SE-PG
 will be interacting with much more code from outside and showing which
 parts of these are PG specific vs. which parts are common to all SELinux
 seems important.

 If you try to document *everything* you're going to be writing for years
 and give the impression that everything is implemented in SE-PG.  A
 dividing line needs to be drawn between what is PG specific and what is
 SELinux (why not SEL?).
 
 It also seems to me reasonable suggestion.
 
 However, a reasonable amount (which should be adjusted under discussions)
 of description should be self-contained.
 For example, security context is a formatted short string is not enough
 to understand why it is necessary and what is the purpose.
 
 As Robert suggested, a few example and definition of technical terms
 will help database folks to understand what it is, even if self-contained
 explanation is not comprehensive from viewpoint of security folks.
 
 Thanks,


-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



  

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-28 Thread Sam Mason

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 also.
 
  OK, so there is some other trusted entity that has unfettered access to
  both databases and its job is to manage these requirements.
 
 No, that's not what this implies.

 What this implies is along the following lines...
 
  If a user at the more secret level updates some data that had been
  classified at a lower level, then that data gets reclassified at the
  higher level.

I still think it does; but maybe there are other ways of arranging
things.  The problem seems to be that if each user only has write access
to their own level then the is no bound as to how far the two databases
will get out of sync with each other.  Some way has to be made of
declassifying data and so bound the amount of difference between the
two.  This declassification can not done by a normal user as they can
only write in their own level.  This trusted entity has to exist to
punch a hole in the security to do something that wouldn't otherwise be
allowed to happen, information normally only flows up the hierarchy.

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-28 Thread Greg Williamson


[wretched top-posting -- begs forgiveness!]

KaiGai --

I have edited the first three sections (up to but not including 
Architecture), mostly cleaning up language but I did run into a few places 
where I am not sure if I got the proper meaning -- I flagged those in square 
brackets (e.g.[...]) and with your name. Feel free to change them, accept them, 
or confer back with me about them.

In particular, in the Security policy section you had:
 

 TE rules use the third field in the security context. It is called type or 
 domain (for processes).
 allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};

I thought that colons were used to split these fields, so the above line would 
have only 2 ? Perhaps after the httpd_t ?


I'd like to get some feedback from you (and any other readers) before I do more 
... I need to go deal an invasion of the kitchen -- it is garbage collection 
morning (early) and I just had a pretty young skunk and two raccoon kits in 
rapid order and I have to clean up and secure the premises.

Regards!

G



- Original Message 
From: Greg Williamson gwilliamso...@yahoo.com
To: KaiGai Kohei kai...@ak.jp.nec.com; KaiGai Kohei kai...@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 in the initial 
version -- do you
mean in the first Beta release of SE-PostgreSQL, or not in the initial 
release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect 
it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure 
if postgres DB
hackers would care if is it is not to be included. How much do these compromise 
the design,
and if so, are there specific plans for implementing them ?

b) something which explains the differences between SELinux and SEPostgreSQL on 
the one
hand (for SE fans). You've done a good job of outlining the differences and 
similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB 
experience
can see the differences.

I am all in favor of external links if you can find good explanation of 
concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation 
details to another page --
basically everything from Installation on, with the exception of the 
overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).

I'll send mail when I have 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 kai...@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

- 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 mandatory access
  controls.
- Revised whole of the composition in the Brief overview section.
- Put an example of security policy rule.
- SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
  avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:
 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 them in the security policy. Because the security
 policy is common for operating system, databases, x-window and others,
 any managed database objects needs its security context.

 Anyway, I need to introduce them in the security model section.

 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 will be somewhat of a break from normal PG documentation because
 so far everything has been self contained, it's chosen its own
 interpretation of the SQL standard and it needs to document that.  SE-PG
 will be interacting with much more code from outside and showing which
 parts of these are PG specific vs. which parts are common to all SELinux
 seems important.

 If you try to document *everything* you're going to be writing for years
 and give the impression that everything is implemented in SE-PG.  A
 dividing line needs

Re: [HACKERS] SE-PostgreSQL Specifications


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 link to them.


This is not supposed to be user documentation.  It's supposed to be a feature 
specification that an implementation can be validated against.




Hmm...
What kind of descriptions are necessary for a feature specifications?

Currently, I guess the specification describes when/where the security
hook should be invoked, what permission should be checked and what result
should be returned for each security hooks.

Is it correct? Or, do you expect any other stuffs?

Apart from that, user documentation is also necessary.
If the specification should be described from completely different viewpoint,
I'll provide it.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications


Greg Williamson wrote:

[wretched top-posting -- begs forgiveness!]

KaiGai --

I have edited the first three sections (up to but not including Architecture),

 mostly cleaning up language but I did run into a few places where I am not
 sure if I got the proper meaning -- I flagged those in square brackets 
(e.g.[...])

 and with your name. Feel free to change them, accept them, or confer back 
with me
 about them.

Thanks for your efforts so much.
I'll confirm it tomorrow (in JST).


In particular, in the Security policy section you had:


TE rules use the third field in the security context. It is called type or 
domain (for processes).
allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};


I thought that colons were used to split these fields, so the above line would

 have only 2 ? Perhaps after the httpd_t ?

It says the third field in the security policy, not a rule in the security 
policy. Sorry, it might be introduced more carefully.


In the default security policy, web server process performs labeled as
system_u:system_r:httpd_t:s0.
   ^^^
This rule is checked when web server process tries to access a table labeled
as system_u:object_r:sepgsql_ro_table_t:s0, for example.
  ^^
The TE rule is defined between the pair of third field (which is called type
or domain) of security contexts.

# BTW, basically, the second field is used for RBAC rules, the fourth field
# is used for MLS rules. The first field is used to record who create the
# object.

Thanks,




I'd like to get some feedback from you (and any other readers) before I do more 
... I need to go deal an invasion of the kitchen -- it is garbage collection 
morning (early) and I just had a pretty young skunk and two raccoon kits in 
rapid order and I have to clean up and secure the premises.

Regards!

G



- Original Message 
From: Greg Williamson gwilliamso...@yahoo.com
To: KaiGai Kohei kai...@ak.jp.nec.com; KaiGai Kohei kai...@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 in the initial 
version -- do you
mean in the first Beta release of SE-PostgreSQL, or not in the initial 
release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect 
it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure 
if postgres DB
hackers would care if is it is not to be included. How much do these compromise 
the design,
and if so, are there specific plans for implementing them ?

b) something which explains the differences between SELinux and SEPostgreSQL on 
the one
hand (for SE fans). You've done a good job of outlining the differences and 
similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB 
experience
can see the differences.

I am all in favor of external links if you can find good explanation of 
concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation 
details to another page --
basically everything from Installation on, with the exception of the 
overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).

I'll send mail when I have 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 kai...@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

- 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 mandatory access
  controls.
- Revised whole of the composition in the Brief overview section.
- Put an example of security policy rule.
- SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
  avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:

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 them in the security policy. Because the security
policy is common for operating system, databases, x-window and others,
any managed database objects needs its security context.

Anyway, I need to introduce them

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-28 Thread Peter Eisentraut

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 because SE-PG isn't self contained I really think you
  need to link to them.
 
  This is not supposed to be user documentation.  It's supposed to be a
  feature specification that an implementation can be validated against.

 Hmm...
 What kind of descriptions are necessary for a feature specifications?

It describes what the feature does and why.

 Currently, I guess the specification describes when/where the security
 hook should be invoked, what permission should be checked and what result
 should be returned for each security hooks.

 Is it correct? Or, do you expect any other stuffs?

That is a pretty good start, but it's drifting into implementation details.

 Apart from that, user documentation is also necessary.
 If the specification should be described from completely different
 viewpoint, I'll provide it.

Yes, user documentation will eventually also be necessary, and the original 
specification may be usable as a source for that.  I'm just reacting to those 
who commented whether or not references should be added and what reference 
style the documentation uses.  We're not there yet.  The purpose of this 
document is to explain what the feature does, not to teach users to use the 
feature.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

Greg Williamson wrote:
 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, or not in the initial 
 release(s) for commitfests ?
 If it is not supported why mention it ? If experienced users of SELinux 
 expect it, they might look for
 an explanation as to why it is missing and when it might appear. I'm not sure 
 if postgres DB
 hackers would care if is it is not to be included. How much do these 
 compromise the design,
 and if so, are there specific plans for implementing them ?

The This is not supported ... comment means this feature is not included 
within
the initial patch submitted to the next commit fest, so the corresponding 
section
is not also included within the documentation patch at that time.
However, I expect all the features and corresponding user documents should be
included within the stable v8.5 release. So, I also described these sections
with notations.

 b) something which explains the differences between SELinux and SEPostgreSQL 
 on the one
 hand (for SE fans). You've done a good job of outlining the differences and 
 similarities with the
 more standard ACL methods and that needs to be kept prominent so people with 
 DB experience
 can see the differences.
 
 I am all in favor of external links if you can find good explanation of 
 concepts elsewhere. This is a
 very high level outline and so I'd be tempted to move all implementation 
 details to another page --
 basically everything from Installation on, with the exception of the 
 overview of the dump issues,
 is (to my eye) a detail that doesn't need exposing (yet).

At first, what should be included within the PostgreSQL official documentation?

I don't think here is any opposition to include
 - Steps to installations
 - Enhancement in SQL statement
 - External links something like:
   It provides mandatory access controls. See the http://. for details.

Needs to be discussed
 - Securtiy model overview, such as security context, security policy and so on.
 - Feature overview, such as example of access controls.
 - References to object classes and permissions.
  (Basically, it is not necessary for end users.)

If we prepare a comprehensive external documentation, one idea is to revise
the series of wikipages at:

  http://wiki.postgresql.org/wiki/SEPostgreSQL

Thanks,

 I'll send mail when I have 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 kai...@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
 
 - 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 mandatory access
   controls.
 - Revised whole of the composition in the Brief overview section.
 - Put an example of security policy rule.
 - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
   avoid meaningless confusion.
 
 I believe it become better than previous revision.
 
 Thanks,
 
 KaiGai Kohei wrote:
 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 them in the security policy. Because the security
 policy is common for operating system, databases, x-window and others,
 any managed database objects needs its security context.

 Anyway, I need to introduce them in the security model section.
 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 will be somewhat of a break from normal PG documentation because
 so far everything has been self contained, it's chosen its own
 interpretation of the SQL standard and it needs to document that.  SE-PG
 will be interacting with much more code from outside and showing which
 parts of these are PG specific vs. which parts are common to all SELinux
 seems important.

 If you try to document *everything* you're going to be writing for years
 and give the impression that everything is implemented in SE-PG.  A
 dividing line needs to be drawn between what is PG specific and what is
 SELinux (why not SEL?).
 It also seems to me reasonable suggestion.

 However, a reasonable amount (which

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-27 Thread Chris Browne

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 access to
 both databases and its job is to manage these requirements.

No, that's not what this implies.

What this implies is along the following lines...

 If a user at the more secret level updates some data that had been
 classified at a lower level, then that data gets reclassified at the
 higher level.

If this sort of outcome is problematic, then that suggests that maybe
the attempt at sharing wasn't such a good idea.

 Thus, it is necessary a capability to store and manage data objects
 with different security labeles in a single database instance here.
 (If we don't want to use commercial solutions instead.)

 SE-PG is about doing the above in one database and allowing more
 rigorous checks to be done?

I don't think the issue is so much about more rigorous; it's about
having mandatory labelling that is handled consistently.
-- 
(reverse (concatenate 'string ofni.sesabatadxunil @ enworbbc))
http://linuxdatabases.info/info/rdbms.html
The people's revolutionary committee has  decided that the name e is
retrogressive, unmulticious   and reactionary, and  has  been flushed.
Please update your abbrevs.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-27 Thread KaiGai Kohei

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 that has unfettered access to
 both databases and its job is to manage these requirements.
 
 No, that's not what this implies.
 
 What this implies is along the following lines...
 
  If a user at the more secret level updates some data that had been
  classified at a lower level, then that data gets reclassified at the
  higher level.
 
 If this sort of outcome is problematic, then that suggests that maybe
 the attempt at sharing wasn't such a good idea.

Theoretically, such kind of updates are not visible for lower security
level users. In other word, a tuple can have multiple version depending
on the security level, it might be called as polyinstantication.

However, SE-PostgreSQL and SELinux which provides the security policy
adopt more simple solution. Its security policy prevent any writer
operations on the data object which dose not have identical security
level.

In other word, if the database client has classified level.
He cannot write anything on both of unclassified and secret,
but it is possible for classified data object.

 Thus, it is necessary a capability to store and manage data objects
 with different security labeles in a single database instance here.
 (If we don't want to use commercial solutions instead.)
 SE-PG is about doing the above in one database and allowing more
 rigorous checks to be done?
 
 I don't think the issue is so much about more rigorous; it's about
 having mandatory labelling that is handled consistently.

Yes, it shall perform correctly as far as SE-PostgreSQL manages security
context of database objects and makes its access control decision without
any exceptions.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-27 Thread Greg Williamson


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 place (perhaps paragraph 
by paragraph) ?

Thanks, and apologies for the delay !

Greg W.

ps most of what I have is orthogonal to the lively discussions since Friday.



  

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-27 Thread KaiGai Kohei

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 wiki and I could do
 them in place (perhaps paragraph by paragraph) ?

Thanks for your helps.

I think it is good idea to edit wikipage because we can easily
check and understand its update history.

IIRC, you can create a wiki account from:
  http://www.postgresql.org/community/signup

BTW, I changed the structure of chapters/sections in former of
the documentation to reduce usage of undefined terminology and
so on. Sorry, if it overlapped with your efforts.
And, please note that the 3.2 Access controls section is still
on work.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread Sam Mason

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 subset of all of
 the objects.  Isn't SE-PG just allowing you to do this within a single
 PG database?
 
 Partly.  There's also a concept called read down, which is
 important.  It allows you to have, say, secret and classified data in
 the same database, and let the secret users see both types but the
 classified users see only the classified stuff, not the secret stuff.
 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 both sets of data.  But if you have higher and lower
 classifications of data it's pretty handy (AIUI) to be able to let the
 higher-secrecy users read the lower-secrecy data - if you used
 separate databases to simulate read-down, you'd have to replicate data
 between them, and also have some manual mechanism for tracking which
 level of secrecy applied to which to which data.
 
 It seems a correct description.
 
 In addition, we also need to prevent that higher-secrecy users writes
 anything to the lower-secrect objects to prevent information leaks.

OK, so to bulk out this physical analogy we'd have two physical servers
one that stores higher-secrecy stuff and one for lower-secrecy
stuff.  Users with higher clearance are able to read/write the higher
secrecy database but only read the lower secrecy database.  Users with
lower clearance can only read/write the lower secrecy database, ideally
they aren't even aware of the existence of the higher secrecy one.

 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 access to
both databases and its job is to manage these requirements.

 Thus, it is necessary a capability to store and manage data objects
 with different security labeles in a single database instance here.
 (If we don't want to use commercial solutions instead.)

SE-PG is about doing the above in one database and allowing more
rigorous checks to be done?

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread Sam Mason

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 security policy. Because the security
 policy is common for operating system, databases, x-window and others,
 any managed database objects needs its security context.
 
 Anyway, I need to introduce them in the security model section.

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 will be somewhat of a break from normal PG documentation because
so far everything has been self contained, it's chosen its own
interpretation of the SQL standard and it needs to document that.  SE-PG
will be interacting with much more code from outside and showing which
parts of these are PG specific vs. which parts are common to all SELinux
seems important.

If you try to document *everything* you're going to be writing for years
and give the impression that everything is implemented in SE-PG.  A
dividing line needs to be drawn between what is PG specific and what is
SELinux (why not SEL?).

 For the security policy, I introduce it at the security model section:
 
 | 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 privilege system, ACL stored in database objects itself
 | holds a list of allowed actions to certain database roles, and it is
 | applied on the user's request.
 | SELinux also holds massive sets of allowed actions between a certain
 | subject and a certain object, we call them security policy.
 
 Is it obscure?

I find that somewhat opaque as well! sorry

 At this point, the SELinux user's guide in Fedora is the most comprehensive
 documentation. It is described from the viewpoint of SELinux users, not
 experts or developers.
 
   http://docs.fedoraproject.org/selinux-user-guide/

OK, thanks!

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread Andrew Dunstan




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 all the databse
objects and can make backups, but any other process cannot touch the
backup files. It means that DBA can launch a backup tool and it creates
a black-boxed file, then he cal also lauch a restore tool to restore
the black-boxed backup, but he cannot see the contents of the backup.
(It might be a similar idea of sudo mechanism.)




Really? How you enforce this black box rule for a backup made across the 
network? From the server's POV there is no such thing as a backup. All 
it sees is a set of SQL statements all of which it might see in some 
other context.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread KaiGai Kohei


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 them in the security policy. Because the security
policy is common for operating system, databases, x-window and others,
any managed database objects needs its security context.

Anyway, I need to introduce them in the security model section.


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 will be somewhat of a break from normal PG documentation because
so far everything has been self contained, it's chosen its own
interpretation of the SQL standard and it needs to document that.  SE-PG
will be interacting with much more code from outside and showing which
parts of these are PG specific vs. which parts are common to all SELinux
seems important.

If you try to document *everything* you're going to be writing for years
and give the impression that everything is implemented in SE-PG.  A
dividing line needs to be drawn between what is PG specific and what is
SELinux (why not SEL?).


It also seems to me reasonable suggestion.

However, a reasonable amount (which should be adjusted under discussions)
of description should be self-contained.
For example, security context is a formatted short string is not enough
to understand why it is necessary and what is the purpose.

As Robert suggested, a few example and definition of technical terms
will help database folks to understand what it is, even if self-contained
explanation is not comprehensive from viewpoint of security folks.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread KaiGai Kohei


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 example, it can access all the databse
objects and can make backups, but any other process cannot touch the
backup files. It means that DBA can launch a backup tool and it creates
a black-boxed file, then he cal also lauch a restore tool to restore
the black-boxed backup, but he cannot see the contents of the backup.
(It might be a similar idea of sudo mechanism.)




Really? How you enforce this black box rule for a backup made across the 
network? From the server's POV there is no such thing as a backup. All 
it sees is a set of SQL statements all of which it might see in some 
other context.


The recent SELinux provide a feature to exchange the security context of
peer process over the network connection.
It allows to control a certain process to send/receive packets to/from
only a certain process, even if they communicate using remote connection.

This feature is named Labeled IPsec. The key exchange daemon (racoon)
was enhanced to exchange the security context of peer processes also,
prior to the actual communications.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread Andrew Dunstan




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 backup and restore tools. For example, it can access all the 
databse

objects and can make backups, but any other process cannot touch the
backup files. It means that DBA can launch a backup tool and it creates
a black-boxed file, then he cal also lauch a restore tool to restore
the black-boxed backup, but he cannot see the contents of the backup.
(It might be a similar idea of sudo mechanism.)




Really? How you enforce this black box rule for a backup made across 
the network? From the server's POV there is no such thing as a 
backup. All it sees is a set of SQL statements all of which it might 
see in some other context.


The recent SELinux provide a feature to exchange the security context of
peer process over the network connection.
It allows to control a certain process to send/receive packets to/from
only a certain process, even if they communicate using remote connection.

This feature is named Labeled IPsec. The key exchange daemon (racoon)
was enhanced to exchange the security context of peer processes also,
prior to the actual communications.




Interesting, I can see this having some use in quite a number of areas. 
Of course, in the end, it still comes down to this issue, which is as 
old as Plato: Quis custodiet ipsos custodes? (see 
http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F )


cheers

andrew

*/

/*

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread Ron Mayer

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 both sets of data.  But if you have higher and lower
 classifications of data it's pretty handy (AIUI) to be able to let the
 higher-secrecy users read the lower-secrecy data 

Nice example.

Is this system being designed flexibly enough so that one user may
have access to the higher-secrecy data of the Iraq dataset but only
the lower-secrecy Afghanistan dataset; while a different user may have
access to the higher-secrecy Afghanistan data but only the lower-secrecy
Iraq data?

I imagine it's not uncommon for organizations to want to have total
access to their data, but expose more limited access to other
organizations they communicate with.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-26 Thread KaiGai Kohei


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 process 
privilege
for backup and restore tools. For example, it can access all the 
databse

objects and can make backups, but any other process cannot touch the
backup files. It means that DBA can launch a backup tool and it creates
a black-boxed file, then he cal also lauch a restore tool to restore
the black-boxed backup, but he cannot see the contents of the backup.
(It might be a similar idea of sudo mechanism.)




Really? How you enforce this black box rule for a backup made across 
the network? From the server's POV there is no such thing as a 
backup. All it sees is a set of SQL statements all of which it might 
see in some other context.


The recent SELinux provide a feature to exchange the security context of
peer process over the network connection.
It allows to control a certain process to send/receive packets to/from
only a certain process, even if they communicate using remote connection.

This feature is named Labeled IPsec. The key exchange daemon (racoon)
was enhanced to exchange the security context of peer processes also,
prior to the actual communications.




Interesting, I can see this having some use in quite a number of areas. 
Of course, in the end, it still comes down to this issue, which is as 
old as Plato: Quis custodiet ipsos custodes? (see 
http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F )


The administrator needs to set up and manage both of the hosts to
keep consistent security policy, but it is not a technical issue.

We have security issues broader than what technical feature can solve,
and the technical security feature is a piece of them.
(Needless to say, it is an important piece.)

For example, any kind of access controls are ineffective to phisical
attacks, so we need to place the server in data centers with physical
controls on entering or leaving a room.
Referring any ISO/IEC15408 certifications, they defines a certain
environment in which the certified products to be used.
It means the certification is valid on the required environments.

The technical security feature is an important piece, but not all.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 () RETURNS SETOF RECORD
 LANGUAGE 'sql'
 SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
   AS 'SELECT * FROM customer';
 
 In this case, confined users cannot create a function labeled as
 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
 controlled by db_procedure:{create} permission.

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.

One thing I know I don't understand is what the security labels actually
mean; I've had a couple of searches through your pages now and can't see
anything described nor pointers to external documentation.

 Confined user can create a function with user_sepgsql_proc_exec_t
 (which is the default one for confined users), but it is not a trusted
 procedure, so the SELECT * FROM customer is executed with confined
 user's privileges as is, then it will be failed due to the lack of
 permission on the customer.credit.

So an unconfined user (whatever that means??) is basically working
with DACs then?

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications


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 show_customers () RETURNS SETOF RECORD
   LANGUAGE 'sql'
   SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
 AS 'SELECT * FROM customer';

In this case, confined users cannot create a function labeled as
'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
controlled by db_procedure:{create} permission.


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.

One thing I know I don't understand is what the security labels actually
mean; I've had a couple of searches through your pages now and can't see
anything described nor pointers to external documentation.


I assume the wikipage (SEPostgreSQL_Draft) is a draft for the PostgreSQL
official documentation. However, the list of security labels originates
from the default security policy in SELinux.
So, I think an external link will be preferable for the references.

TODO: I'll make the list of security labels we can assign on.


Confined user can create a function with user_sepgsql_proc_exec_t
(which is the default one for confined users), but it is not a trusted
procedure, so the SELECT * FROM customer is executed with confined
user's privileges as is, then it will be failed due to the lack of
permission on the customer.credit.


So an unconfined user (whatever that means??) is basically working
with DACs then?


Sorry for using the undefined terminology.

The default security policy provides several security contexts that we
can assign on user's shell process, such as user_t, staff_t and unconfined_t.
(Please note that the security context of processes means its privileges.)

SELinux checks privileges of processes without any exceptions.
However, the default security policy allows anything on unconfined_t label.
It means unconfined users are allowed anything according to the policy.
(BTW, we can unplug the unconfined label using modular policy stuff.)

On the other hand, rest of security context (user_t, staff_t or httpd_t for
web servers) are confined, because the security policy does not allow
such widespread permissions.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-25 Thread Tom Lane

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 superusers.  Or do you want the correctness
of your backups to depend on whether your SELinux policy is correct?
The first time somebody loses critical data because SELinux suppressed
it from their pg_dump output, they're going to be on the warpath.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-25 Thread A.M.



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
terminology thing though.


There had better still be superusers.  Or do you want the correctness
of your backups to depend on whether your SELinux policy is correct?
The first time somebody loses critical data because SELinux suppressed
it from their pg_dump output, they're going to be on the warpath.


This behavior is no different than when taking/using an SE-enabled  
filesystem backup. And woe to the admin who doesn't test his  
backups- caveat emptor.


Still, it would be nice if pg_dump warned or stopped if the backup it  
created was completely useless (missing data dependencies), no?


Cheers,
M

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 anyone and none of it
is explained in a way I can understand.  External links are fine at the
moment (I think) but descriptions will need to exist.

For example you currently define a security context as a formatted
short string---how does that tell me why I would want one or what it
does!  As an example, PG currently has the following to describe what a
role is:

  http://www.postgresql.org/docs/current/static/database-roles.html

I'd expect a similar definition for each of the major terms in SE-PG;
at the moment these seem to be security label, security context,
security policy and others?  What do others think?

Hope that helps explain my confusion!  If you point me at some docs I'll
be happy to write/edit things to make them more relevant to PG.

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 power they currently do.  Organizations may
well not trust specific parts of their database to certain types of
backups, SE-PG should allow this to be controlled somewhat.

 The first time somebody loses critical data because SELinux suppressed
 it from their pg_dump output, they're going to be on the warpath.

That should be solved by different methods; as A.M said pg_dump can
complain if it doesn't see everything it expected to (which should
handle the naive user case) and backdoors can be put in the scheme
that will (by default?) initially allow a backup subject unfettered
read-only access to each object.  I'm expecting that this access can be
revoked as needed from sensitive tables.

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-25 Thread Robert Haas

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 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 accurate.  A more
accurate statement would be that it's possible to create a system in
which there is no unconfined role.

 Organizations may
 well not trust specific parts of their database to certain types of
 backups, SE-PG should allow this to be controlled somewhat.

I imagine it would be possible to run pg_dump on a database where you
couldn't see all of the objects, and get a dump of just those, but
that's only tangentially related to whether such things as superusers
exist.  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.  And while I believe
SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
might want to think carefully before you decide to do so, and the
system certainly shouldn't (and can't) force you to set it up that
way.

 The first time somebody loses critical data because SELinux suppressed
 it from their pg_dump output, they're going to be on the warpath.

 That should be solved by different methods; as A.M said pg_dump can
 complain if it doesn't see everything it expected to (which should
 handle the naive user case) and backdoors can be put in the scheme
 that will (by default?) initially allow a backup subject unfettered
 read-only access to each object.  I'm expecting that this access can be
 revoked as needed from sensitive tables.

If pg_dump can tell that there is information missing, the system
hasn't done a very good job of hiding its existence, which is surely
the whole point here.  Even if SE-PostgreSQL isn't explicitly worried
about eliminating covert channels, it seems like a terrible idea to
design a database backup tool that operates by exploiting ones we
haven't chosen to eliminate.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 really accurate.  A more
 accurate statement would be that it's possible to create a system in
 which there is no unconfined role.

Yes, that sounds more precise!

I'm still unsure of terminology; what's a unconfined role?  I guess
the layman's description is similar to a superuser, but I'm sure
there's a more refined definition somewhere.  Hum, I've just found
Fedora's guide, is the following considered a reasonable picture:

  
http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html

  Organizations may
  well not trust specific parts of their database to certain types of
  backups, SE-PG should allow this to be controlled somewhat.
 
 I imagine it would be possible to run pg_dump on a database where you
 couldn't see all of the objects, and get a dump of just those, but
 that's only tangentially related to whether such things as superusers
 exist.

I'm not sure what point you're trying to make; in my understanding
superusers can see and do anything--hence they can make a backup.

 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's obvious that when you perform a
backup of one of these databases you're only seeing a subset of all of
the objects.  Isn't SE-PG just allowing you to do this within a single
PG database?

 And while I believe
 SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
 might want to think carefully before you decide to do so, and the
 system certainly shouldn't (and can't) force you to set it up that
 way.

I agree that this would seem to make the resulting system easier to
manage, however I can also imagine scenarios where the converse would
be true.  This is a fuzzy engineering decision of the sort that I don't
like making without a use case---and it would be nice to have several
here.

  pg_dump can complain if it doesn't see everything it expected to
 
 If pg_dump can tell that there is information missing, the system
 hasn't done a very good job of hiding its existence, which is surely
 the whole point here.

Hum, good point--scratch that idea then!

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications


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 understandable/usable by anyone and none of it
is explained in a way I can understand.  External links are fine at the
moment (I think) but descriptions will need to exist.

For example you currently define a security context as a formatted
short string---how does that tell me why I would want one or what it
does!  As an example, PG currently has the following to describe what a
role is:

  http://www.postgresql.org/docs/current/static/database-roles.html


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 security policy. Because the security
policy is common for operating system, databases, x-window and others,
any managed database objects needs its security context.

Anyway, I need to introduce them in the security model section.


I'd expect a similar definition for each of the major terms in SE-PG;
at the moment these seem to be security label, security context,
security policy and others?  What do others think?


The security label is an identical one with security context.
Due to the historical reason, I uses a term of SECURITY_LABEL for
interfaces, but it might be more easy understandable to use
SECURITY_CONTEXT instead.

For the security policy, I introduce it at the security model section:

| 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 privilege system, ACL stored in database objects itself
| holds a list of allowed actions to certain database roles, and it is
| applied on the user's request.
| SELinux also holds massive sets of allowed actions between a certain
| subject and a certain object, we call them security policy.

Is it obscure?

In addition, I also think it needs to define some other terms explicitly.
For example, what the term of labeled means.


Hope that helps explain my confusion!  If you point me at some docs I'll
be happy to write/edit things to make them more relevant to PG.


At this point, the SELinux user's guide in Fedora is the most comprehensive
documentation. It is described from the viewpoint of SELinux users, not
experts or developers.

  http://docs.fedoraproject.org/selinux-user-guide/

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-25 Thread Robert Haas

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 the database privilege system, ACL stored in database objects itself
 | holds a list of allowed actions to certain database roles, and it is
 | applied on the user's request.
 | SELinux also holds massive sets of allowed actions between a certain
 | subject and a certain object, we call them security policy.

 Is it obscure?

It's obscure to me.  :-)

I think you need to define security policy more precisely and give at
least one or two examples of security policy entries.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications


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 user's requests.
| At the database privilege system, ACL stored in database objects itself
| holds a list of allowed actions to certain database roles, and it is
| applied on the user's request.
| SELinux also holds massive sets of allowed actions between a certain
| subject and a certain object, we call them security policy.

Is it obscure?


It's obscure to me.  :-)

I think you need to define security policy more precisely and give at
least one or two examples of security policy entries.


OK, I'll try to define it more precisely and introduce a few examples
in the documents.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-25 Thread Robert Haas

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 the power they currently do.

It's been billed that way, but it's not really accurate. A more
accurate statement would be that it's possible to create a system in
which there is no unconfined role.

Yes, that sounds more precise!

I'm still unsure of terminology; what's a unconfined role? I guess
the layman's description is similar to a superuser, but I'm sure
there's a more refined definition somewhere. Hum, I've just found
Fedora's guide, is the following considered a reasonable picture:

http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html

Organizations may
well not trust specific parts of their database to certain types of
backups, SE-PG should allow this to be controlled somewhat.

I imagine it would be possible to run pg_dump on a database where you
couldn't see all of the objects, and get a dump of just those, but
that's only tangentially related to whether such things as superusers
exist.

I'm not sure what point you're trying to make; in my understanding
superusers can see and do anything--hence they can make a backup.

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's obvious that when you perform a
backup of one of these databases you're only seeing a subset of all of
the objects. Isn't SE-PG just allowing you to do this within a single
PG database?

Partly. There's also a concept called read down, which is
important. It allows you to have, say, secret and classified data in
the same database, and let the secret users see both types but the
classified users see only the classified stuff, not the secret stuff.

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 both sets of data. But if you have higher and lower
classifications of data it's pretty handy (AIUI) to be able to let the
higher-secrecy users read the lower-secrecy data - if you used
separate databases to simulate read-down, you'd have to replicate data
between them, and also have some manual mechanism for tracking which
level of secrecy applied to which to which data.

All of the foregoing is my very layman's understanding of this, so
take it with a grain of salt.

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications

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 way, but it's not really accurate. A more
accurate statement would be that it's possible to create a system in
which there is no unconfined role.

Yes, that sounds more precise!

Yes, Rober's explanation is correct.

http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html

Please note that SELinux/SE-PgSQL checks all the requests from users
without any exceptions, even if he is a superusers.
It makes its access control decisions based on the security policy.

The default security policy (which is provided by SELinux's community)
allows anything on the unconfined ones. Thus, it is allowed anything
at the result.
(Needless to say, DAC permission checks are applied independent from
whether it is confined or unconfined in SELinux.)

It is important the decision is always according to the security policy.

And while I believe
SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
might want to think carefully before you decide to do so, and the
system certainly shouldn't (and can't) force you to set it up that
way.

I agree that this would seem to make the resulting system easier to
manage, however I can also imagine scenarios where the converse would
be true. This is a fuzzy engineering decision of the sort that I don't
like making without a use case---and it would be nice to have several
here.

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 all the databse
objects and can make backups, but any other process cannot touch the
backup files. It means that DBA can launch a backup tool and it creates
a black-boxed file, then he cal also lauch a restore tool to restore
the black-boxed backup, but he cannot see the contents of the backup.
(It might be a similar idea of sudo mechanism.)

It is a separated issue whether the *default* security policy should
supports such an extreme protection, or not.

However, SELinux community shall provide its security policy to make
backup and restore them correctly, and suggest what privilege should
be assigned on the user sheel which launches backup and restore tools.
If it does not work correctly, it is a simply bug.

TODO: I've not provide a draft documentation for backup options to
pg_dump command, but it will be necessary to be reviewed.
It should contains what security context should be assigned on
the user shell which launches the pg_dump also.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SE-PostgreSQL Specifications