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

Stephen Frost wrote:
 * Greg Smith (g...@2ndquadrant.com) wrote:
 I personally feel that Steven  
 Frost's recent comments here about how the PostgreSQL code makes this  
 harder than it should be really cuts to the core of a next step here.   
 The problem facing us isn't is SEPostgreSQL the right solution for  
 providing external security checks?; it's how can the PostgreSQL code  
 be improved so that integrating external security is easier?  Looking  
 
 Thanks for that support, Greg.  This was what I was principally trying
 to do with KaiGai and the commitfest patch I reviewed of his last round.
 Unfortunately, the committer comments I received on that patch didn't
 help us outline a path forward, just declared that the approach in the
 current patch wasn't workable.  My, now much more optimistic thanks to
 our meeting, view is that the concept of abstracting the access controls
 is solid and a necessary first step; but we need to find a better way to
 implement it.

I agree. SELinux should be one of the user selectable options.
An abstraction layer for enhanced access controls are already adopted in
a few open source projects (Linux kernel, X-window), and gets successed.

 Also thanks to our discussion, I've got a much better handle on how
 SELinux and the general secuirty community views PostgreSQL (and the
 Linux kernel for that matter)- it's an application which consists of a
 set of object managers.  That then leads into an approach to address at
 least some of Tom's comments:
 
 Let's start by taking the patch I reviewed and splitting up
 security/access_control.c along object lines.  Of course, the individual
 security/object_ac.c files would only include the .h's that are
 necessary.  This would be a set of much smaller and much more
 managable files which only know about what they should know about- the
 object type they're responsible for.

Basically, agreed. This file had more than 4KL in the last commit fest.

IMO, however, we should consider these issues before splitting up old patch.

(1) Whether the framework should host the default PG model, not only
enhanced security features, or not?
  This patch tried to host both of the default PG model and SELinux.
  But, the default PG model does not have same origin with label-based
  mandatory access controls, such as SELinux, from a historical angle.
  So, this patch needed many of unobvious changes to the core routines.

(2) Whether the framework should be comprehensive, or not?
  This patch tried to replace all the default PG checks in the core
  routines from the begining. It required to review many of unobvious
  changes in the core routine. Because I've been repeatedly pointed out
  to keep changeset smaller, I'm frightened for the direction.
  The coverage of the latest SE-PgSQL/Lite patch is only databases,
  schemas, tables and columns. I think it is a good start to deploy
  security hooks on the routines related to these objects, rather than
  comprehensive support from the begining.

(3) In the future, whether we should allow multiple enhanced securities
at the same time, or not?
  It was not clear in the previous commit fest. But, in fact, Linux
  kernel does not support multiple security features in same time,
  because it just makes security label management complex. (It also
  have another reasons, but just now unlear.)
  I don't think we have any good reason to activate multiple enhanced
  securities at same time.

I think most of folks can agree with (2) and (3). But I expect opinion
is divided at (1).

For example, if we host the default PG checks to create a new database,
all the existing checks shall be moved as follows:

  
http://code.google.com/p/sepgsql/source/browse/trunk/pgsec/src/backend/security/access_control.c?r=2273#1430

In addition, it has to return the security context to be assigned on
the new database, when it hosts SELinux.
Even if this rework is limited to four kind of object classes, I'm
worry about it overs an acceptable complexity.

If the framework hosts only enhanced securities, this hook shall be
implemented as:

  /*
   * ac_database_create
   * It checks permission to create a new database, and returns a security
   * label to be assigned on, or NULL if unnecessary.
   *
   * datName   : name of the new database
   * srcDatOid : OID of the template database
   * datLabel  : user given security label, or NULL
   */
  Value *
  ac_database_create(const char *datName, Oid srcDatOid, Value *datLabel)
  {
  #ifdef HAVE_SELINUX
  if (sepgsql_is_enabled())
  return sepgsql_database_create(datName, srcDatOid, datLabel);
  #endif
  return NULL;
  }

In the caller (createdb()), this invocation shall be placed as follows:

  :
+  datLabel = ac_database_create(dbname, src_dboid, userDatLabel);
  :
+  if (!datLabel)
+  new_record_nulls[Anum_pg_database_datselabel - 1] = true;
+  else
+  new_record[Anum_pg_database_datselabel - 1]
+  =

Re: [HACKERS] SE-PostgreSQL/Lite Review

KaiGai,

* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
(1) Whether the framework should host the default PG model, not only
enhanced security features, or not?
This patch tried to host both of the default PG model and SELinux.
But, the default PG model does not have same origin with label-based
mandatory access controls, such as SELinux, from a historical angle.
So, this patch needed many of unobvious changes to the core routines.

I certainly understand what you're saying here. However, I feel that
these changes to the core of PG are good, and are taking PG in the right
direction to have a much clearer and better implemented security
infrastructure. The fact that you've found a number of odd cases
(duplicate checking, odd failure cases due to checks being done at
various parts of the process, etc) is a testement that this is bringing
the PG code forward even without the addition of SELinux support.

I realize that makes it more work for you and I don't envy you that.

(2) Whether the framework should be comprehensive, or not?
This patch tried to replace all the default PG checks in the core
routines from the begining. It required to review many of unobvious
changes in the core routine. Because I've been repeatedly pointed out
to keep changeset smaller, I'm frightened for the direction.
The coverage of the latest SE-PgSQL/Lite patch is only databases,
schemas, tables and columns. I think it is a good start to deploy
security hooks on the routines related to these objects, rather than
comprehensive support from the begining.

I don't believe we will get support to commit a framework which is
intended to eventually support the PG model (following from my answer to
#1) in a partial form. Perhaps it would be good to split the patch up
on a per-object-type basis, to make it simpler/easier to review (as
in, patch #1: database_ac.c + changes to core for it; patch #2:
table_ac.c + changes to core for it, etc; earlier patches assumed to be
already done in later patches), but the assumption will almost certainly
be that they will all be committed to wonderful CVS at the same time.

(3) In the future, whether we should allow multiple enhanced securities
at the same time, or not?
It was not clear in the previous commit fest. But, in fact, Linux
kernel does not support multiple security features in same time,
because it just makes security label management complex. (It also
have another reasons, but just now unlear.)
I don't think we have any good reason to activate multiple enhanced
securities at same time.

To be honest, I feel that this will just fall out once we get through
doing #1. I've just heard from Casey (author of the SMACK security
manager, an alternative to SELinux) that the PGACE framework (which is
what we suggested he look at) would be easily modified to support SMACK.
I feel the same would be true of what we're talking about in #1. If you
disagree with that, please let me know.

I think most of folks can agree with (2) and (3). But I expect opinion
is divided at (1).

For example, if we host the default PG checks to create a new database,
all the existing checks shall be moved as follows:

http://code.google.com/p/sepgsql/source/browse/trunk/pgsec/src/backend/security/access_control.c?r=2273#1430

In addition, it has to return the security context to be assigned on
the new database, when it hosts SELinux.
Even if this rework is limited to four kind of object classes, I'm
worry about it overs an acceptable complexity.

I feel that what was at issue is that the complexity of
access_control.c was far too great- because *everything* was in that
one file. Splitting access_control.c into smaller files would make them
more managable, and if we implement them all in a similar manner using a
similar policy for function names, arguments, etc, then once the first
object type is reviewed, the others will go more easily for the reviwer.

If the security framework does *not* support the SQL model, I think
we'll get push back from the community that it clearly couldn't be used
by any other security manager generically without alot of potential
changes and additional hooks that could end up bringing us all the way
to being capable of supporting the SQL model anyway. I'm certainly
willing to hear core indicate otherwise though.

Thanks again, KaiGai.

Stephen

signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-11 Thread Greg Smith


Robert Haas wrote:

One comment I have in general about this process is that I think it
would enormously reduce the level of pain associated with making these
kinds of changes if we could get patches that were not full of minor
issues that need to be cleaned up (like comments not properly
adjusted, spelling/grammar errors, formatting inconsistent with the
rest of the code base, poor English).
Sure, it's not fair to ask the committers to do that.  But it's not 
really something we can expect to get in all situations from our English 
as a second language contributors either--it's hard enough to get these 
details right even on stuff done in this country by native speakers.  At 
least we've got a big stack of comments that usually make sense if you 
read them to work with on the SE-PostgreSQL patches, which is much 
better than the alternative.


I think we need a two pronged attack on this issue.  Eventually I think 
someone who wants this feature in there will need to sponsor someone 
(and not even necessarily a coder) to do a sizable round of plain old 
wording cleanup on the comment text of the patch.  Robert is right to 
point out the committers are too expensive, in terms of what work for 
the community they could be doing besides that, to waste on that job.  
English editing help good enough to help a lot for this purpose isn't 
hard to find though.  As far as formatting, it drives me a little crazy 
that it's not more common practice for contributors to do their own 
targeted pgindent runs to at least nail some of the low-hanging fruit in 
that area, due the difficulty of working with the tool.  That's 
something else I think it would be nice to invest a little time in 
improving.  For example, there's no reason we should still have to kick 
back patches regularly just because of tab/space issues, and I know I 
run into one of those nearly every CommitFest.


--
Greg Smith2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com  www.2ndQuadrant.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/Lite Review

Stephen Frost wrote:
 KaiGai,
 
 * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
 (1) Whether the framework should host the default PG model, not only
 enhanced security features, or not?
   This patch tried to host both of the default PG model and SELinux.
   But, the default PG model does not have same origin with label-based
   mandatory access controls, such as SELinux, from a historical angle.
   So, this patch needed many of unobvious changes to the core routines.
 
 I certainly understand what you're saying here.  However, I feel that
 these changes to the core of PG are good, and are taking PG in the right
 direction to have a much clearer and better implemented security
 infrastructure.  The fact that you've found a number of odd cases
 (duplicate checking, odd failure cases due to checks being done at
 various parts of the process, etc) is a testement that this is bringing
 the PG code forward even without the addition of SELinux support.
 
 I realize that makes it more work for you and I don't envy you that.

The reason why I prefer MAC only framework is not a technical reason.
As long as we can review it and acceptable, I have no reason to avoid it.

 (2) Whether the framework should be comprehensive, or not?
   This patch tried to replace all the default PG checks in the core
   routines from the begining. It required to review many of unobvious
   changes in the core routine. Because I've been repeatedly pointed out
   to keep changeset smaller, I'm frightened for the direction.
   The coverage of the latest SE-PgSQL/Lite patch is only databases,
   schemas, tables and columns. I think it is a good start to deploy
   security hooks on the routines related to these objects, rather than
   comprehensive support from the begining.
 
 I don't believe we will get support to commit a framework which is
 intended to eventually support the PG model (following from my answer to
 #1) in a partial form.  Perhaps it would be good to split the patch up
 on a per-object-type basis, to make it simpler/easier to review (as
 in, patch #1: database_ac.c + changes to core for it; patch #2:
 table_ac.c + changes to core for it, etc; earlier patches assumed to be
 already done in later patches), but the assumption will almost certainly
 be that they will all be committed to wonderful CVS at the same time.

As Rober Haas already suggested in another message, my patch in the last
commit fest is too large. It tried to rework anything in a single patch.
The per-object-type basis make sense for me.

In my cosmetic preference, ace_ is better than ac_. The 'e' means
extendable, and ace feels like something cool. :-)
In X-window system, it calls its framework XACE.

And I'd like to store these files in backend/security/ace/*.c, because
backend/security will also store other security modules!

src/
 + backend/
+ security/
   + ace/ ... access control framework
   + sepgsql/ ... selinux specific code
   + smack/   ... (upcoming?) smack specific code
   + solaristx/   ... (upcoming?) solaris-tx specific code
  :


 (3) In the future, whether we should allow multiple enhanced securities
 at the same time, or not?
   It was not clear in the previous commit fest. But, in fact, Linux
   kernel does not support multiple security features in same time,
   because it just makes security label management complex. (It also
   have another reasons, but just now unlear.)
   I don't think we have any good reason to activate multiple enhanced
   securities at same time.
 
 To be honest, I feel that this will just fall out once we get through
 doing #1.  I've just heard from Casey (author of the SMACK security
 manager, an alternative to SELinux) that the PGACE framework (which is
 what we suggested he look at) would be easily modified to support SMACK.
 I feel the same would be true of what we're talking about in #1.  If you
 disagree with that, please let me know.

Ahh, what I want to say is, whether we should allow enhanced securities.
If we host the default PG model on the framework, it is an exception of
the count.

The reason why I prefer the default PG check + one enhanced security at
most is simplification of the security label management.
If two label-based enhanced securities are enabled at same time,
we need two field on pg_class and others to store security context.
In addition, OS allows to choose one enhanced security at most eventually.

In my image, the hook should be as:

  Value *
  ac_database_create([arguments ...])
  {
  /*
   * The default PG checks here.
   * It is never disabled
   */

  /* enhanced security as follows */
  #if defined(HAVE_SELINUX)
  if (sepgsql_is_enabled())
  return sepgsql_database_create(...);
  #elif defined(HAVE_SMACK)
  if (smack_is_enabled())
  return smack_database_create(...);
  #elif defined(HAVE_SOLARISTX)
  if (soltx_is_enabled())
  return soltx_database_create(...);
  #endif

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-11 Thread Joshua Brindle


Greg Smith wrote:

It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group of people all together to do perhaps the biggest single patch
review ever, to work on just that. I gathered up a list of the biggest
concerns about this feature and its associated implementation, we got a
number of regular PostgreSQL hackers and two of the security guys you've
seen on this list all in the same room, and we talked about little but
SEPostgreSQL for hours. Minutes are at
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd
suggest anyone interested in this feature (or in rejecting this feature)
to take a look at what we covered.



I just wanted to add some talking notes here.

User base for the feature:

While my goals for this feature line up with military/government users 
this is in no way the extent of the potential user base. The fact is 
most people won't know they want this feature until it is available. Why 
is that? Well, how many of you have written webapps and implemented 
policy logic in your application rather than the database level? Why do 
people currently feel the need to do this? Is it even possible to 
implement some complex policies (eg., PCI compliance) at the database 
level? If PostgreSQL version whatever suddenly had the ability to 
implement the policy logic in the database, would you move it there? I 
know I would..


Audit:

In past conversations it sounded like some of the Postgres community was 
skeptical even about the design of the security model. For an even 
earlier look (September 2006) of KaiGai and the SELinux community 
talking about the object model and even high level design of the 
solution see http://marc.info/?l=selinuxm=115762285013528w=2


I've read through some of the prior patches, but haven't done an 
extensive audit, not only because of the size but because it became 
apparent relatively quickly that it was a waste of time and the 
community here wasn't going to accept it anyway. If this situation 
changes I think you'll find a few of us willing to donate time to the cause.



Policy:

The policy is easy once you have an object model that covers your use 
cases. You can see in the above discussion how we came to the object 
model we have now and why I've been comfortable with it since then.


An interesting aside, we must have hit the object model pretty well 
since another RDBMS (Trusted Rubix) uses the same one as SEPostgreSQL. 
See http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf



Works outside of SELinux:

As Stephen already pointed out, Casey Schaufler (CC'd) who is the author 
of SMACK http://schaufler-ca.com/ believes that the abstractions 
provided by PGACE will allow integration of his security system as well. 
SMACK is already in the Linux kernel as an alternative LSM to SELinux.


Further, not that I've seen the code or know how they did it, Trusted 
Rubix has support for multiple access control systems 
http://rubix.com/cms/features including Trusted Solaris, Solaris 
Trusted Extensions, SELinux and their own RBAC system.


--

With all that said, I've very interested in seeing this work move along. 
In its current shape it has limited utility in my world (although I know 
of at least 2 solutions I've seen that run 20 Postgres servers on a 
single system just to have database separation). The main thing that 
prevents it from being used in that situation today is superuser access 
(eg., we can't have superusers that can go around and muck in data he's 
not cleared for). But I recognize that this is a first step to a 
potentially great system and I definitely want to see it moving forward.


--
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/Lite Review

2009-12-11 Thread Joshua Brindle


Joshua Brindle wrote:

Greg Smith wrote:

It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group of people all together to do perhaps the biggest single patch
review ever, to work on just that. I gathered up a list of the biggest
concerns about this feature and its associated implementation, we got a
number of regular PostgreSQL hackers and two of the security guys you've
seen on this list all in the same room, and we talked about little but
SEPostgreSQL for hours. Minutes are at
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd
suggest anyone interested in this feature (or in rejecting this feature)
to take a look at what we covered.



I just wanted to add some talking notes here.

User base for the feature:

While my goals for this feature line up with military/government users
this is in no way the extent of the potential user base. The fact is
most people won't know they want this feature until it is available. Why
is that? Well, how many of you have written webapps and implemented
policy logic in your application rather than the database level? Why do
people currently feel the need to do this? Is it even possible to
implement some complex policies (eg., PCI compliance) at the database
level? If PostgreSQL version whatever suddenly had the ability to
implement the policy logic in the database, would you move it there? I
know I would..

Audit:

In past conversations it sounded like some of the Postgres community was
skeptical even about the design of the security model. For an even
earlier look (September 2006) of KaiGai and the SELinux community
talking about the object model and even high level design of the
solution see http://marc.info/?l=selinuxm=115762285013528w=2



I highly suggest a quick read of the above thread, it shows how we 
established an object model in fairly short order. The conversation also 
continues here: http://marc.info/?l=selinuxm=115786457722767w=2


and also here:
http://marc.info/?l=selinuxm=117160445604805w=2
http://marc.info/?l=selinuxm=117160445611588w=2
http://marc.info/?l=selinuxm=117160445608517w=2

--
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/Lite Review

KaiGai,

* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
 As Rober Haas already suggested in another message, my patch in the last
 commit fest is too large. It tried to rework anything in a single patch.
 The per-object-type basis make sense for me.

Agreed.

 In my cosmetic preference, ace_ is better than ac_. The 'e' means
 extendable, and ace feels like something cool. :-)

No complaints here..  I just hope this doesn't end up being *exactly*
the same as your original PGACE patches..  I'd feel terrible if we
weren't able to at least improve something with this extremely long and
drawn our process!

 And I'd like to store these files in backend/security/ace/*.c, because
 backend/security will also store other security modules!

This is perfectly reasonable in my view.  No complaints here.

 src/
  + backend/
 + security/
+ ace/ ... access control framework
+ sepgsql/ ... selinux specific code
+ smack/   ... (upcoming?) smack specific code
+ solaristx/   ... (upcoming?) solaris-tx specific code

Looks good to me.  Perhaps we'll have a smack/ patch showing up very
shortly as well..

 The reason why I prefer the default PG check + one enhanced security at
 most is simplification of the security label management.
 If two label-based enhanced securities are enabled at same time,
 we need two field on pg_class and others to store security context.

Ah, yes, I see your point must more clearly now.  This sounds reasonable
to me.

 In addition, OS allows to choose one enhanced security at most eventually.
 
 In my image, the hook should be as:
 
   Value *
   ac_database_create([arguments ...])
   {
   /*
* The default PG checks here.
* It is never disabled
*/
 
   /* enhanced security as follows */
   #if defined(HAVE_SELINUX)
   if (sepgsql_is_enabled())
   return sepgsql_database_create(...);
   #elif defined(HAVE_SMACK)
   if (smack_is_enabled())
   return smack_database_create(...);
   #elif defined(HAVE_SOLARISTX)
   if (soltx_is_enabled())
   return soltx_database_create(...);
   #endif
   return NULL;
   }
 
 We can share a common image image?

If all of these security modules make sense as only-more-restrictive,
then I have no problem with this approach.  Honestly, I'm fine with the
initial hooks looking as above in any case, since it provides a clear
way to deal with switching out the 'default PG checks' if someone
desires it- you could #if around that block as well.  As it's the
principle/primary, and I could see only-more-restrictive being more
popular, I don't mind having that code in-line in the hook.  The check
itself is still being brought out and into the security/ framework.

I do think that, technically, there's no reason we couldn't allow for
multiple only-more-restrictive models to be enabled and built in a
single binary for systems which support it.  As such, I would make those
just #if defined() rather than #elif.  Let it be decided at runtime
which are actually used, otherwise it becomes a much bigger problem for
packagers too.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL/Lite Review

Greg,

* Greg Smith (g...@2ndquadrant.com) wrote:
 I think we need a two pronged attack on this issue.  Eventually I think  
 someone who wants this feature in there will need to sponsor someone  
 (and not even necessarily a coder) to do a sizable round of plain old  
 wording cleanup on the comment text of the patch.

For the benefit of this list (this was already discussed some at the
BWPUG meeting), I agree with Greg on this and am actively looking to
try and help (either directly in my spare time or indirectly as a
sponsor).  If anyone else is interested or can do so as well, that would
be great!  Please speak up!

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-11 Thread David P. Quigley

On Fri, 2009-12-11 at 11:36 -0500, Stephen Frost wrote:
[Snip...]
 
  In addition, OS allows to choose one enhanced security at most eventually.
  
  In my image, the hook should be as:
  
Value *
ac_database_create([arguments ...])
{
/*
 * The default PG checks here.
 * It is never disabled
 */
  
/* enhanced security as follows */
#if defined(HAVE_SELINUX)
if (sepgsql_is_enabled())
return sepgsql_database_create(...);
#elif defined(HAVE_SMACK)
if (smack_is_enabled())
return smack_database_create(...);
#elif defined(HAVE_SOLARISTX)
if (soltx_is_enabled())
return soltx_database_create(...);
#endif
return NULL;
}
  
  We can share a common image image?
 
 If all of these security modules make sense as only-more-restrictive,
 then I have no problem with this approach.  Honestly, I'm fine with the
 initial hooks looking as above in any case, since it provides a clear
 way to deal with switching out the 'default PG checks' if someone
 desires it- you could #if around that block as well.  As it's the
 principle/primary, and I could see only-more-restrictive being more
 popular, I don't mind having that code in-line in the hook.  The check
 itself is still being brought out and into the security/ framework.
 
 I do think that, technically, there's no reason we couldn't allow for
 multiple only-more-restrictive models to be enabled and built in a
 single binary for systems which support it.  As such, I would make those
 just #if defined() rather than #elif.  Let it be decided at runtime
 which are actually used, otherwise it becomes a much bigger problem for
 packagers too.
 

So when Eamon did the XACE work he allowed for stackable security
modules. We do not allow for this in the Linux kernel but we can still
figure out whether we want to support it for now. I'm not convinced that
the ifdef model is the right way to go. There should be a security
structure where pointers to the appropriate functions reside (like we
have in linux) so this way you have a register_module call which takes
the mac model and puts all the necessary function pointers into the
structure and the hook is just a call to security-create_db. If you
want to make it stackable you make security-create_db a list of
function pointers that get executed in turn. I'll ask Eamon when I see
him next how he handled deregistration of a particular model.

Dave


-- 
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/Lite Review

2009-12-11 Thread Joshua Brindle


Stephen Frost wrote:

KaiGai,


snip

I do think that, technically, there's no reason we couldn't allow for
multiple only-more-restrictive models to be enabled and built in a
single binary for systems which support it.  As such, I would make those
just #if defined() rather than #elif.  Let it be decided at runtime
which are actually used, otherwise it becomes a much bigger problem for
packagers too.



It isn't just a case of using #if and it magically working. You'd need a 
system to manage multiple labels on each object that can be addressed by 
different systems. So instead of having an object mapped only to 
system_u:object_r:mydb_t:s15 you'd also have to have it mapped to, 
eg., ^ for Smack.


--
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/Lite Review

Josh,

* Joshua Brindle (met...@manicmethod.com) wrote:
 Stephen Frost wrote:
 I do think that, technically, there's no reason we couldn't allow for
 multiple only-more-restrictive models to be enabled and built in a
 single binary for systems which support it.  As such, I would make those
 just #if defined() rather than #elif.  Let it be decided at runtime
 which are actually used, otherwise it becomes a much bigger problem for
 packagers too.

 It isn't just a case of using #if and it magically working. You'd need a  
 system to manage multiple labels on each object that can be addressed by  
 different systems. So instead of having an object mapped only to  
 system_u:object_r:mydb_t:s15 you'd also have to have it mapped to,  
 eg., ^ for Smack.

I'm not sure I see that being a problem..  We're going to have
references in our object managers which make sense to us (eg: table
OIDs) and then a way of mapping those to some label (or possibly a set
of labels, as you describe).  We might want to reconsider the catalog
structure a bit if we want to support more than one at a time, but I
don't see it as a huge problem to support more than one label existing
for a given object.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-11 Thread Robert Treat

On Thursday 10 December 2009 21:47:18 KaiGai Kohei wrote:
 Greg Smith wrote:
  It's funny; we started out this CommitFest with me scrambling to find
  someone, anyone, willing to review the latest SE-PostgreSQL patch,
  knowing it was a big job and few were likely to volunteer.  Then
  schedules lined up just right, and last night I managed to get a great
  group of people all together to do perhaps the biggest single patch
  review ever, to work on just that.I gathered up a list of the
  biggest concerns about this feature and its associated implementation,
  we got a number of regular PostgreSQL hackers and two of the security
  guys you've seen on this list all in the same room, and we talked about
  little but SEPostgreSQL for hours.  Minutes are at
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd
  suggest anyone interested in this feature (or in rejecting this feature)
  to take a look at what we covered.

 I repent that I cannot attend here.
 The wikipage is a good summarize. Thanks for your efforts.

  There's comments there, with references for you [citation needed] types,
  to help answer four of the most common complaints I've seen on this list
  about this feature:
 
  -Is there really a user base for it?
  -Has it been audited by security professionals?
  -Is there a useful SELinux policty to support it?
  -Will this work with other security frameworks?
 
  I feel pretty good now that these are not really our community's
  problems--these have had at least modest, and in some cases extensive,
  due diligence applied to them.  And we've confirmed there's access to
  expertise from the security community to help out with remaining
  concerns there, in person even if we plan it out right.  I personally
  suspect they've been discouraged from getting involved more by the slow
  pace this has been proceeding within our community and the general
  disarray around it, which would be understandable.

 IMO, the slow pace is not a primary reason. In fact, SELinux was released
 at 2000 Dec, but it gets integtated into the mainline kernel at 2003 Aug
 with various kind of improvements. It takes about 3 years from the first
 relase. IIRC, now we take 2.5 years from the first announce of SE-PgSQL
 in this list, and various kind of improvements and cleanups had been done.
 It is a bit long term, but not too long term.

 The reason of this gap is that people have individual consciousness about
 their security. I often represent it as security is a subjective term.
 Needless to say, we don't have magic-bullets for any threats. Any
 technology has its metirs and limitations. However, people tend to say it
 is nonsense, if the feature does not match with their recognizable demands
 or threats.

 Security-folks know MAC is not magic-bullets, while it is a significant
 piece of system security. But some of complaints might be pointless for
 security experts, so had been dismotivated.
 From the perspective of security folks, we have to introduce it doggedly.
 And, I'd like to understand database folks there are various kind of
 security models and viewpoints here. SELinux is one of them.

  The parts I do believe we have reason to be concerned are with the code
  integration into the PostgreSQL core, and no one has any easy answers to
  things like isn't this going to increase CERT advisories? and who's
  going to maintain this besides KaiGai?  I personally feel that Steven
  Frost's recent comments here about how the PostgreSQL code makes this
  harder than it should be really cuts to the core of a next step here.
  The problem facing us isn't is SEPostgreSQL the right solution for
  providing external security checks?; it's how can the PostgreSQL code
  be improved so that integrating external security is easier?  Looking
  at SEPostgreSQL is great because it really highlights where the existing
  set of places are.  This general idea matches where thinking on things
  like row-level security was already going too--implement this for the
  database in general, then link SEPostgres in as just one provider of a
  security restriction.

 Right, it seems to me the security provider is a good phrase to represent
 this feature. It just provides additional access control decisions based on
 the different perspective of security model.

 Please note that the access control granularity is not an essential issue.
 We can also assume table-level mandatory access controls for instance.

 The latest patch provides table/column level controls without row-level,
 because the current PgSQL has facilities to know what tables and columns
 are referenced reasonably, so SE-PgSQL also can know what tables/columns
 are referenced without special tricks.

 Please remind the earlier SE-PgSQL in v8.2.x. It walked on the Query tree
 to pick up what columns were accessed.

  I hope the review from the BWPUG helps everyone out, and that the
  suggestions on the wiki for the Follow-up plan are helpful.  As CF

Re: [HACKERS] SE-PostgreSQL/Lite Review

Stephen Frost wrote:
 In my cosmetic preference, ace_ is better than ac_. The 'e' means
 extendable, and ace feels like something cool. :-)
 
 No complaints here..  I just hope this doesn't end up being *exactly*
 the same as your original PGACE patches..  I'd feel terrible if we
 weren't able to at least improve something with this extremely long and
 drawn our process!

Please forget old PGACE. We're talking about our future. :-)

 And I'd like to store these files in backend/security/ace/*.c, because
 backend/security will also store other security modules!
 
 This is perfectly reasonable in my view.  No complaints here.
 
 src/
  + backend/
 + security/
+ ace/ ... access control framework
+ sepgsql/ ... selinux specific code
+ smack/   ... (upcoming?) smack specific code
+ solaristx/   ... (upcoming?) solaris-tx specific code
 
 Looks good to me.  Perhaps we'll have a smack/ patch showing up very
 shortly as well..

It's a welcome feature.

 The reason why I prefer the default PG check + one enhanced security at
 most is simplification of the security label management.
 If two label-based enhanced securities are enabled at same time,
 we need two field on pg_class and others to store security context.
 
 Ah, yes, I see your point must more clearly now.  This sounds reasonable
 to me.
 
 In addition, OS allows to choose one enhanced security at most eventually.

 In my image, the hook should be as:

   Value *
   ac_database_create([arguments ...])
   {
   /*
* The default PG checks here.
* It is never disabled
*/

   /* enhanced security as follows */
   #if defined(HAVE_SELINUX)
   if (sepgsql_is_enabled())
   return sepgsql_database_create(...);
   #elif defined(HAVE_SMACK)
   if (smack_is_enabled())
   return smack_database_create(...);
   #elif defined(HAVE_SOLARISTX)
   if (soltx_is_enabled())
   return soltx_database_create(...);
   #endif
   return NULL;
   }

 We can share a common image image?
 
 If all of these security modules make sense as only-more-restrictive,
 then I have no problem with this approach.  Honestly, I'm fine with the
 initial hooks looking as above in any case, since it provides a clear
 way to deal with switching out the 'default PG checks' if someone
 desires it- you could #if around that block as well.  As it's the
 principle/primary, and I could see only-more-restrictive being more
 popular, I don't mind having that code in-line in the hook.  The check
 itself is still being brought out and into the security/ framework.

Ahh, indeed, #elif does not allow a single binary to provide multiple
options. You are right.

I'd like to rewrite it as follows:

  Value *
  ac_database_create([arguments ...])
  {
  Value *retval = NULL;

  /*
   * The default PG checks here.
   * It is never disabled
   */

  switch (ace_feature)
  {
  #ifdef HAVE_SELINUX
  case ACE_SELINUX_SUPPORT:
  if (sepgsql_is_enabled())
  retval = sepgsql_database_create(...);
  break;
  #endif
  #ifdef HAVE_SMACK
  case ACE_SMACK_SUPPORT:
  if (smack_is_enabled())
  retval = smack_database_create(...);
  break;
  #endif
  #ifdef HAVE_SOLARISTX
  case ACE_SOLARISTX_SUPPORT:
  if (soltx_is_enabled())
  retval = soltx_database_create(...);
  break;
  #endif
  default:
  break;
  }

  return retval;
  }

 I do think that, technically, there's no reason we couldn't allow for
 multiple only-more-restrictive models to be enabled and built in a
 single binary for systems which support it.  As such, I would make those
 just #if defined() rather than #elif.  Let it be decided at runtime
 which are actually used, otherwise it becomes a much bigger problem for
 packagers too.

The reason why I don't want to support multiple enhanced securities at
same time is complexity of security label management, not access control
model.

Unlike X-server, RDBMS have to manage the security label of database
object persistently on the disk. It naturally needs enhancement of data
structure, such as pg_class.relsecon field in the latest SE-PgSQL/Lite.

If the third enhanced security does not use security label, basically,
I think it is feasible. In fact, the default PG check is a security
provider without security label, and it can coexist with SELinux.

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/Lite Review

Stephen Frost wrote:
 Josh,
 
 * Joshua Brindle (met...@manicmethod.com) wrote:
 Stephen Frost wrote:
 I do think that, technically, there's no reason we couldn't allow for
 multiple only-more-restrictive models to be enabled and built in a
 single binary for systems which support it.  As such, I would make those
 just #if defined() rather than #elif.  Let it be decided at runtime
 which are actually used, otherwise it becomes a much bigger problem for
 packagers too.
 It isn't just a case of using #if and it magically working. You'd need a  
 system to manage multiple labels on each object that can be addressed by  
 different systems. So instead of having an object mapped only to  
 system_u:object_r:mydb_t:s15 you'd also have to have it mapped to,  
 eg., ^ for Smack.
 
 I'm not sure I see that being a problem..  We're going to have
 references in our object managers which make sense to us (eg: table
 OIDs) and then a way of mapping those to some label (or possibly a set
 of labels, as you describe).  We might want to reconsider the catalog
 structure a bit if we want to support more than one at a time, but I
 don't see it as a huge problem to support more than one label existing
 for a given object.

If we allow multiple security labels on a database object, we have to
expand the structure of system catalog whenever a new security feature
will come in. I think it against to the purpose of the framework.

Even if we store them external relations to reference the object by OID,
we have to provide multiple interface to import/export a security label
for each enhanced securities. For example, it requires much complex patch
to the pg_dump.

My preference is all the enhanced securities shares a common facility
to manage security label, a common statement support and a common
backup/restore support.

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/Lite Review

I'd like to summary about the framework.

* Functionalities

The ACE framework hosts both of the default PG checks and upcoming
enhanced securities. We can build a binary with multiple enhanced
security features, but user can choose one from them at most due
to the security label management.

So, it basically has the following structure:

  Value *
  ac_database_create([arguments ...])
  {
  Value *retval = NULL;

  /*
   * The default PG checks here. It is never disabled.
   */

  switch (ace_feature)
  {
  #ifdef HAVE_SELINUX
  case ACE_SELINUX_SUPPORT:
  if (sepgsql_is_enabled())
  retval = sepgsql_database_create(...);
  break;
  #endif
  #ifdef HAVE_SMACK
  case ACE_SMACK_SUPPORT:
  if (smack_is_enabled())
  retval = smack_database_create(...);
  break;
  #endif
  default:
   break;
  }
  return retval;
  }


* Namespace

The framework is stored in the src/backend/security/ace.
As a general rule, Each source file has this naming convension:
  src/backend/security/ace/object_class_ace.c

Uncategolized hooks (such as cascaded-deletion called from dependency
system) are stored in ace/sysobj_ace.c. It is an exception.

All the framework functions (except for static) have ace_ prefix
to distinguish from any other internal routines.

The security providers (SELinux, upcoming SMACK, ...) specific files
are stored in a certain directory in src/backend/security/ace/.
SE-PgSQL shall use sepgsql directory.

* Documentation

I don't plan to provide SGML documentation about ACE itself, except for
internal section, because it is an internal infrastructure.
For developers, src/backend/security/ace/README will provide a brief
overview of the ACE framework, and every security hooks have source
code comments to introduce the specification of itself.

* Patches

As a general rule, a patch is organized for each object classes, except
for very tiny object classes.
e.g)
  pgsql-ace-02-database.patch
  pgsql-ace-03-schema.patch
 :

I'll try to submit a set of patches related to the following object classes
and functionalities by the 12/16.

 * pgsql-ace-01-common.patch
   It contains common part of ACE and uncategolized ones, such as cascaded
   deletion from dependency, and so on.
 * pgsql-ace-02-database.patch
   It contains security hooks related to pg_database.
 * pgsql-ace-03-schema.patch
   It contains security hooks related to pg_namespace.
 * pgsql-ace-04-relation.patch
   It contains security hooks related to pg_class and pg_attribtue
 * pgace-ace-05-label.patch
   It contains security label support in SQL statement.

I'd like to conclude arguable things earlier than whole of reworks.

Then, we shall be able to see the rest of patches within this year.

Thanks,

KaiGai Kohei wrote:
 Stephen Frost wrote:
 In my cosmetic preference, ace_ is better than ac_. The 'e' means
 extendable, and ace feels like something cool. :-)
 No complaints here..  I just hope this doesn't end up being *exactly*
 the same as your original PGACE patches..  I'd feel terrible if we
 weren't able to at least improve something with this extremely long and
 drawn our process!
 
 Please forget old PGACE. We're talking about our future. :-)
 
 And I'd like to store these files in backend/security/ace/*.c, because
 backend/security will also store other security modules!
 This is perfectly reasonable in my view.  No complaints here.

 src/
  + backend/
 + security/
+ ace/ ... access control framework
+ sepgsql/ ... selinux specific code
+ smack/   ... (upcoming?) smack specific code
+ solaristx/   ... (upcoming?) solaris-tx specific code
 Looks good to me.  Perhaps we'll have a smack/ patch showing up very
 shortly as well..
 
 It's a welcome feature.
 
 The reason why I prefer the default PG check + one enhanced security at
 most is simplification of the security label management.
 If two label-based enhanced securities are enabled at same time,
 we need two field on pg_class and others to store security context.
 Ah, yes, I see your point must more clearly now.  This sounds reasonable
 to me.

 In addition, OS allows to choose one enhanced security at most eventually.

 In my image, the hook should be as:

   Value *
   ac_database_create([arguments ...])
   {
   /*
* The default PG checks here.
* It is never disabled
*/

   /* enhanced security as follows */
   #if defined(HAVE_SELINUX)
   if (sepgsql_is_enabled())
   return sepgsql_database_create(...);
   #elif defined(HAVE_SMACK)
   if (smack_is_enabled())
   return smack_database_create(...);
   #elif defined(HAVE_SOLARISTX)
   if (soltx_is_enabled())
   return soltx_database_create(...);
   #endif
   return NULL;
   }

 We can share a common image image?
 If all of these security modules make sense as only-more-restrictive,
 then I have no problem with

[HACKERS] SE-PostgreSQL/Lite Review

2009-12-10 Thread Greg Smith

It's funny; we started out this CommitFest with me scrambling to find 
someone, anyone, willing to review the latest SE-PostgreSQL patch, 
knowing it was a big job and few were likely to volunteer.  Then 
schedules lined up just right, and last night I managed to get a great 
group of people all together to do perhaps the biggest single patch 
review ever, to work on just that.I gathered up a list of the 
biggest concerns about this feature and its associated implementation, 
we got a number of regular PostgreSQL hackers and two of the security 
guys you've seen on this list all in the same room, and we talked about 
little but SEPostgreSQL for hours.  Minutes are at 
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd 
suggest anyone interested in this feature (or in rejecting this feature) 
to take a look at what we covered.


There's comments there, with references for you [citation needed] types, 
to help answer four of the most common complaints I've seen on this list 
about this feature:


-Is there really a user base for it?
-Has it been audited by security professionals?
-Is there a useful SELinux policty to support it?
-Will this work with other security frameworks?

I feel pretty good now that these are not really our community's 
problems--these have had at least modest, and in some cases extensive, 
due diligence applied to them.  And we've confirmed there's access to 
expertise from the security community to help out with remaining 
concerns there, in person even if we plan it out right.  I personally 
suspect they've been discouraged from getting involved more by the slow 
pace this has been proceeding within our community and the general 
disarray around it, which would be understandable.


The parts I do believe we have reason to be concerned are with the code 
integration into the PostgreSQL core, and no one has any easy answers to 
things like isn't this going to increase CERT advisories? and who's 
going to maintain this besides KaiGai?  I personally feel that Steven 
Frost's recent comments here about how the PostgreSQL code makes this 
harder than it should be really cuts to the core of a next step here.  
The problem facing us isn't is SEPostgreSQL the right solution for 
providing external security checks?; it's how can the PostgreSQL code 
be improved so that integrating external security is easier?  Looking 
at SEPostgreSQL is great because it really highlights where the existing 
set of places are.  This general idea matches where thinking on things 
like row-level security was already going too--implement this for the 
database in general, then link SEPostgres in as just one provider of a 
security restriction.


I hope the review from the BWPUG helps everyone out, and that the 
suggestions on the wiki for the Follow-up plan are helpful.  As CF 
Manager, I feel we've given this patch its fair chunk of time this last 
month.  I don't really see any options except to mark it returned with 
feedback yet again for now, as this CF is nearing its close and there's 
still plenty of open issues.  My hope is that we've made progress toward 
answering some of the fundamental concerns that keep popping up around 
this patch for good, and that a plan with community members who will act 
on it (in this country for once) is coming together.  As always, we owe 
KaiGai a debt for offering his code contributions, sticking through an 
immense amount of criticism, and suggesting ways the rest of the 
database might become better overall through that interaction.  I do 
hope a committer is able to give his Largeobject access controls patch 
proper attention and commit it if feasible to do so.  It would be nice 
to see confirmed progress toward the larger goal of both feature and 
buzzword/checkbox complete PostgreSQL security is being made through his 
contributions.


At this point, I think someone comfortable with hacking into the 
PostgreSQL core will need to work on this project from that angle before 
even SE/PostgreSQL Lite is likely to be something we can commit.  Maybe 
we can get KaiGai thinking in those terms instead of how he's been 
approaching the problem.  Maybe Bruce or Steven can champion that work.  
I have to be honest and say that I'm not optimistic that this is 
possible or even a good idea to accomplish in the time remaining during 
this release.  A patch that touches the security model in fairly 
fundamental ways seems like it would be much better as an alpha-1 
candidate, while there's still plenty of time to shake out issues, than 
as a beta-1 or even alpha-3 one.  And I'm skeptical that this feature 
really fits the true use-cases for SEPostgres without row-level 
filtering anyway.  After our talk last night, it's obvious we need to 
figure out how to get that back before including the code does what 
people really want here.  But based on looking at the market for this 
sort of feature, providing this new form of security integrated into the

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-10 Thread KaiGai Kohei

Greg Smith wrote:
 It's funny; we started out this CommitFest with me scrambling to find 
 someone, anyone, willing to review the latest SE-PostgreSQL patch, 
 knowing it was a big job and few were likely to volunteer.  Then 
 schedules lined up just right, and last night I managed to get a great 
 group of people all together to do perhaps the biggest single patch 
 review ever, to work on just that.I gathered up a list of the 
 biggest concerns about this feature and its associated implementation, 
 we got a number of regular PostgreSQL hackers and two of the security 
 guys you've seen on this list all in the same room, and we talked about 
 little but SEPostgreSQL for hours.  Minutes are at 
 http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd 
 suggest anyone interested in this feature (or in rejecting this feature) 
 to take a look at what we covered.

I repent that I cannot attend here.
The wikipage is a good summarize. Thanks for your efforts.


 There's comments there, with references for you [citation needed] types, 
 to help answer four of the most common complaints I've seen on this list 
 about this feature:
 
 -Is there really a user base for it?
 -Has it been audited by security professionals?
 -Is there a useful SELinux policty to support it?
 -Will this work with other security frameworks?
 
 I feel pretty good now that these are not really our community's 
 problems--these have had at least modest, and in some cases extensive, 
 due diligence applied to them.  And we've confirmed there's access to 
 expertise from the security community to help out with remaining 
 concerns there, in person even if we plan it out right.  I personally 
 suspect they've been discouraged from getting involved more by the slow 
 pace this has been proceeding within our community and the general 
 disarray around it, which would be understandable.

IMO, the slow pace is not a primary reason. In fact, SELinux was released
at 2000 Dec, but it gets integtated into the mainline kernel at 2003 Aug
with various kind of improvements. It takes about 3 years from the first
relase. IIRC, now we take 2.5 years from the first announce of SE-PgSQL
in this list, and various kind of improvements and cleanups had been done.
It is a bit long term, but not too long term.

The reason of this gap is that people have individual consciousness about
their security. I often represent it as security is a subjective term.
Needless to say, we don't have magic-bullets for any threats. Any technology
has its metirs and limitations. However, people tend to say it is nonsense,
if the feature does not match with their recognizable demands or threats.

Security-folks know MAC is not magic-bullets, while it is a significant
piece of system security. But some of complaints might be pointless for
security experts, so had been dismotivated.
From the perspective of security folks, we have to introduce it doggedly.
And, I'd like to understand database folks there are various kind of
security models and viewpoints here. SELinux is one of them.

 The parts I do believe we have reason to be concerned are with the code 
 integration into the PostgreSQL core, and no one has any easy answers to 
 things like isn't this going to increase CERT advisories? and who's 
 going to maintain this besides KaiGai?  I personally feel that Steven 
 Frost's recent comments here about how the PostgreSQL code makes this 
 harder than it should be really cuts to the core of a next step here.  
 The problem facing us isn't is SEPostgreSQL the right solution for 
 providing external security checks?; it's how can the PostgreSQL code 
 be improved so that integrating external security is easier?  Looking 
 at SEPostgreSQL is great because it really highlights where the existing 
 set of places are.  This general idea matches where thinking on things 
 like row-level security was already going too--implement this for the 
 database in general, then link SEPostgres in as just one provider of a 
 security restriction.

Right, it seems to me the security provider is a good phrase to represent
this feature. It just provides additional access control decisions based on
the different perspective of security model.

Please note that the access control granularity is not an essential issue.
We can also assume table-level mandatory access controls for instance.

The latest patch provides table/column level controls without row-level,
because the current PgSQL has facilities to know what tables and columns
are referenced reasonably, so SE-PgSQL also can know what tables/columns
are referenced without special tricks.

Please remind the earlier SE-PgSQL in v8.2.x. It walked on the Query tree
to pick up what columns were accessed.

 I hope the review from the BWPUG helps everyone out, and that the 
 suggestions on the wiki for the Follow-up plan are helpful.  As CF 
 Manager, I feel we've given this patch its fair chunk of time this last 
 month.  I don't really

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-10 Thread Stephen Frost

* Greg Smith (g...@2ndquadrant.com) wrote:
 I personally feel that Steven  
 Frost's recent comments here about how the PostgreSQL code makes this  
 harder than it should be really cuts to the core of a next step here.   
 The problem facing us isn't is SEPostgreSQL the right solution for  
 providing external security checks?; it's how can the PostgreSQL code  
 be improved so that integrating external security is easier?  Looking  

Thanks for that support, Greg.  This was what I was principally trying
to do with KaiGai and the commitfest patch I reviewed of his last round.
Unfortunately, the committer comments I received on that patch didn't
help us outline a path forward, just declared that the approach in the
current patch wasn't workable.  My, now much more optimistic thanks to
our meeting, view is that the concept of abstracting the access controls
is solid and a necessary first step; but we need to find a better way to
implement it.

Also thanks to our discussion, I've got a much better handle on how
SELinux and the general secuirty community views PostgreSQL (and the
Linux kernel for that matter)- it's an application which consists of a
set of object managers.  That then leads into an approach to address at
least some of Tom's comments:

Let's start by taking the patch I reviewed and splitting up
security/access_control.c along object lines.  Of course, the individual
security/object_ac.c files would only include the .h's that are
necessary.  This would be a set of much smaller and much more
managable files which only know about what they should know about- the
object type they're responsible for.

Clearly, code comments also need to be reviewed and issues with them
addressed.  I'm also not a fan of the skip permissions check
arguments, which are there specifically to address cascade deletions,
which is a requirment of our PG security model.  I'd love to see a
better solution and am open to suggestions or thoughts about what one
would be.  I know one of KaiGai's concerns in this area was performance,
butas we often do for PG, perhaps we should consider that second and
first consider what it would look like if we ignored performance
concerns.  This would change skip permissions check to what object is
being deleted, and am I a sub-object of that?.  I don't feel like I've
explained that well enough, perhaps someone else could come up with
another solution, or maybe figure out a better way to describe what I'm
trying to get with this.

Regarding the special-purpose shims- I feel there should be a way for us
to handle them better.  This might be a good use-case for column-level
privileges in pg_catalog.  That's pure speculation at the moment tho, I
havn't re-looked at those shims lately to see if that even makes sense.
I don't like them either though, for what it's worth.

Regarding contrib modules- I view them as I do custom code which the
user writes and loads through dlopen() into the backend process- there
should be a way for it to do security right, but it ultimately has to
be the responsibility of the contrib module.  Admins can review what
contrib modules have been made SELinux/etc aware and choose to install
only those which they trust.

 Maybe Bruce or Steven can champion that work.   

See above? ;)  I've had enough of a break from this and our discussion
has revitalized me.  I certainly welcome Bruce's comments, as well as
anyone else.

 I have to be honest and say that I'm not optimistic that this is  
 possible or even a good idea to accomplish in the time remaining during  
 this release.  

While I agree with you, I wish you hadn't brought it up. :)  Mostly
because I feel like it may discourage people from wanting to spend time
on it due to desire to focus on things which are likely to make it into
the next release.  That being said, I don't feel that'll be an issue for
KaiGai or myself, but getting someone beyond us working on this would
really be great, especially yourself and/or Bruce.

 On my side, in addition to helping coordinate everyone pushing in the
 same direction, I'll also continue trying to shake out some sponsorship  
 funding for additional work out of the people in this country it would  
 benefit.  It seems I'm going to keep getting pulled into the middle of  
 this area regularly anyway.

Thank you for that.  I'm planning to do the same and will certainly let
people know, to the extent possible, of anything I'm able to dig up.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL/Lite Review

2009-12-10 Thread Greg Smith


Stephen Frost wrote:

* Greg Smith (g...@2ndquadrant.com) wrote:
  
I have to be honest and say that I'm not optimistic that this is  
possible or even a good idea to accomplish in the time remaining during  
this release.  


While I agree with you, I wish you hadn't brought it up. :)  Mostly
because I feel like it may discourage people from wanting to spend time
on it due to desire to focus on things which are likely to make it into
the next release.
The reason I mentioned it is that I was getting a general feeling that 
the community at large was going to view not getting the patch into 8.5 
as a final straw for working on it.  I wanted to be clear that the scope 
of doing this right may extend beyond that, but that shouldn't be a 
reason to give up on it.  I think KaiGai's comments about how it took 3 
years to get SELinux similarly integrated into the Linux core rather 
then shipping as an add-on is encouraging, in that the way and scope of 
how we're struggling with this topic is not something we should consider 
extraordinary and therefore a failing.  This is not an easy thing to do 
for anyone who tries it.


--
Greg Smith2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com  www.2ndQuadrant.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/Lite Review

2009-12-10 Thread Robert Haas

On Thu, Dec 10, 2009 at 10:39 PM, Stephen Frost sfr...@snowman.net wrote:
 Let's start by taking the patch I reviewed and splitting up
 security/access_control.c along object lines.  Of course, the individual
 security/object_ac.c files would only include the .h's that are
 necessary.  This would be a set of much smaller and much more
 managable files which only know about what they should know about- the
 object type they're responsible for.

Good idea.

 Clearly, code comments also need to be reviewed and issues with them
 addressed.  I'm also not a fan of the skip permissions check
 arguments, which are there specifically to address cascade deletions,
 which is a requirment of our PG security model.  I'd love to see a
 better solution and am open to suggestions or thoughts about what one
 would be.  I know one of KaiGai's concerns in this area was performance,
 butas we often do for PG, perhaps we should consider that second and
 first consider what it would look like if we ignored performance
 concerns.  This would change skip permissions check to what object is
 being deleted, and am I a sub-object of that?.  I don't feel like I've
 explained that well enough, perhaps someone else could come up with
 another solution, or maybe figure out a better way to describe what I'm
 trying to get with this.

I don't know the right solution to this either but I'm glad you're
thinking about it.

 Regarding the special-purpose shims- I feel there should be a way for us
 to handle them better.  This might be a good use-case for column-level
 privileges in pg_catalog.  That's pure speculation at the moment tho, I
 havn't re-looked at those shims lately to see if that even makes sense.
 I don't like them either though, for what it's worth.

I am not sure if I fully understand either the problem or your
proposed solution, but it seems to me that permissions checking needs
to be forcibly crammed into a fixed number of buckets.  In other
words, for, say, databases, there should be a finite list of objects
that can be performed on databases: create, drop, connect, etc.  Any
permissions question that comes up has to be asked in terms of one of
those operations.  So if somebody writes code, in core or contrib,
that displays the size of the database, it has to key off the same
permissions as one of those pre-existing categories.  It doesn't get
to invent rules specific to that case from scratch.

(Humerous interlude: I worked on a project written in C++ many years
ago where there were these security context objects, and all
user-visible interfaces had to check with the security context before
allowing any privileged operation, using the may_i() method.  By
convention, variables of the security context type were always named
mother, thus mother-may_i(whatever)...)

[...snip...]

One comment I have in general about this process is that I think it
would enormously reduce the level of pain associated with making these
kinds of changes if we could get patches that were not full of minor
issues that need to be cleaned up (like comments not properly
adjusted, spelling/grammar errors, formatting inconsistent with the
rest of the code base, poor English).  I can't speak for anyone else,
but it seems to me that asking a committer to fix all of that stuff on
top of substantive review of the patch is asking a lot.  I realize
that this is difficult for non-native speakers of English and a lot of
work even for those who are fluent in the language, but it is part of
our project culture and style to do these kinds of things right and I
certainly don't want to be the one who lowers our standards in this
area.  For a small patch, it's not so bad to have to fix these things
(though it's certainly nicer not to need to) but for a patch of five
or ten thousand lines, it's a LOT of work.

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

2009-08-04 Thread Stephen Frost

* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
 David Fetter wrote:
  On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
  Just generally, access control is a great way to describe what's
  actually happening here.  That people conflate access control with
  security has resulted in a 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.

pg_ac_?  Still shorter than 'security_', uses the pg_ prefix, which we
use in a number of other places, and has 'ac' in it..

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-04 Thread Tom Lane

Stephen Frost sfr...@snowman.net writes:
 * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
 My concern is access_control_ is a bit long for prefixes,
 but ac_ is too short to represent what it is doing.

 pg_ac_?  Still shorter than 'security_', uses the pg_ prefix, which we
 use in a number of other places, and has 'ac' in it..

I don't see anything wrong with ac_.  Short is good, and there isn't
any other concept in the PG internals that it would conflict with.
If there were, pg_ac_ would surely not help to disambiguate.

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-08-04 Thread Stephen Frost

* Tom Lane (t...@sss.pgh.pa.us) wrote:
 Stephen Frost sfr...@snowman.net writes:
  * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
  My concern is access_control_ is a bit long for prefixes,
  but ac_ is too short to represent what it is doing.
 
  pg_ac_?  Still shorter than 'security_', uses the pg_ prefix, which we
  use in a number of other places, and has 'ac' in it..
 
 I don't see anything wrong with ac_.  Short is good, and there isn't
 any other concept in the PG internals that it would conflict with.
 If there were, pg_ac_ would surely not help to disambiguate.

Works for me.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

2009-08-04 Thread KaiGai Kohei

Stephen Frost wrote:
 * Tom Lane (t...@sss.pgh.pa.us) wrote:
 Stephen Frost sfr...@snowman.net writes:
 * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
 My concern is access_control_ is a bit long for prefixes,
 but ac_ is too short to represent what it is doing.
 pg_ac_?  Still shorter than 'security_', uses the pg_ prefix, which we
 use in a number of other places, and has 'ac' in it..
 I don't see anything wrong with ac_.  Short is good, and there isn't
 any other concept in the PG internals that it would conflict with.
 If there were, pg_ac_ would surely not help to disambiguate.
 
 Works for me.

OK, I'll go on with the ac_ prefix.

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

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


Robert Haas wrote:

If superusers DON'T exist, that would be making the opposite
statement, namely, that there isn't ANY WAY to get a backup that you
can be sure DOES contain all of the objects.

The traditional approach would be to maintain multiple physically
separate databases; in this setup it'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.
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements also.

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.)

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?

Robert Haas wrote:
 I think the best thing for this patch right now is to move it to
 Returned with Feedback.  I can't see any way that this patch is
 going to be made committable for this CommitFest, and I think that
 pretending otherwise is only encouraging KaiGai to do another of his
 lighting rework-and-resubmits.  While those are very impressive,
 they're not getting us where we need to be.  I think that what KaiGai
 needs to do here is get the spec written (with the help of Greg
 Williamson and anyone else who is willing to pitch in), and submit it
 for comments.  I don't think there will be a problem getting that
 reviewed outside of a CommitFest, and it's not a patch anyway, so the
 time that it gets submitted is not crucial.  What is crucial is that
 it is a good spec that everyone can read, and hopefully understand and
 discuss.  There is no point writing any more code, or submitting any
 more patches, until we have agreement on what those patches are
 supposed to do.

I also agree that the easy understandable specification what SE-PostgreSQL
tries to achieve is more important than implementation.

I described it from the scratch again.
Here is an initial draft:
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

I would like to improve documentation quality and fix its specification
during the discussion.

 I am going to go ahead and mark this as Returned with Feedback.

Agreed.

-- 
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-24 Thread Greg Williamson


Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got 
some non-work related issues which may keep from giving this a good look until 
the weekend (FWIW). I'll post any questions I have.

Thanks,

Greg W.



- Original Message 
From: KaiGai Kohei kai...@ak.jp.nec.com
To: Robert Haas robertmh...@gmail.com
Cc: pgsql-hackers@postgresql.org; KaiGai Kohei kai...@kaigai.gr.jp; Greg 
Williamson gwilliamso...@yahoo.com; Sam Mason s...@samason.me.uk; Joshua 
Brindle met...@manicmethod.com
Sent: Thursday, July 23, 2009 9:54:10 PM
Subject: SE-PostgreSQL Specifications

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

2009-07-24 Thread Martijn van Oosterhout

On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
 Here is the initial draft of SE-PostgreSQL specifications:
 
   http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really obvious language stuff and an example but the English is
quite good.

One thing I know people are going to ask: why did you use names like
create and delete and not the usual names that postgresql itself
uses. I suspect the answer is because that's the standard naming used
in SELinux, but I think you need to spell that out somewhere.

The same for the db_* convention. Do you have a reference to naming
conventions for SELinux permissions?

I need to think it over some more, but it's a really good start.

Have a nice day,
-- 
Martijn van Oosterhout   klep...@svana.org   http://svana.org/kleptog/
 Please line up in a tree and maintain the heap invariant while 
 boarding. Thank you for flying nlogn airlines.


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

Martijn van Oosterhout wrote:
 On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
 Here is the initial draft of SE-PostgreSQL specifications:

   http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
 
 Hey, this is really cool. Think it is a nice introduction. Fixed some
 of the really obvious language stuff and an example but the English is
 quite good.

Thanks, but I found an incorrect change at the trusted procedure section.

Old)
  CREATE TABLE customer (
  cid integer primary key,
  cname   varchar(32),
  credit  varchar(32)
- SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
- );

New)
  CREATE TABLE customer (
  cid integer primary key,
  cname   varchar(32),
  credit  varchar(32)
+ ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';

This example intends to assign secret label on the credit column,
not whole of the table. Note that the default security context shall
be assigned on the table and rest of columns in this case.

| For example, when the customer table is defined as follows,
| unprivileged users cannot see the contents of customer.credit
| because it is labeled as sepgsql_secret_table_t which means
| all the accesses are denied from confined domains.

Is the description inadequate to note the example tries to assign
a certain security context on the customer.credit column?


BTW, in the later case, the table is labeled as secret, then columns
inherit table's security context in the default, so the table and all
the columns are labeled as secret.

 One thing I know people are going to ask: why did you use names like
 create and delete and not the usual names that postgresql itself
 uses. I suspect the answer is because that's the standard naming used
 in SELinux, but I think you need to spell that out somewhere.
 
 The same for the db_* convention. Do you have a reference to naming
 conventions for SELinux permissions?

http://oss.tresys.com/repos/refpolicy/trunk/policy/flask/access_vectors

All the object classes managed in userspace object manager have its prefix.
For example, X-window objects has x_* prefix.
Kenel objects don't have any prefix, such as file.

Referring the other base object classes, it uses create, getattr,
setattr, relabelfrom and relabelto commonly. However, a permission
to remove the object itself is named reflecting to the characteristics of
the object.
For example, file:{unlink} and ipc:{destroy} mean a permission to remove
itself. I believe drop is an appropriate naming for database objects.

TODO: add description at the Object classes and permissions why object
  classes are prefixed by db_*

 I need to think it over some more, but it's a really good start.
 
 Have a nice day,


-- 
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-24 Thread Stephen Frost

KaiGai,

* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
 Here is the initial draft of SE-PostgreSQL specifications:
 
   http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

Thanks for this, it really does help, I believe.  I've been reviewing it
and am also planning on helping refine and improve upon it.  I'd like to
spend time working on the patch as well but I'm hesitant to commit to
that right now due to other obligations.  We'll see how it goes.

Thanks again,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SE-PostgreSQL Specifications

2009-07-24 Thread Robert Haas

On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frostsfr...@snowman.net wrote:
 Thanks for this, it really does help, I believe.  I've been reviewing it
 and am also planning on helping refine and improve upon it.  I'd like to
 spend time working on the patch as well but I'm hesitant to commit to
 that right now due to other obligations.  We'll see how it goes.

At this point, I think refining and improving the spec is probably
considerably more important than writing the code.

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

2009-07-24 Thread Sam Mason

On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
 Thanks, but I found an incorrect change at the trusted procedure section.
 
 Old)
   CREATE TABLE customer (
   cid integer primary key,
   cname   varchar(32),
   credit  varchar(32)
 - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
 - );
 
 New)
   CREATE TABLE customer (
   cid integer primary key,
   cname   varchar(32),
   credit  varchar(32)
 + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';
 
 This example intends to assign secret label on the credit column,
 not whole of the table. Note that the default security context shall
 be assigned on the table and rest of columns in this case.

The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden.  For example, imagine we have a row
in the customer table with cid=1 whose security label would normally
prevent.  We can perform:

  SELECT show_credit(1);

and, as far as I can tell, this call would succeed.


-- 
  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 07:23:22AM +0900, KaiGai Kohei wrote:

Thanks, but I found an incorrect change at the trusted procedure section.

Old)
  CREATE TABLE customer (
  cid integer primary key,
  cname   varchar(32),
  credit  varchar(32)
- SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
- );

New)
  CREATE TABLE customer (
  cid integer primary key,
  cname   varchar(32),
  credit  varchar(32)
+ ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';

This example intends to assign secret label on the credit column,
not whole of the table. Note that the default security context shall
be assigned on the table and rest of columns in this case.


The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden.  For example, imagine we have a row
in the customer table with cid=1 whose security label would normally
prevent.  We can perform:

  SELECT show_credit(1);

and, as far as I can tell, this call would succeed.


This example shows that confined client cannot read credit card number
without using trusted procedure, but trusted procedure returns masked one.
It does not intend to hide existence of entries within customer table.

See the third box in the section.

 postgres=# SELECT cid, cname FROM customer;
  cid | cname
 -+---
   10 | jack
   13 | adam
   14 | liza
 (3 rows)

This query does not read from customer.credit, so it should be succeeded.

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-24 Thread Sam Mason

On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
 Sam Mason wrote:
 The show_credit() function in this section would seem to leak authority
 as well; it seems possible to determine if customers exist that
 otherwise may otherwise hidden.  For example, imagine we have a row
 in the customer table with cid=1 whose security label would normally
 prevent.  We can perform:
 
   SELECT show_credit(1);
 
 and, as far as I can tell, this call would succeed.
 
 This example shows that confined client cannot read credit card number
 without using trusted procedure, but trusted procedure returns masked one.
 It does not intend to hide existence of entries within customer table.

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';

(I hope I've modified the example correctly!)

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